Tech Off Thread

13 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Interfaces

Back to Forum: Tech Off
  • User profile image
    clint_hill

    I am interested to find out what the opinion is of using interfaces for your objects. And secondly, how is it used. Does it benefit change management or does it protect object definition?

    I have never really created interfaces for any of the objects I have built - I just never saw a need. Any opinion on this would be great.

  • User profile image
    JParrish

    Interfaces are basically the OOP version of a contract. The primary benefit of using an interface, is that there is an enforement that the object at a minimum will provide the properties/methods that the interface specifies.

    Often times a class library will have interfaces with base classes which implement the interface for you. In regards to C#, you cannot derive from more than one class, so in the event that you create a class which needs to be passed into multiple contexts, you can implement the interfaces for each context and there will be no problems. For instance, one developer may have a vehicle inventory system which has an interface that specifies IVehicle. Then another developer has built an order entry system which requires that an object of IProduct be passed into the "ProcessOrder(IProduct product)" method. In this way both systems work with a single object, and their expected entries into that object are enforced.

  • User profile image
    hurcane

    From a functional perspective, I find interfaces beneficial when two disparate objects need to share a behavior. The first time I used an interface was in a customer billing program. Customers can be billed for product and they can be billed for labor. Product and Labor are different business objects, but they both implement the IBillableItem interface.

    The IBillableItem interface is used in the Billing object. When a Product object is billed, it has to update on-hand quantities. The Labor object doesn't have to do this. These different implementations are internal to the Product and Labor objects. The Billing object expects that the objects will "do the right thing" when it calls methods and properties through the interface.

    We frequently implement standard FCL interfaces in our objects. I implement ICloneable and IComparable in nearly every object I write.

  • User profile image
    prog_dotnet

    Take a look at the Session 8 - Interfaces, in the Modern Software Development with vb.net webcast series.


    http://msdn.microsoft.com/vbasic/community/webcasts/modern/default.aspx

    Session 1: Program Execution in the 21st Century
    This webcast has already occurred, click the link to access an on-demand version

    • Virtual machines, sandboxes, garbage collection Class libraries
    • Execution in .NET: CLR, FCL, JIT compilation, GAC
    • Quick discussion of application design (monolithic vs. component-based)
      

    Session 2: OOP and Class Design
    This webcast has already occurred, click the link to access an on-demand version

    • Basic classes: field & methods
    • Examples: String, Array, Customer
    • Instantiation with New & Redim
    • Class design: constructors, overloading, properties, ToString
    • References vs. values; Cloning: shallow vs. deep
      

    Session 3: Working with Classes and Class Libraries
    This webcast has already occurred, click the link to access an on-demand version

    • Namespaces; Instance vs. shared classes
    • Framework class library (e.g. File I/O, data structures, XML docs)
    • Interacting with Framework classes: For Each, Equals, Hashcode
    • Dynamic instantiation via "CreateObject"
      

    Session 4: Windows Forms: What's New in GUI Programming
    Thursday, February 26th, 2004 1 PM - 2:30 PM PST

    • Windows Forms classes
    • Delegates
    • "Control Arrays", many-to-one/one-to-many event handling
    • OOP with Windows Forms: objects & list boxes, type-casting
    • Data binding
    • Validation
      

    Session 5: Defensive Programming
    Tuesday, March 2nd, 2004 1 PM - 2:30 PM PST   

    Session 6: Databases (part 1 of 3)
    Tuesday, March 16th, 2004 1 PM - 2:30 PM PST   

     

    Session 8: Interfaces
    Tuesday, March 30th, 2004 1 PM - 2:30 PM PST   

    Session 9: Inheritance
    Tuesday, April 6th, 2004 1 PM - 2:30 PM PST   

    Session 7: Databases (part 2 of 3)
    Tuesday, March 23rd, 2004 1 PM - 2:30 PM PST   

    Session 10: Databases (part 3 of 3)
    Thursday, April 15th, 2004 1 PM - 2:30 PM PST   

    Session 11: Component-based Programming
    Tuesday, April 20th, 2004 1 PM - 2:30 PM PST   

    Session 12: Application Design and Deployment
    Tuesday, April 27th, 2004 1 PM - 2:30 PM PST   

    Session 13: Distributed Programming: Remoting vs. Web services
    Tuesday, May 4th, 2004 1 PM - 2:30 PM PST   

    Session 14: Concurrent Programming: Delegates and Multi-threading
    Tuesday, May 11th, 2004 1 PM - 2:30 PM PST   

    Session 15: Software Engineering Today: Best practices and Patterns
    Tuesday, May 18th, 2004 1 PM - 2:30 PM PST   

  • User profile image
    clint_hill

    Thanks guys. As I read your replies I see my actual question with interfaces is this: what happens when updates need to occur to interfaces?

    So I see how two disparate objects retain uniformity of behavior. But now lets say I add a behavior to the interface like so:

    public interface IObject
    {
       void Save();   //original
       void Delete(); //original
       void Copy();   //NEW Behavior
    }

    This will require me to go to any object implementing this interface and add logic. I see this as a bad methodology and I was curious how people would get around this. Would you even change the interface or just change the derived objects?

    And for arguments sake lets say this scenario happens because in a release test of an app a business rule changed and required this type of change.

  • User profile image
    JParrish

    Well, the fact that interfaces may change is something of a reality in software development. The world changes, our environment, the cultures surrounding us all change with time, and with that change will be a driving change to the software we write to try and model such dynamic environments.

    You wouldn't want to change an object that implemented an interface when the reality is the universe governing that interface the object implements has changed. You can make simple changes to deal with minute problems, but it is a bad practice (imo) to do so without binding future implementations to that same change.

    There are products that will assist you in re-factoring software when you have to make such a change. This won't help you much if you have shipped a thousand versions of your class library, but then that is why we have the concept of a version, they aren't always backwards compatible, nor should they be.

  • User profile image
    aza

    I find interfaces useful to move from the design stage to the development stage. After coming up with a rough class diagram it can be handy to use interfaces to clearly define the interactions between classes. This approach becomes even more useful when there are mutliple developers involved. I can provide the interface for my classes to the other developers much quicker then I can provide the implementation. Coding can then proceed in parallel.

    One esoteric problem I am grappling with right now is due to interfaces not supporting properties. Often the shared signatures will need methods and properties. Alternative options are to use a base class and inheritance but this adds a level of semantic complexity that kind of defeats the purpose.

    If a "shared" interface changes then all parties using it need to adjust their code. The benefit of using the interface in this case is that as an interface implementer you know exactly which signatures are used by consumers. Of course public accessors also do this but I think interfaces give it an extra level of clarity. I may still be tempted to change a public method signature because I was the one who made it public in the first place and no one else is likely to be using it and maybe I'll just make it private so I can change it anyway.

    Regards,
    Aaron

  • User profile image
    hurcane

    Changing the public side of an interface is problematic. Any existing components that have implemented the interface will break if they try to run against the new version of the interface.

    How I would handle it depends on how much influence I have over the components that have implemented the interface.

    If I have access to the source code of all components that use the interface, then I would have to change each of them to implement new method.

    Even if I don't have direct access to the source code, the component may only be used within my workgroup/department/enterprise. If I have influence over the other developers and can mandate that they must change their components to implement the new method, I would go that route.

    It's when you don't have influence over existing implementations that you have trouble. You have two choices, basically. You can break the interface and deal with the feedback, or you make a new interface.

    If I had sold or given away the component that defines this interface, breaking the interface is probably not an option. In this case, I would make an IObject2 interface. I would convert IObject into a facade that makes calls into IObject2. If users want the new functionality, they can change their source code to use IObject2 instead of IObject.

    I've seen the incremental numbering of interfaces a lot with 3rd-party components. Crystal Reports has done it. Videosoft (now ComponentOne) has done it. I've been working recently with Dymo printers, and they have done the same thing.

    If you're dealing with public interfaces that are going to be used by people over whom you have no influence, you must be very careful about the design because it truly becomes a "contract" once it is implemented by others.

  • User profile image
    clint_hill

    Thanks for all the feedback. And I will admit, I still don't like the idea of interfaces. I see the beauty of sharing "behaviors", yet I find it so limiting when change-management rolls in to the picture.

    hurcane wrote:
    If you're dealing with public interfaces that are going to be used by people over whom you have no influence, you must be very careful about the design because it truly becomes a "contract" once it is implemented by others.



    And so I would wonder how might there be a way to still get the advantages of interfaces yet keep the flexibility of classes. Abstract comes to mind and I was wondering how you guys play this into your designs?

  • User profile image
    JParrish

    You still aren't allowed multiple inheritance.

  • User profile image
    clint_hill

    Sure, but if you take good care of the interfaces that this abstract class has originally and just add features to the abstract class, aren't you getting best of breed?

  • User profile image
    JParrish

    Well I think this points to the separation between interfaces and implementation classes. To me, the interface is a minimal contract on what will be supported. If you want to add a feature, such that it simply provides value to an implementation, then you are free to do that in an implementation class, that won't break the interface.

    If however, you have to alter the signature of a method that the interface defines, then you are most likely looking at a fundamental change to the core concepts the interface supports. In that case, all classes need to be forced to adhere to the new contract.

  • User profile image
    aza

    clint_hill wrote:
    And so I would wonder how might there be a way to still get the advantages of interfaces yet keep the flexibility of classes. Abstract comes to mind and I was wondering how you guys play this into your designs?


    I use interfaces to:
    1. Provide an agreed upon signature for two or more developers,
    2. Provide a minimal clean access point for an implementation class.

    Classes are obviously where all the magic happens and serve a completely different purpose to interfaces. As far as abstract classes go if they only contain abstract members then they are equivalent to an interface anyway.

    I find I use interfaces more then base/abstract classes and polymorphism. While polymorphism is extremely powerful and useful the situations to which it is suited for don't appear that regularly.

    I don't see a class as being more flexible then an interface, they are used for different things. Unlike classes interfaces can't satisfy any functional requirements but if interfaces are used wisely they can provide the code with clearer and cleaner semantics; thus helping avoid smell and make life easier for maintainers. In more complex designs Interfaces also make it easier for multiple developers to build and subsequently use the software by providing unambiguos APIs.

    Aaron

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.