Сергей Протько: ну вот и я пришел только к тому, что в том или ином месте придется жертвовать типизацией, либо применять instanceof.
По поводу цепочки ответственности - я по сути и написал 1 к 1 ваш же код, но да, это действительно цепочка (хотя у каждого ее элемента и нельзя явно задать следующий, все задается порядком элементов в массиве)
Сергей Протько: > Зависит от этой "одной задачи" конечно, но все во имя Single Responsibility
В данном случае одна задача и есть единая ответственность. Приводить все к уровню "одна ответственность - один метод", на мой взгляд, не всегда возможно.
> в реализации Command Bus
Их довольно много. Какую из них советуете посмотреть?
> у сервисов которые что-то ищут одинаковый интерфейс, так?
Да
> Можно ли завернуть результаты их работы в объекты?
Это и возможные проблемы, которые я вижу, перечислено в третьем варианте решения, который я рассматривал
> мы можем применить тот самый double dispatch?
Я не понимаю, как вы его видите в PHP и применительно к объектам с результатом.
В вашем примере вы называете переопределение метода перегрузкой, а вызов метода переданного класса в методе иного класса - double dispatch'ем, что достаточно далеко от их определений.
> выносите "общие методы" в отдельный сервис и шарьте его как зависимость
Зачем? Можно так сделать, но не вижу ничего плохого, если есть ряд методов, связанных одной задачей. Проблема-то совсем не в методах сервиса, а в методах хендлеров:
> Есть куча решений данной проблемы, в частности Chain of responsibility.
Собственно о этих решениях и хотелось бы узнать подробнее.
> У вас должен быть снаружи только один публичный метод а внутри уже реализация сама разберется
Каким образом? Путем отказа от хинтинга и выбора необходимой обработки через instanceof?
> Короче ваша проблема в том что у вас есть некие сервисы, с неким интерфейсом, которые по факту делают совсем разные вещи.
Хендлеры делают разные вещи, это, так сказать, источник проблемы. Зависимость в сервисах, как вы описали выше, возможно внедрить, но это уже меньшая проблема, так как все же сервисы имеют общее.
Проблема на высоком уровне такова:
- Имеем пару сервисов, которые могут что-то искать, в API и на десктопе, детали реализации и перечень необходимых возможностей у них немного отличается
- Результаты работы сервисов нужно прогнать через ряд "рендереров", каждый из которых может немного добавить к результату работы. При этом одним рендерерам необходимо вызывать специфичные для сервиса методы, а некоторым достаточно общего функционала.
Philipp T: возможно, не изучал исходники этого класса. Но у него довольно удобное API, уже решающее всякие проблемы типа пропуска пустых строк, а так как человеку нужно загнать информацию в MySQL, рискну предположить, что она там в каком-то структурированном формате, и возможно даже CSV, для чего опять-таки есть метод.
В любом случае, я отписался в качестве комментария к вашему ответу, а не отдельным ответом, так как считаю этот класс, действительно, просто дополнением к нему.
По поводу цепочки ответственности - я по сути и написал 1 к 1 ваш же код, но да, это действительно цепочка (хотя у каждого ее элемента и нельзя явно задать следующий, все задается порядком элементов в массиве)