locked
Interface best practice RRS feed

  • Question

  • Hi,

    I am trying to improve my coding practice so that for each business entity in my project (i.e. a class), I create an interface and occassionally use this interface throughout my project especially when working with LINQ.

    However I am still not solid on all the reasons why this is a best practice. 

    Could you elaborate

    TIA

    Wednesday, May 27, 2009 11:36 AM

Answers

  • Its an incredible best practice...why?

    I would rather work with interfaces than whole objects any day. Interfaces to me are a contracts of work . I know that a particular interface is designed to be focused on its task at hand; regardless of the object underneath. With that contract, which is leaner than looking at a whole object, I can get its gist of what it should do, quite quickly and use it appropriately as designed .

    Secondly if the code works with interfaces, say from a factory pattern, if the object underneath needs to be changed, no harm no foul. Any consumer does not have to change their code and only the business logic end changes.

    Also a the intent of multiple inheritance (for raw operations, not object oriented-ness) can be accomplished (IMHO) by having an object have multiple interfaces which give the object the ability to do specific work in multiple arenas.

    Interfaces have upfront costs, but the keep the operations focused and concise.

    My last major use of interfaces for me was to allow for an admin of a web site emulate a target user. The website would look at a specific interface IUser on the passed around user object and process screens and user requests accordingly. To emulate a user, I had an admin emulation user object which exposed both the IUser interface and an IAdmin interface. On non admin screens the website was none the wiser and allowed for me to emulate the IUser targetted. Only in admin screens or other specific areas wherere needed could test the object to see if IAdmin was also found and behaved accordingly.

    To sum up, its a contract of work and by working with an interface vs a hard class object will pay off dividends in terms of maintenace, understanding and object extensibility.

    HTH



    William Wegerson (www.OmegaCoder.Com)
    • Proposed as answer by Harry Zhu Tuesday, June 2, 2009 9:10 AM
    • Marked as answer by Harry Zhu Wednesday, June 3, 2009 7:58 AM
    Wednesday, May 27, 2009 3:25 PM
  • I hope this means that you are creating instance of the interfaces, and not the actual types and implementing classes themselves.  Are you doing this everywhere with the implementing classes?

    interface IA {  }

    class A : IA  {  }

    IA obj = new A();


    Mark the best replies as answers. "Fooling computers since 1971."
    • Proposed as answer by Harry Zhu Tuesday, June 2, 2009 9:10 AM
    • Marked as answer by Harry Zhu Wednesday, June 3, 2009 7:58 AM
    Wednesday, May 27, 2009 4:03 PM
  • What if you had this?

    interface IAgent {  }

    abstract class APerson { }

    public class Agent : APerson, IAgent

    I like to use abstract classes to reduce code redundancy.  I also define constructors in the abstract class and use them like Object Factories.  So that all inheriting classes are all built in the same fashion.  In fact, my abstract classes usually implements interfaces themselves.  You do not need to provide implementation in the abstract class either.

    interface IA
        {
            void Method();
        }
        abstract class AA : IA
        {
            public abstract void Method();
        }

    Mark the best replies as answers. "Fooling computers since 1971."
    • Proposed as answer by Harry Zhu Tuesday, June 2, 2009 9:09 AM
    • Marked as answer by Harry Zhu Wednesday, June 3, 2009 7:58 AM
    Wednesday, May 27, 2009 5:06 PM

All replies

  • Its an incredible best practice...why?

    I would rather work with interfaces than whole objects any day. Interfaces to me are a contracts of work . I know that a particular interface is designed to be focused on its task at hand; regardless of the object underneath. With that contract, which is leaner than looking at a whole object, I can get its gist of what it should do, quite quickly and use it appropriately as designed .

    Secondly if the code works with interfaces, say from a factory pattern, if the object underneath needs to be changed, no harm no foul. Any consumer does not have to change their code and only the business logic end changes.

    Also a the intent of multiple inheritance (for raw operations, not object oriented-ness) can be accomplished (IMHO) by having an object have multiple interfaces which give the object the ability to do specific work in multiple arenas.

    Interfaces have upfront costs, but the keep the operations focused and concise.

    My last major use of interfaces for me was to allow for an admin of a web site emulate a target user. The website would look at a specific interface IUser on the passed around user object and process screens and user requests accordingly. To emulate a user, I had an admin emulation user object which exposed both the IUser interface and an IAdmin interface. On non admin screens the website was none the wiser and allowed for me to emulate the IUser targetted. Only in admin screens or other specific areas wherere needed could test the object to see if IAdmin was also found and behaved accordingly.

    To sum up, its a contract of work and by working with an interface vs a hard class object will pay off dividends in terms of maintenace, understanding and object extensibility.

    HTH



    William Wegerson (www.OmegaCoder.Com)
    • Proposed as answer by Harry Zhu Tuesday, June 2, 2009 9:10 AM
    • Marked as answer by Harry Zhu Wednesday, June 3, 2009 7:58 AM
    Wednesday, May 27, 2009 3:25 PM
  • I hope this means that you are creating instance of the interfaces, and not the actual types and implementing classes themselves.  Are you doing this everywhere with the implementing classes?

    interface IA {  }

    class A : IA  {  }

    IA obj = new A();


    Mark the best replies as answers. "Fooling computers since 1971."
    • Proposed as answer by Harry Zhu Tuesday, June 2, 2009 9:10 AM
    • Marked as answer by Harry Zhu Wednesday, June 3, 2009 7:58 AM
    Wednesday, May 27, 2009 4:03 PM
  • Hi OmegaMan,

    Thanks for your feedback. What you shared is very helpful. however, I need some hand-on understanding of what you mean with these comments:

    1) "Secondly if the code works with interfaces, say from a factory pattern, if the object underneath needs to be changed, no harm no foul. Any consumer does not have to change their code and only the business logic end changes."

    So say I have an Agent class that implements Person class and IAgent (where  IAgent holds the agent details of a person working in a company) like  so:

    public class Agent : Person, IAgent

    it seems from your comment that this would be a bad usage, I should instead change it to:

    public class Agent : IPerson, IAgent

    and pass all the code implemented in Person class into the Agent class. Is that what you mean ? Is it bad usage as it is ? If yes, are the situations where my original implementations is valid ?

    2) "Also a the intent of multiple inheritance (for raw operations, not object oriented-ness) can be accomplished (IMHO) by having an object have multiple interfaces which give the object the ability to do specific work in multiple arenas."

    What do you mean by raw operations vs object-orientedness ?  By doing work in multiple arenas, do you mean (using say my suggested implementation) that in one context, I can do work that is agent specific and then later do work that is person specific ?

    Thanks in advance.



    Wednesday, May 27, 2009 4:47 PM
  • Thanks for your very relevant question. This is forcing me to think hard.

    Here is where I broke the above rule:

     Agent agent = new Agent();

    becasue I did the following:

    public class Agent : Person, IAgent     ( where   public class Person : IPerson )

    As I asked OmegaMan, is that bad implementation ?  I do find myself in a dificult situation becasue there is at least one case I think I need an entire agent object and it would be awkward (IMHO) to break up some operations for IPerson and another set for IAgent.... I tend to see  agent as having person properties and agent properties all implementable from IAgent and IPerson.

    I guess I could do the follwoing to improve the behavior...

    public class Agent : IPerson, IAgent

    but is there any situation where instantiating agent  be justifiable ?


    TIA


    Wednesday, May 27, 2009 5:06 PM
  • What if you had this?

    interface IAgent {  }

    abstract class APerson { }

    public class Agent : APerson, IAgent

    I like to use abstract classes to reduce code redundancy.  I also define constructors in the abstract class and use them like Object Factories.  So that all inheriting classes are all built in the same fashion.  In fact, my abstract classes usually implements interfaces themselves.  You do not need to provide implementation in the abstract class either.

    interface IA
        {
            void Method();
        }
        abstract class AA : IA
        {
            public abstract void Method();
        }

    Mark the best replies as answers. "Fooling computers since 1971."
    • Proposed as answer by Harry Zhu Tuesday, June 2, 2009 9:09 AM
    • Marked as answer by Harry Zhu Wednesday, June 3, 2009 7:58 AM
    Wednesday, May 27, 2009 5:06 PM