Interface per base class design

Question

consider i have a Customer Class and it got CustomerTypeA, CustomerTypeB, CustomerTypeC as child classes.

Would it be a better design to implement a ICustomer interface to Customer class and create sub type objects (CustomerTypeA, CustomerTypeB, CustomerTypeC)

interface ICustomer {}

class Customer : ICustomer {}

class CustomerTypeA : ICustomer {}
class CustomerTypeB : ICustomer {}
class CustomerTypeC : ICustomer {}

ICustomer obj;
obj = new CustomerTypeB();

or

Create objects of child classes with Customer class object declaration?

class Customer {}
class CustomerTypeA : Customer {}
class CustomerTypeB : Customer {}
class CustomerTypeC : Customer {}

Customer obj;
obj = new CustomerTypeB();

How should i choose which approach to follow?

May be in other words, is it a better design that every parent object to implement from an Interface? what advantage does it bring me?

Thank you

Its C#. Just out of curiosity how does the programming language effect the solution? — Ramu, Sep 23 '18 at 12:43
It is not entirely clear what alternatives you are considering. In one version, you would have a base class and child classes without any interfaces, and in the other one, you would have only interfaces (one for each "subclass") and no base class? Only a base interface maybe? — user3738870, Sep 23 '18 at 12:52
C++, Perl, JavaScript, Common Lisp don't have interfaces. Perl has roles you could use instead, depending. Haskell has classes (in a way), but no subtyping. — melpomene, Sep 23 '18 at 12:52
@user3738870 added sample example snippet, may be it helps to understand the question better — Ramu, Sep 23 '18 at 13:03
I believe that your question is too broad: asking for *what's better* should be focused on some concrete use case. — Matías Fidemraizer, Sep 23 '18 at 13:51
A great article https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose — Eldho, Sep 23 '18 at 14:18

score 1 · Accepted Answer · answered Sep 23 '18 at 12:44

1

You may use either but people are increasingly favoring composition over inheritance. It offers flexibility at runtime and increased separation of concerns.

To decide what's best in your case you have to examine how the type hierarchy might evolve, what your actual requirements are, how you want to write automated tests etc.

answered Sep 23 '18 at 12:44

Hero Wanders

3,237
1
10
14

How does composition over interface increase increased separation of concerns when compared over parent class design? – Ramu Sep 23 '18 at 13:15
1

@Ramu it depends on you situation . Single inheritance is not a problem. Suppose you have a class which is engine and you have another class CarEngine. You can have carengine : eninge but this go when there a `supercarengine : carengine` It can complex. Instead you can have Supercarengine "have" car engine functionalities which makes easier to design. Inheritance is a relationship & composition is a has a relationship – Eldho Sep 23 '18 at 14:21
1

Using inheritance introduces static coupling of behavior (from the child class to the parent class). This means what you get from your child class is basically always the base class behavior plus some modifications (weak separation). In many cases this is not a problem. But you may encounter situations where you would like to bind your child classes' specific behavior to other implementations of the API which the base class offers. Using composition, the specific behavior is located in independent classes and loosely coupled by interface based delegation. Look at your case and decide what you – Hero Wanders Sep 23 '18 at 14:42

score 1 · Answer 2 · answered Sep 23 '18 at 13:18

You could generally use both. But if your class "Customer" is needed somewhere else i would either go with the second solution (simple inheritance) ore change the first solution to this (assuming that your CustomerTypes still have something in common with Customer):

interface ICustomer{}
class Customer:ICostumer{}
class CustomerTypeA:Customer{}
...

And when using it:

ICustomer myCustomer=new CustomerTypeA();

score 1 · Answer 3 · answered Sep 23 '18 at 13:46

I think this can only be decided with more knowledge about the specific use case. What you should keep in mind is that in C# you can only have one base class. So your second alternative can only work if you don't have to inherit from any other classes in either of the subclasses.

So in general, I think the first approach is more flexible, and if you want to avoid code duplication in you subclasses, you may want to consider implementing the shared logic in the Customer class, and inherit from it wherever possible. If one of your subclasses needs to inherit from a different class, it can still implement ICustomer, of course.

Also, if the shared logic is a larger piece of code/functionality and you can't use inheritance (because of another base class being present), you can also consider using delegation (composition over inheritance/strategy pattern).

Interface per base class design

3 Answers3