Как использовать Принцип подстановки Барбары Лисков применительно к PHP?

Question

[Guy Fawkes]

В PHP отсутствует Double Dispatching и перегрузка методов (и в ответ на отличающуюся от базового класса/интерфейса сигнатуру он вывалится с ошибкой). Но решить проблему как-то нужно: пусть у нас есть некие классы, которые могут быть обработаны разными хендлерами:

interface IService
{
  public function methodC();
}

class Service1 implements IService 
{
   public function methodA() {}

   public function methodC() {}
}

class Service2 implements IService
{
   public function methodB() {}

   public function methodC() {}
}

Сервисы должны имплементировать какие-то общие методы, но помимо этого у них есть и специфичные методы.

При этом интерфейс подобных хендлеров хотелось бы иметь общий вида

interface IHandler
{
  public function handle(IService $service);
}

class Handler1 implements IHandler
{
  public function handle(IService $service) {}
}

class Handler2 implements IHandler
{
  public function handle(IService $service) {}
}

Однако каждый из хендлеров может не работать с конкретной реализацией сервиса.

Я рассматривал следующие варианты решения:
- Visitor. Предполагает наличие в каждом из хендлеров методов типа handleService1(Service1 $service) и handleService2(Service2 $service), при этом один из методов остается пустым
- Массив маппинга, который говорит, какой хендлер может обрабатывать какой из сервисов. Интерфейсы хендлеров и интерфейсы сервисов отделяются, что соответствует сегрегации интерфейсов, однако получаем следующие проблемы: этот массив можно где-то хранить или наполнять в каком-то классе из конфигурационного файла, что исключает возможный тайп хинтинг как в каком-либо методе, так и при итерации по коллекции хендлеров и приводит к хранению несколькихт коллекций отличающихся интерфейсом хендлеров, а также нескольким методам вида addHandler1, addHandler2.
- Передача в хендлеры не самих инстансов сервисов, а неких результатов их работы. Приводит к передаче либо слишом больших и переполненных геттерами объектов, либо просто массивов, что никак не способствует хинтингу и удобству написания и поддержки кода

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

Answer 1

[Сергей Протько]

В PHP отсутствует Double Dispatching и перегрузка методов

Double Dispatch в PHP:

class Foo {
    // ...
    public function makeSomeStuff(Bar $bar)
    {
         $bar->doStuff($this->someData); // double dispatch!
    }
}

Перегрузка методов:

class Foo {
    public function foo() {}
}

class Bar extends Foo {
    public function foo() {} // перегружен!
}

и в ответ на отличающуюся от базового класса/интерфейса сигнатуру он вывалится с ошибкой

то что вы хотели сделать называется ad-hoc полиморфизм, и он есть из коробки в любом языке программирования с динамической типизацией. Достаточно просто не указывать явно сигнатуру, все довольно просто) Ну и да, минус этого то что это не явно и в рантайме. Для языков со статической типизацией явная "перегрузка" нужна только для того что бы компилятор мог построить таблицы диспетчеризации вызовов.

Но решить проблему как-то нужно

Перегрузка методов в наследниках с изменением сигнатуры это как раз таки нарушение принципа подстановки барбары лисков (LSP для сокращения).

> Сервисы должны имплементировать какие-то общие методы, но помимо этого у них есть и специфичные методы.

выносите "общие методы" в отдельный сервис и шарьте его как зависимость. Тогда у всех сервисов будут только специфичные методы и тогда будет достигаться принцип единой ответственности (который характеризуется как "у каждого объекта должна быть только одна причина для возможных изменений").

p.s. венгерская нотация - это ужас. Все эти префиксы и суффиксы которые показывают кто есть тип (интерфейс, абстрактный класс) это вещи которые ломают всю красоту идеи полиморфизма и абстракции. Если хотите можем об этом пообщаться отдельно.

Однако каждый из хендлеров может не работать с конкретной реализацией сервиса.

Значит полиморфизм в нашем случае пошел погулять. Есть куча решений данной проблемы, в частности Chain of responsibility.

> Visitor. Предполагает наличие в каждом из хендлеров методов типа handleService1(Service1 $service) и handleService2(Service2 $service), при этом один из методов остается пустым

зачем так усложнять то? У вас должен быть снаружи только один публичный метод а внутри уже реализация сама разберется. Ну то есть если хотите - можете внутри сделать два приватных метода но это так же странно.

> Массив маппинга, который говорит, какой хендлер может обрабатывать какой из сервисов.

Опять же излишнее усложнение.

Короче ваша проблема в том что у вас есть некие сервисы, с неким интерфейсом, которые по факту делают совсем разные вещи. То есть они априори не могут принадлежать к одному и тому же типу. Ну и нарушение LSP на лицо, вы не можете в коде заменить одну реализацию сервиса другой.

Дальнейшие варианты возможны только после того, как вы опишите на высоком уровне что вам нужно сделать. Ну то есть не то к чему вы пришли а почему вы к этому пришли и какая задача стояла изначально.

Comments

[Guy Fawkes]

В вашем примере вы называете переопределение метода перегрузкой, а вызов метода переданного класса в методе иного класса - double dispatch'ем, что достаточно далеко от их определений.

> выносите "общие методы" в отдельный сервис и шарьте его как зависимость

Зачем? Можно так сделать, но не вижу ничего плохого, если есть ряд методов, связанных одной задачей. Проблема-то совсем не в методах сервиса, а в методах хендлеров:

> Есть куча решений данной проблемы, в частности Chain of responsibility.

Собственно о этих решениях и хотелось бы узнать подробнее.

> У вас должен быть снаружи только один публичный метод а внутри уже реализация сама разберется

Каким образом? Путем отказа от хинтинга и выбора необходимой обработки через instanceof?

> Короче ваша проблема в том что у вас есть некие сервисы, с неким интерфейсом, которые по факту делают совсем разные вещи.

Хендлеры делают разные вещи, это, так сказать, источник проблемы. Зависимость в сервисах, как вы описали выше, возможно внедрить, но это уже меньшая проблема, так как все же сервисы имеют общее.

Проблема на высоком уровне такова:
- Имеем пару сервисов, которые могут что-то искать, в API и на десктопе, детали реализации и перечень необходимых возможностей у них немного отличается
- Результаты работы сервисов нужно прогнать через ряд "рендереров", каждый из которых может немного добавить к результату работы. При этом одним рендерерам необходимо вызывать специфичные для сервиса методы, а некоторым достаточно общего функционала.

[Сергей Протько]

Guy Fawkes:

В вашем примере вы называете переопределение метода перегрузкой, а вызов метода переданного класса в методе иного класса - double dispatch'ем, что достаточно далеко от их определений.

повторюсь еще раз. В языках с динамической системой типов "явная" перегрузка и "явная" двойная диспетчеризация не нужна так как диспетчеризация и так происходит в рантайме.

Зачем? Можно так сделать, но не вижу ничего плохого, если есть ряд методов, связанных одной задачей.

Зависит от этой "одной задачи" конечно, но все во имя Single Responsibility. Маленькие специфичные вещи проще менять.

Хендлеры делают разные вещи, это, так сказать, источник проблемы.

наиболее похожий на ваш случай пример можно наблюдать в реализации Command Bus. Там так же есть хэндлеры и они выполняют совершенно разные вещи. Но у них у всех один и тот же интерфейс.

Проблема на высоком уровне такова:

1) у сервисов которые что-то ищут одинаковый интерфейс, так? Можно ли завернуть результаты их работы в объекты?
2) мы можем вынести "специфичные" вещи прямо в объект с результатом? Таким образом спрятав детали поближе к реализации и сохранив "единнобразие" интерфейса?
3) мы можем применить тот самый double dispatch?

[Guy Fawkes]

Сергей Протько: > Зависит от этой "одной задачи" конечно, но все во имя Single Responsibility
В данном случае одна задача и есть единая ответственность. Приводить все к уровню "одна ответственность - один метод", на мой взгляд, не всегда возможно.

> в реализации Command Bus
Их довольно много. Какую из них советуете посмотреть?

> у сервисов которые что-то ищут одинаковый интерфейс, так?
Да

> Можно ли завернуть результаты их работы в объекты?
Это и возможные проблемы, которые я вижу, перечислено в третьем варианте решения, который я рассматривал

> мы можем применить тот самый double dispatch?
Я не понимаю, как вы его видите в PHP и применительно к объектам с результатом.

[Сергей Протько]

Guy Fawkes: попробую выразить свою мысль более явно. И да, с double dispatch я несколько все же был не прав.

Начнем с перегрузки методов и почему "она не нужна" в php в том виде в котором существует в таких языках как Java.

class SimplePrinter implements Printer
{
    public function print(Circle $shape) {}
    public function print(Rectangle $shape) {}
    public function print(Square $shape) {}
}

так как в PHP вся диспетчеризация и так происходит в рантайме, у нас будет что-то типа:

class SimplePrinter implements Printer
{
    public function print(Shape $shape) 
    {
           $shapePrinter = [
                Circle::class => [$this, 'printCircle'],
                Rectangle::class => [$this, 'printRectangle'],
                printSquare::class => [$this, 'printSquare'],
           ][get_class($shape)] ?? null;

           if (null === $shapePrinter) {
                 // throw exception
           }

           $shapePrinter($shape);
    }
    private function printCircle(Circle $shape) {}
    private function printRectangle(Rectangle $shape) {}
    private function printSquare(Square $shape) {}
}

Минусы очевидны. Если мы добавим форму, нам придется поправить все реализации принтера. Налицо нарушение SRP. Да и код не очень то красивый, теряется информация для статического анализа.

Double Dispatch в том виде в котором он может существовать в PHP:

interface Printer
{
    public function printRectangle(Rectangle $shape);
    public function printCircle(Rectangle $shape);
    // ...
}
abstract class Shape
{
    abstract public function print(Printer $printer);
}

class Rectangle extends Shape
{
    public function print(Printer $printer)
    {
         $printer->printRectangle($this);
    }
}

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

Минусы у нас все еще остаются. Если добавляется новая форма, нам надо поправить интерфейс и все реализации. Зато вся информация о типах на месте.

Далее мы либо должны менять интерфейс, либо ифы и частичная потеря информации о типах. Для отдельных пакетов последнее не столь страшно если вы покрываете код тестами потому я бы пошел по этому пути, раз нам важна читабельность.

Можно вынести логику печати отдельных шэйпов в отдельные сервисы и применить chain of responsibilities.

interface Printer
{
    public function supports(Shape $shape);
    public function print(Shape $shape);
}

class DefaultPrinter implements Printer
{
     private $printers;
     public function __construct(array $printers) { $this->printers = $printers; }

     public function supports(Shape $shape) { return true; }
     public function print(Shape $shape)
     {
           foreach ($this->printers as $printer) {
                if ($printer->supports($shape)) {
                     return $printer->print($shape);
                }
           }
     }
}

class CircleDefaultPrinter implements Printer
{
    public function supports(Shape $shape)
    {
          return $shape instanceof Circle;
    }

    public function print(Shape $shape) 
    {
        // ...
    }
}

но это опять же много лишнего кода. Для упрощения можно вынести логику печати прямо в объекты Circle.

То есть в данном случае либо мы соблюдаем SRP либо LSP. Если честно вариант с double dispatch и "много методов в интерфейсе" мне нравится больше всего.

В языках типа Python это решается так же при помощи создания новых функций:

printer = Dispatch();
printer.add_call((Circle), default_circle_printer)
printer.add_call((Rectangle), default_rectangle_printer)

printer(shape) // multiple dispatch

тоесть информацией о типах мы так же жертвуем по сути (разве что наш статический анализатор умеет в случае Python такие штуки распознавать).

[Guy Fawkes]

Сергей Протько: ну вот и я пришел только к тому, что в том или ином месте придется жертвовать типизацией, либо применять instanceof.
По поводу цепочки ответственности - я по сути и написал 1 к 1 ваш же код, но да, это действительно цепочка (хотя у каждого ее элемента и нельзя явно задать следующий, все задается порядком элементов в массиве)

[Павел Волынцев]

interface Printer
{
    public function printRectangle(Rectangle $shape);
    public function printCircle(Rectangle $shape);
    // ...
}

Плохой интерфейс. Он не любит треугольники.

[Сергей Протько]

Павел Волынцев: троеточия там к чему как вы думаете?

[Павел Волынцев]

Сергей Протько: :)