我不能说这是一个问题，而更多的是一个意见请求，我相信许多其他人可以从澄清这个问题中受益。
这是我的实际案例：
我有一个名为 DataExchangeService 的抽象类和许多扩展该类的子类（这是我的 MVC 框架中的基本 CONTROLLER 类）。处理数据定义的管理模块（用户、类型、部分等）它们都具有添加、编辑、删除、列表方法，在大多数情况下具有 100% 的相似性。我知道这一点，因为我仅使用搜索和替换来复制它们。现在的问题是，并非所有 DateExchangeService 子类都处理数据定义，因此有足够多的情况我不需要 CRUD 方法。
多重继承将在另一个类中定义这些 CRUD 方法及其行为，并在需要的地方扩展这两个类，但我确实认为这是很棘手的东西，而且我不使用它（+PHP 没有这样的功能）。那么最佳实践是什么？
以下是我想到的方法：
CASE A
-
定义一个将所有这些方法参数化的 CRUDHandler 类。
- 强制我使用这些方法。
-
在已实现方法的主体中，我添加了如下内容：
public function edit($params) {
$this->params = $params;
$this->CRUDHandler->handle("edit", $this);
}
在 PHP 中，可以使用 __call() 来完成此操作）
代码> 魔术方法。）
案例 B
-
定义 CRUDHandler 类来扩展基础 DataExchangeService。
-
定义特定类型的 DataExchangeService 时（例如
UsersExchangeService) 不是扩展 DataExchangeService，而是扩展 CRUDHandler，
这样您就可以在需要时得到您想要的一切。
那么，对于这种多重继承方法还有其他看法吗？
谢谢
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
-
Define a CRUDHandler class that has all these methods parametrized.
-
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);
}
(In PHP this can be done with the __call() magic method.)
CASE B
-
Define class CRUDHandler as extending the base DataExchangeService.
-
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
发布评论
评论（1）
目前有一种流行的思维方式是“优先考虑组合而不是继承”。 Google 上的信息太多，无法在这里全部列出，但我们只能说，除了偶尔出现的抽象基类之外，我已经有 2-3 年没有使用继承了。
主要思想是任何给定的类都将依赖于其他类，而不是扩展允许其提供所需功能的基类。事实上，为了保持事物SOLID，它将依赖于提供契约的接口，表明它们将执行某项功能。
然后，您的 Controller 类会传入服务/组件，并委托给这些服务/组件来完成特定的工作。
请注意，您也可能在其他方面走得太远。如果您有一个依赖于大量外部服务的类，尤其是如果该类中并非每个公共方法最终都使用所有外部服务，那么您实际上可能有两个类。即，您的控制器通过执行多项工作来“违反”单一责任原则。对于 Web 框架中的控制器来说，这尤其容易意外发生，因为它们鼓励这样做。
此时，我认为建议阅读：
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: