Элегантные альтернативы странному множественному наследованию - PullRequest
Новая
       4

Элегантные альтернативы странному множественному наследованию

4 голосов
/ 19 января 2011

Я не могу сказать, что это вопрос, но скорее просьба о мнении, и я уверен, что многие другие могли бы выиграть от разъяснения этого вопроса.

Вот мой практический пример:

У меня есть абстрактный класс с именем DataExchangeService и множество подклассов, расширяющих этот класс (это базовый класс CONTROLLER в моей MVC Framework).Модули администрирования, которые обрабатывают определение данных (пользователи, типы, разделы и т. Д.), Все они имеют методы добавления, редактирования, удаления, составления списка со сходством в большинстве случаев на 100%.Я знаю это, потому что я копирую их, используя только поиск и замену.Теперь дело не в том, что все мои подклассы DateExchangeService обрабатывают определение данных, поэтому есть достаточно случаев, когда мне не нужны методы CRUD.

Множественное наследование определило бы эти методы CRUD и их поведение в другом классе ирасширить оба этих класса там, где это необходимо, но я действительно считаю, что это сложно, и я не использую его (+ PHP не имеет такой функциональности).Итак, что было бы лучшим опытом?

Вот подходы, которые приходили мне в голову:

CASE A

  1. Определить класс CRUDHandler, который имеет всеэти методы параметризованы.

  2. Создайте свойство типа CRUDHandler, где оно необходимо, а также реализуйте интерфейс CRUD, который заставит меня использовать эти методы.

  3. В тела реализованных методов я добавляю что-то вроде этого: 

public function edit($params) {
    $this->params = $params;
    $this->CRUDHandler->handle("edit", $this);
}

(В PHP это можно сделать с помощью магического метода __call().)

CASE B

  1. Определить класс CRUDHandler как расширение базового DataExchangeService.

  2. При определении определенного типа DataExchangeService (например, UsersExchangeService)вместо расширения DataExchangeService вы расширяете CRUDHandler, таким образом вы получаете все, что хотите, когда это необходимо.

Итак, есть ли другие мнения по поводу этого подхода с применением множественного наследования?

Спасибо

1 Ответ

7 голосов
/ 19 января 2011

В настоящее время существует популярный стиль мышления, который гласит: « предпочитает композицию наследованию ». В Google слишком много информации, чтобы действительно перечислить все это здесь, но давайте просто скажем, что за редким исключением случайного абстрактного базового класса я не использовал наследование в течение 2-3 лет.

Основная идея состоит в том, что любой данный класс, а не расширяющий базовые классы, которые позволяют ему предоставлять требуемую функциональность, будет зависеть от других классов. На самом деле, чтобы сохранить вещи SOLID , он будет зависеть от интерфейсов , которые предоставляют контракт, в котором говорится, что они будут выполнять функцию.

Затем вы попадаете в точку, где ваш класс Controller имеет переданные сервисы / компоненты, которым он делегирует для выполнения определенных заданий.

Заметьте, вы можете зайти слишком далеко и другим путем. Если у вас есть класс, который зависит от множества внешних сервисов , особенно , если не каждый публичный метод класса завершает использование всех из них, у вас фактически может быть два класса. То есть ваш контроллер «нарушает» принцип единственной ответственности, выполняя более одной работы. Это особенно легко сделать случайно с контроллерами в веб-фреймворках, потому что они как бы поощряют это.

На данный момент, я считаю, что желательно прочитать:

...