locked
Interface for same classes in different namespaces/projects, on other way.... RRS feed

  • Question

  • Hi Smile

     

    Maybe this has no sense - i have two business classes A and B, with same properties, but in different projects. I have code C in third project who manages class B. How can i manage that code C manage class B, but without using interface. I tries to avoid interface or abstract class because of changes in classes A and B.

    If i must implement interface, best place will be in project with code C, right?

     

    And if there is any good literature about this..... thanx Smile

    Sunday, January 6, 2008 12:57 AM

Answers

  • If I'm understanding you correctly, you're asking if you can manage a class without an interface?

     

    You could reference the class directly and code A and B could derive from a base class of shared functionality, but OO principles would say that you should use an interface so that other objects are not coupled to that changing class implementation.

     

    If project code C is common to both, it may be the best place to put the code.  On the other hand, the best place may well be in a new project, code D, then it is completely de-coupled from any of the other code projects.

     

    My advice is always use interfaces, they much much easier to test properly, and they provide a cleaner, unchanging way into a code implementation.  The fact that A and B change often should dictate that you use an interface, and making a design decision not to do so, because they change often is incorrect, as laziness has been factored into your design.

     

    I hope this helps,

     

    Martin Platt.

    Monday, January 7, 2008 4:08 AM

All replies

  • If I'm understanding you correctly, you're asking if you can manage a class without an interface?

     

    You could reference the class directly and code A and B could derive from a base class of shared functionality, but OO principles would say that you should use an interface so that other objects are not coupled to that changing class implementation.

     

    If project code C is common to both, it may be the best place to put the code.  On the other hand, the best place may well be in a new project, code D, then it is completely de-coupled from any of the other code projects.

     

    My advice is always use interfaces, they much much easier to test properly, and they provide a cleaner, unchanging way into a code implementation.  The fact that A and B change often should dictate that you use an interface, and making a design decision not to do so, because they change often is incorrect, as laziness has been factored into your design.

     

    I hope this helps,

     

    Martin Platt.

    Monday, January 7, 2008 4:08 AM
  •  

    Thank you so much, Martin , it helps !

     

    Two important things i learn:

    1. Why to use interface instead of abstract class - so you don't take care about shared functionality. Shared functionality is needed sometimes ... but i don't need it now.

    2. This is really good idea to have D project for interface, so you can decouple projects.

     

    Anyway, if you have time, what book is good to read for this kind of problems?

     

    regards, Vlado

    Monday, January 7, 2008 5:23 AM