различные рекомендации - это только рекомендации, не имеющие универсального характера

Там тоже может быть куча всякого.
Производители ещё те пид..ры.

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

но в любом случае удачи что-то менять в важных классах, заместо расширения их

наследование - штука хорошая, но везде должна быть мера. Если, например, наследование превышает 10 (например), то что делать? Следовать далее общеизвестным принципам или пересмотреть архитектуру?)

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

"... или пересмотреть архитектуру" - ключевой момент. Универсалий нет) Есть приближения.

ахаха, 10 расширений логики, доприближались походу)))) класс хрен пойми за что отвечает, видимо, что всё идет к пересмотрению

или

расширения удовлетворяют 3му и 1му принципам и проблем нет

🤷‍♂

сектор приз, Елена на барабане

крутите Елену

архитектура - это не только зависимости в рамках наследования

На этот счёт есть мнение программистов и мнение бизнеса. В зависимости от понимания между этими двумя ипостасями будет принято то или иное решение. Если бизнес давит сроками (ну или через А 😆) то приляпают 125ое расширение классов и сдадут задачу клиенту. Если программисты ленивые будет аналогично.
Если программисты "безумие и отвага", то будет принято решение переписать весь модуль проект, прое..ут сроки сдачи, и/или будет работать ещё хуже. Могут быть публично кастрированы впоследствии.
И очень редко просто не доводят до такого состояния, и потому вопрос не возникнет
😆

Лучше качественно и медленно, чем быстро и не очень)

бизнесу ппаааааахую еему щас надо

Но мнение бизнеса - нам нужны бабки, потому быстро и дёшево 😂