Elegant alternatives to the weird multiple inheritance

Question

I can not say that this is a question, but more of an opinion request and I am sure many others could benefit from clarifying this issue.

Here is my practical case:

I have an abstract class called DataExchangeService and a lot of sub-classes that extend this one (this is the base CONTROLLER class in my MVC Framework). The administration modules that handle data definiton (Users,Types,Sections etc) they all have the add,edit,delete,list methods with 100% similarity in most cases. I know that because I replicate them by using only search and replace. Now the thing is not all my DateExchangeService sub-classes handle data definiton so there are enough cases where I don't need the CRUD methods.

Multiple inheritance would define these CRUD methods and their behaviour in another class and would extend both these classes where it is needed, but I really do think it is tricky stuff and I do not use it (+PHP doesn't have such functionality). So what would be the best practice?

Here are the approaches that crossed my mind:

CASE A

1. Define a CRUDHandler class that has all these methods parametrized.

2. Create a property of CRUDHandler type where it is needed and also implement the CRUD interface that will force me to use these methods.

3. In the bodies of the implemented methods I add something like this:

public function edit($params) {
    $this->params = $params;
    $this->CRUDHandler->handle("edit", $this);
}

(In PHP this can be done with the __call() magic method.)

CASE B

1. Define class CRUDHandler as extending the base DataExchangeService.

2. When defining a specific type of DataExchangeService (for example UsersExchangeService) instead of extending DataExchangeService you extend CRUDHandler, this way you get all you want when it is needed.

So, are there any other opinions on this MultiInheritance approach?

Thanks

Answer 1

There is currently a popular style of thinking that says "favour composition over inheritance". There is too much information on Google to really list it all here, but let's just say that with the rare exception of the occasional abstract base class, I haven't used inheritance in 2-3 years.

The main idea is that any given class, rather than extending base classes that allow it to deliver required functionality, will have dependencies on other classes. In actual fact, to keep things SOLID, it'll have dependencies on interfaces that provide a contract that says they'll perform a function.

You then get to a point where your Controller class has services/components passed-in, which it delegates to in order to get specific jobs done.

Note you can go too far the other way as well. If you have a class that depends on lots of external services especially if not every public method on the class ends up using all of them, you might in fact have two classes after all. I.e. your controller is "violating" the single responsibility principle by doing more than one job. This is especially easy to do by accident with controllers in web frameworks because they kind of encourage it.

At this point, I reckon it's advisable to read up on:

• Favour composition over inheritance.
• Dependency Injection and Inversion of Control.
• Inversion of Control containers (e.g. StructureMap and my personal favourite: Castle Windsor).