Как правильно применить полиморфизм?

Question

[Kolya Vantukh]

Допустим в системе есть такая сущность как Товарно-транспортная накладная(ттн) для каждой из службы доставок. Но в зависимости от типа ттн, одни можно редактировать в бд, другие взаимодействуют с сторонними сервисами(сдек) и у них есть соответствующая логика. Как мне лучше построить архитектуру, чтобы, к примеру, при редактировании заказа вызывать нужные методы ттн в зависимости от ее типа? (если ттн можно редактировать - редактируем, если нужно редактировать на стороннем сервисе - делаем) Делать соответствующие интерфейсы для каждого типа?(EditableInDb,DeliveryServiceSync и т.д) и потом проверять на интерфейс

if ($ttn instanceof EditableInDb) { 
//some logic
}

Что по мне, не очень хорошо, ведь различия в логике могут в перспективе разрастись и таких вот проверок на интерфейсы будет море .
Или сделать общий интерфейс для всех типов ттн и оставлять некоторые методы без реализации для типов ттн, для которых не предусмотрено такое поведение?
Что скажите? Может есть какой-нибудь третий вариант?

Comments

[Максим Федоров]

поместить логику в каждый такой объект
или в объекты одного типа, в котором будут свои такие объекты, но снаружи ведут себя одинаково

[Дмитрий]

Я бы не заморачивался и сделал бы просто свойство типа boolean, которое и будет главным основным отличием, а интерфейсы уже сами по себе.

[Adamos]

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

Answer 1

[Kolya Vantukh]

Сделал свойство типа boolean, которое и будет главным основным отличием

Answer 2

[Антон Шаманов]

реализуй шаблон strategy + decorator

Comments

[Kolya Vantukh]

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

[Антон Шаманов]

Kolya Vantukh, также можно применить шаблон наблюдатель - пусть тпп подписывается на события доступные для нее или даже mvc/hmvc - данные, их представления и бизнес логика