У меня есть несколько классов для взаимодействия с различными типами баз данных. Каждый 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';
}
?>
Это действительно не лучшая практика, и она приведет к фатальной ошибке :-(.
Но как еще я могу это сделать? Я не хочу, чтобы получить свойства с помощью функции, которая извлекает его из пространства имен / классов.
И есть ли лучший способ получить эту структуру, когда вам нужно 2 типа уровней:
specificNS \ SpecificClass
расширяет commonNs \ SpecificClass
расширяет конкретныеNs \ CommonClass
расширяет commonNs \ CommonClass
Композиция не очень поможет. Потому что большинство функций будут в общих чертах. Только несколько функций будут переопределены
NB!
Это не поможет псевдонимам классов (я думаю), потому что мне нужно использовать больше типов баз данных в одном скрипте …
Заранее спасибо, flexjoly
Вопрос о том, является ли использование ORM единственной лучшей практикой, или использование собственного кода — это путь совершенно другой дискуссии, и я уверен, что по этому поводу существует столько же мнений, сколько и разработчиков.
Поскольку вы работали с вашим кодом в течение многих лет, это означает, что он работает, и вы уже знаете каждый кусочек своего кода, поэтому придерживайтесь того, что у вас есть, и постепенно улучшайте его с помощью рефакторинга.
Теперь перейдем к вопросу: если вы пытаетесь переписать логику доступа к БД с нуля, и все, что вам нужно сделать, это иметь возможность легко переключать базы данных в дальнейшем без изменения кучи классов, я бы порекомендовал взглянуть на шаблоны дизайна, отличные от той, с которой вы застряли.
Например, в вашем случае, попробуйте шаблон стратегии или шаблон компоновщика, где вы можете определить логику во время выполнения.
для конкретных случаев использования PHP, проверьте https://github.com/domnikl/DesignPatternsPHP
Композиция, безусловно, должна помочь, и скорее она создаст более элегантный и читаемый код, который вы пытаетесь получить с помощью множественного наследования.
Других решений пока нет …