Какой шаблон проектирования будет подходящим для использования в этой структуре классов PHP, без множественного наследования?

Question

У меня есть абстрактный класс с именем Node.Он содержит конструктор, который берет строку из моей базы данных и создает базовую информацию.Все части контента на моем сайте расширяют этот класс - Person, Event, Project и т. Д.

3 этих расширенных классов являются особыми - когда они создаются, в дополнение к извлечению значений избаза данных, они также должны запросить веб-сервис;если веб-служба предоставляет значения, отличные от значений, указанных в БД, их необходимо сохранить в БД.

На языке с множественным наследованием это было бы довольно просто;любой из этих классов будет расширяться как Node, так и APIData, или что-то в этом роде.Без MI я не уверен, как справиться с этим.Использование интерфейса не помогло бы, так как это не дает конкретных реализаций.

Шаблон декоратора иногда рекомендуется в качестве замены некоторых функций MI, но у меня нет достаточного опыта, чтобы определить, является ли этосоответствующий выбор.Есть предложения?

Answer 1

Объекты должны быть тупыми. Когда я создаю что-то, оно не должно делать ничего, кроме того, о чем я его спрашиваю, то есть создавать себя. Не обращайтесь к веб-сервисам и не пишите в базу данных. Если бы я использовал ваши объекты в качестве другого разработчика в вашей команде, я был бы шокирован.

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

Я думаю, что лучшим подходом здесь будет создание службы, которая возвращает объекты, такие как PersonService, EventService и т. Д., Которая выполняет следующие действия:

• Получить запись из базы данных
• Если необходимо проверить веб-сервис:
  • Извлечение данных из веб-службы
  • Если изменения существуют, сохранить обратно в базу данных
• Передать запись в конструктор объекта
• Возврат объекта

Это позволяет не беспокоиться о вызове веб-службы в таком месте, где это имеет смысл, то есть в коде, который извлекает необходимые данные для создания и возврата объектов, то есть службы (РЕДАКТИРОВАТЬ: фактически DAO, но вы идея).

Answer 2

Поскольку класс APIData будет принимать функциональность от вашего класса Node, вы должны просто расширить его. Вот некоторый псевдокод:

abstract class APIData extends Node {

    public function __construct($data) {
        parent::__construct($data);
        $this->checkData();
    }

    protected function checkData() {
        // load data from webservice
        $data = $this->loadData();

        // check if data is the same
        foreach($data as $item => $value) {
            if ($this->data[$item] != $value) {
                // save in database
            }
        }
    }
}

Answer 3

Не обязательно сидеть и выбирать шаблон дизайна, как в «хорошо, я собираюсь реализовать шаблон декоратора». Вместо этого вы должны разработать свой код так, как он должен работать, и в результате этого будет развиваться шаблон проектирования. Просто так получилось, что у нас есть много существующей терминологии, которая описывает некоторые общие шаблоны проектирования, и знание того, что они называют, может облегчить их описание.

В любом случае, я бы посоветовал вам идти вверх, а не вниз. Вместо того, чтобы расширять Node и пытаться каким-то образом заставить APIData туда, у вас может быть отдельный объект, который состоит из Node и APIData объектов и выполняет свою индивидуальную работу через них.

Когда PHP 5.4 выйдет со своими чертами, это будет намного проще.