多重继承，特征和特性，这是最佳方法吗？

Question

我有一些类可以与不同类型的数据库进行交互。每个数据库类都需要扩展一些常规类。

赞：

<?php
mysql\SelectSql extends common\SelectSqlAbstract
mysql\SqlComposer extends common\SqlComposerAbstract
?>

问题是SelectSql还应该扩展SqlComposer类。在PHP中这是不可能的，因为它需要多重继承。

所以我正在尝试解决方法，并将SqlComposer重写为特征。 （我也尝试使用SelectSqlAbstract作为特征），然后该结构是：

<?php
class mysql\SelectSql extends common\SelectSqlAbstract{
  use mysql\SqlComposerTrait
} 
abstract class common\SelectSqlAbstract extends common\SqlComposerAbstract{
  protected $sqlType = 'select';
}

abstract class common\SqlComposerAbstract{
  protected $sqlType;
  protected $dbType;

}
trait mysql\SqlComposerTrait{
  protected $dbType = 'mysql';
}
?>

这实际上不是最佳实践，它会导致致命错误。

但是我还能怎么做？我不想通过从类名/命名空间中提取属性的函数来获取属性。

并且当您需要两种类型的级别时，有没有更好的方法来获得此结构：specificNS \ SpecificClass扩展commonNs \ SpecificClass扩展specificNs \ CommonClass扩展commonNs \ CommonClass

组成不会真正有帮助。因为大多数功能都是常见的。只有少数功能会被特定Ns覆盖]

这对别名类没有帮助（我认为），因为我需要在一个脚本中使用更多类型的数据库...

Answer 1

[使用ORM是唯一的最佳实践，还是使用自己的代码是一个完全不同的争论，我敢肯定，对于这一点，开发人员的数量与那里的观点一样多。

正如您使用代码已有多年的经验，这意味着它可以正常工作，并且您现在知道代码的每一点，因此请坚持使用已有的内容，并通过重构使其逐渐变得更好。

现在出现问题，如果您试图从头开始重写数据库访问逻辑，而您要做的只是能够稍后轻松地切换数据库而无需修改一堆类，我建议您使用一个查看您所坚持的设计模式以外的其他模式。

例如，在您的情况下，请尝试策略模式或构建器模式，您可以在运行时决定逻辑。对于特定于PHP的用例，请检查https://github.com/domnikl/DesignPatternsPHP组合肯定会有所帮助，而它将产生更优雅和可读的代码，您正在尝试通过多重继承实现的代码。