怪异的多重继承的优雅替代品 [英] Elegant alternatives to the weird multiple inheritance

问题描述

我不能说这是一个问题，但是更多的是征求意见，我确信许多其他人可以从澄清这个问题中受益.

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.

这是我的实际情况:

我有一个名为DataExchangeService的抽象类和许多扩展该类的子类(这是我的MVC Framework中的基本CONTROLLER类).处理数据定义(用户，类型，部分等)的管理模块在大多数情况下都具有100％相似性的添加，编辑，删除，列表方法.我知道这是因为我仅通过搜索和替换来复制它们.现在事情不是我的所有DateExchangeService子类都可以处理数据定义，因此在很多情况下我不需要CRUD方法.

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.

多重继承将在另一个类中定义这些CRUD方法及其行为，并将这两个类扩展到需要的地方，但我确实认为这是棘手的事情，因此我不使用它(+ PHP没有这样的东西)功能).那么什么是最佳做法?

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?

以下是我心中的方法:

1. 定义一个具有所有这些方法参数化的CRUDHandler类.

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

在需要的地方创建一个CRUDHandler类型的属性，并实现CRUD接口，这将迫使我使用这些方法.

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

在实现的方法的正文中，我添加如下内容:

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

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

(在PHP中，可以使用__call()魔术方法来完成.)

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

1. 将类CRUDHandler定义为扩展基础DataExchangeService.

1. Define class CRUDHandler as extending the base DataExchangeService.

在定义特定类型的DataExchangeService时(例如 UsersExchangeService)而不是扩展DataExchangeService，而是扩展CRUDHandler， 这样，您将在需要时获得所需的一切.

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.

那么，对于这种MultiInheritance方法还有其他意见吗?

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

谢谢

推荐答案

当前有一种流行的思维方式，说"

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.

主要思想是，任何给定的类(而不是扩展允许其提供所需功能的基类)都将依赖于其他类.实际上，要保留 SOLID ， 将依赖于接口，这些接口提供了一个合同，表明它们将执行功能.

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.

然后，您到达Controller类具有传入的服务/组件的位置，它委派给这些服务/组件以完成特定的工作.

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.

请注意，您也可以采用其他方法.如果您有一个类，尤其是依赖于许多外部服务的类，如果不是该类上的每个公共方法最终都使用了它们，那么实际上您可能会有两个类. IE.您的控制者通过执行多项工作来违反"单一责任原则.对于Web框架中的控制器而言，这是很容易偶然发生的事情，因为它们鼓励这样做.

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:

• 收藏继承之上的组成.
• 依赖注入和控制反转.
• 控制容器的倒置(例如 StructureMap 和我的个人收藏:

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

这篇关于怪异的多重继承的优雅替代品的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！