существует ли противоположность абстрактному классу?

Я использую свой собственный PHP-фреймворк, и он в значительной степени основан на компонентах, в основном от pear и Zend, но в последнее время появляются некоторые лучшие компоненты Composer.

Поскольку мои приложения растут, становится все труднее переключаться между компонентами, и я задаюсь вопросом, есть ли способ разработать мои программы по-другому. Таким образом, чтобы я мог использовать компоненты как противоположность абстрактным классам.

Я думаю, что должен быть способ создания собственных классов, которые, в свою очередь, просто подключаются к pear или zend и используют эти классы, как если бы они были интерфейсами или абстрактными классами. Конечно, они будут выполнять фактическую работу, а я буду просто ссылаться на них.

Гипотетически, если я использовал pear Config/Lite, который может работать только с ini и файлами массивов, а теперь я хочу перейти на pear config или Zend config, чтобы получить преимущество сохранения данных в базе данных, то должен быть простой способ переключиться без изменения всего моего кода, поскольку они реализуют одно и то же.

Я спрашиваю, потому что я использовал pears Net/URL/Mapper, который не так уж плох, но я нашел что-то, что также позаботится о диспетчеризации, и это активно развивается. Также я уверен, что подобная ситуация будет возникать снова и снова.

Решение

Вы хотите найти что-то вроде паттерна проектирования фасада или просто использовать делегирование / композицию. Однако будьте осторожны, использование чего-то вроде фасада может привести к большой ненужной сложности, поскольку вы добавляете уровни абстракции. Я рекомендую вам прочитать некоторые паттерны проектирования php, особенно делегирование / композицию объектов, чтобы понять, как это может подойти для вашего случая.

Комментарии (1)

Для этого, IMO, следует использовать композицию. Пусть классы в вашей библиотеке открывают свой собственный публичный интерфейс, от которого зависит остальная часть вашего кода. Если вы когда-либо измените основу компонента, скажем, с PEAR на Zend, просто убедитесь, что все оригинальные публичные методы по-прежнему соответствуют предыдущей версии, и все будет в порядке. При желании вы можете формализовать эти интерфейсы с помощью ключевого слова interface, но это выходит за рамки данного ответа ;)

Комментарии (0)