Как вызывать расширенные классы?

Question

[Михаил]

Для работы с API Magento 2 сделал (сгенерировал) себе либу https://github.com/springimport/swagger-magento2-client Сам проект на yii2.
Возникла необходимость расширить базовые методы. Естественно что трогать код не хочется, поэтому расширение начал в "новом слое" - отдельных классах, наследованных от базовых в либе. В проекте теперь часть кода использует базовые классы, а часть - расширенные. Решил что пора использовать DI. В этом случае в проекте будет только зависимость на интерфейс. По умолчанию в либе нет интерфейсов и, наверное, придется генерировать их вручную и приписывать каждому классу. Но другого решения в не вижу.
Удовлетворяет ли такое расширение принципам SOLID и адекватности?
А если понадобится сделать кэширование методов, то прописываю кэширующий класс для интерфейса и все?

Answer 1

[Fortop]

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

В этом случае не нужно ничего генерировать и прописывать вручную.

Что касается вопроса оценки со стороны SOLID, то причём тут это?

Comments

[Михаил]

Я решил делать так: везде использую базовые классы. Когда возникает необходимость их расширить, то я расширяю и добавляю "предпочтение" на новый класс. Таким образом везде где использовался базовый класс будет использован новый. Интерфейсы пока решил не делать.

Мне кажется что такое расширение не противоречит принципу расширения, но не изменения в SOLID. Но вот на счет кэширования не уверен. Ведь в этом случае происходит как раз замена оригинального метода хотя с тем же поведением.

[Fortop]

Михаил:
Что такое "предпочтение"?

[Михаил]

Fortop: Это переопределение класса или интерфейса (di).

[Fortop]

Михаил: Мгм, мгм...

Может лучше говорить о контрактах и сигнатурах?

И, да, основной принцип почему рекомендуется опираться на интерфейсы - это то, что они не зависят от конкретной реализации. Т.е. производить подмену достаточно легко.

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