Я не могу сказать, что это вопрос, но скорее запрос о мнении, и я уверен, что многие другие могли бы воспользоваться разъяснением этой проблемы.
Вот мой практический случай:
У меня есть абстрактный класс под названием DataExchangeService и много подклассов, которые расширяют его (это базовый класс CONTROLLER в моей MVC Framework). Модули администрирования, которые обрабатывают определение данных (пользователи, типы, разделы и т. Д.), Все они имеют методы добавления, редактирования, удаления, списка со 100% -ным сходством в большинстве случаев. Я знаю это, потому что я копирую их, используя только поиск и замену. Теперь не все мои подклассы DateExchangeService обрабатывают данные, поэтому есть достаточно случаев, когда мне не нужны методы CRUD.
Множественное наследование определит эти методы CRUD и их поведение в другом классе и расширит оба этих класса там, где это необходимо, но я действительно думаю, что это сложный материал, и я его не использую (+ PHP не имеет такой функциональности). Итак, какова была бы лучшая практика?
Вот те подходы, которые пришли мне в голову:
Определите класс CRUDHandler, у которого все эти методы параметризованы.
Создайте свойство типа CRUDHandler, где это необходимо, а также реализуйте интерфейс CRUD, который заставит меня использовать эти методы.
В телах реализованных методов я добавляю что-то вроде этого:
public function edit ($ params) {
$ this-> params = $ params;
$ this-> CRUDHandler-> handle ("edit", $ this);
}
(В PHP это можно сделать с __call() магического метода __call() .)
Определите класс CRUDHandler как расширение базы DataExchangeService.
При определении определенного типа DataExchangeService (например, UsersExchangeService) вместо расширения DataExchangeService вы расширяете CRUDHandler, таким образом вы получаете все, что хотите, когда это необходимо.
Итак, есть ли другие мнения относительно этого подхода MultiInheritance?
благодаря
В настоящее время существует популярный стиль мышления, в котором говорится, что « предпочитают композицию над наследованием ». Слишком много информации о Google, чтобы действительно перечислить все это здесь, но давайте просто скажем, что за редким исключением изредка абстрактного базового класса я не использовал наследование через 2-3 года.
Основная идея заключается в том, что любой заданный класс, а не расширение базовых классов, которые позволяют ему предоставлять требуемую функциональность, будет иметь зависимости от других классов. На самом деле, чтобы сохранить вещи SOLID , у нее будут зависимости от интерфейсов, которые предоставляют контракт, в котором говорится, что они будут выполнять функцию.
Затем вы попадаете в точку, в которой ваш класс Controller имеет много переданных услуг / компонентов, которые он делегирует, чтобы выполнить определенные задания.
На этом этапе я считаю, что рекомендуется читать: