Когда НЕ нужно использовать SOLID?

Читал, что SOLID - это хорошие рекомендации, проверенные временем, но пихать их 
каждый проект не стоит. Гуглил примеры, когда его применять не нужно и не нашел. Скажите, в каких случаях применение SOLID неоправданно?
    

Ответы

Ответ 1

Касательно любого паттерна/принципа разработки можно сказать:


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


Также имеет место быть неполное или даже некорректное понимание используемых принципов/паттернов
И возможно даже возведение в абсолют, когда буквальное следование им становится превыше здравого смысла.

Таким образом вопрос не в том, когда не нужно использовать SOLID, а в том, насколько использовать каждый из его принципов в своем, конкретном случае.

S - Single Responsibility Principle

Класс должен иметь только одну ответственность

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

O - Open/Closed Principle

Программные сущности должны быть открытыми для расширения, но закрытыми для модификации

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

L - Liskov Substitution Principle

Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы

Ради обеспечения этого принципа иногда приходится использовать сомнительные решения
К примеру класс Ellipse имеет подкласс Circle, который является случаем Ellipse с одинаково
длиной по осям X и Y. В соответствии с принципом, подкласс Circle обязан реализовать поведение родителя. Если Ellipse содержит метод stretchX, позволяющий модифицировать длину по оси X, то класс Cirlce также обязан реализовать это поведение, несмотря на то, что для круга это невозможно.

I - Interface Segregation Principle

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

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

D - Dependency Inversion Principle

Принцип инверсии зависимости

Возьмем ситуацию когда объект класса A вызывает методы объекта класса B. Значит 
зависит от B. С применением этого принципа, объект типа B должен быть инстанциирован вне A и передан как зависимость в A. Без применения этого принципа, это может сделать сам объект A, что во многих случаях гораздо удобнее.



Основано на http://www.tonymarston.net/php-mysql/not-so-solid-oo-principles.html. В процессе чтения узнал много нового. Холивар приветствуется )


Ответ 2

Как и любой инструмент, принципы проектирования нужно применять с умом.

Можно выделить два случая, когда применение принципов проектирования приведет к увеличению проблем, и не приведет ни к чему хорошему.


YAGNI

Подробности — в ответе на вопрос «Нарушает ли OCP и DIP (из SOLID) принцип YAGNI?».

Принципы проектирования предназначены для смягчения определенной проблемы разработк
(да, именно «смягчения», но не решения проблемы), добавляя при этом свои собственные проблемы.

Поскольку иногда проблемы программисты придумывают себе сами, то следование (особенн
буквальное) принципам проектирования приведет к перекосу дизайна, не решая при этом реальной проблемы.

Другими словами, чрезмерное увлечения принципами проектирования может привести 
переусложненному решению там, где эта сложность не нужна.
«over»-SOLID

Подробнее в статье «О принципах проектирования».

Есть ряд типовых паталогических случаев использования SOLID-принципов:


Anti-SRP – Принцип размытой ответственности. Классы разбиты на множество мелких классов, в результате чего логика размазывается по нескольким классам/модулям.
Anti-OCP – Принцип фабрики фабрик. Дизайн является слишком обобщенным и расширябельным, выделяется слишком большое число уровней абстракции.
Anti-LCP – Принцип непонятного наследования. Принцип проявляется либо в чрезмерно
количестве наследования, либо в его полном отсутствии, в зависимости от опыта и взглядов местного главного архитектора.
Anti-ISP – Принцип тысячи интерфейсов. Интерфейсы классов разбиваются на слишко
большое число составляющих, что делает их неудобными для использования всеми клиентами.
Anti-DIP – Принцип инверсии сознания или DI-головного мозга. Интерфейсы выделяютс
для каждого класса и пачками передаются через конструкторы. Понять, где находится логика становится практически невозможно.