我有一些类与不同类型的数据库交互。每个db类都需要扩展一些通用类。
:
<?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
extends commonNs'SpecificClass
扩展specificNs ' CommonClass
扩展commonNs ' CommonClass
组合不会真的有帮助。因为大多数函数都是在公共函数中。只有少数函数会被覆盖
它不会帮助别名类(我认为)，因为我需要在一个脚本中使用更多类型的数据库…
使用ORM是唯一的最佳实践，还是使用自己的代码是一种完全不同的争论，我相信在这个问题上有很多开发者的意见。
因为你已经使用你的代码多年了，这意味着它可以工作，你现在知道你的代码的每一个细节，所以坚持你所拥有的，并通过重构逐渐使它变得更好。
现在问题来了，如果你试图从头开始重写你的DB访问逻辑，你想做的就是能够在以后轻松地切换数据库，而不必修改一堆类，我建议你看看设计模式，而不是你所坚持的设计模式。
例如，在您的情况下，尝试策略模式或构建器模式，您可以在运行时决定逻辑。有关PHP特定用例，请查看https://github.com/domnikl/DesignPatternsPHP组合肯定会有帮助，相反，它会产生比您试图通过多重继承实现的代码更优雅、更可读的代码。