Всем привет! Когда начинал изучать php, везде призывали к тому, чтобы код ни в коем случае не дублировался... Мол будешь изменять что-то и придется ползать по файлам и изменять одно и то же везде, и где-то забудется...
Но никто не упоминал о другой стороне медали...
Как вы боретесь с такой ситуацией? Когда хочется изменить этот единственный код для одной части приложения, и меняя его затрагиваются те, о которых я уже не помню. В итоге всё ломается...
По идее код, который не дублируется - должен быть абстрактным, чем больше в нем конкретики - тем больше косяков при изменении... лучше сделать больше входных параметров, задав необязательным из них по умолчанию нулевые значения или стандартные для вашего сценария, с возможностью переопределить их при вызове, да, класс станет жирнее немного и при вызове методов нужно будет передать больше значений, зато класс будет универсален и при изменении каких-то конструкций не случится ахтунга...
Александр, и изменяя этот общий, для разных частей приложения, код, затрагиваются те части приложения, которые я не хотел менять, но которые связаны общим НЕ дублирующимся кодом.
Сложно ответить сумбурный вопрос.
Но если в кратце.
Когда хочется изменить этот единственный код
Это не означает что у вас весь уникальный код в одной функции, методе или объекте, их может быть сотни (максимально не зависимых друг от друга) как конструктор или луковица объеденные в один функционал (S в абривиатуре SOLID) поскольку функционал может разный то и состовляюшие (элементы) могут по разному комбинироваться и поэтому когда хочется что то поменять в идеале вы заходите в метод длинною около 20 строк и спокойно меняете не боясь что то сломать.
Есть метод getWhatever(), который общий для всех.
Вы можете в конкретном классе реализовать свой getWhatever(), в котором написать parent::getWhatever() и модифицировать общий результат до частного случая.
getWhatever() не должен быть private и final
SOLID.
DRY - хортшая практика, но не везде применима. Например у вас есть две в чем-то похожие сушности, далеко не факт что их стоит наследовать от общего родителя иили объединять сервисы что с ними работают. При написании тестов DRY может быть даже анти практикой.
