Существуют ли исключения для ТВЕРДОГО принципа?

Question

Я пытаюсь применить принципы SOLID в дизайне класса моего проекта. Существуют ли исключения из принципов SOLID? Нужно ли применять этот принцип ОПРЕДЕЛЕННО. Например, я подготовил фабричный класс.

Этот класс не соответствует OCP.
В будущем могут потребоваться производители нового типа, и я должен добавить новый блок if if.
Является ли мой дизайн плохим?
Или есть исключения принципов SOLID, которые не упоминаются слишком часто?
Я не уверен, но мой пример соответствует «Стратегическому закрытию» OCP? Если у вас есть другие примеры исключений SOLID, я думаю, что это было бы полезно для дизайнеров.

Answer 1

Принцип Open-Closed важен и полезен, но это не то, что следует применять вслепую для всех классов и всех модулей. В некоторых случаях создание абстракций, которые расширяют расширяемость, просто не стоит того, потому что не ожидается никаких расширений. В других случаях мы можем ожидать, что требования изменятся, но мы не уверены, какие изменения ожидать, или мы не уверены в других требованиях, поэтому мы предпочитаем отложить решение и начать с более простого модуля которая не учитывает ОКР.

Answer 2

SOLID Принципы - это всего лишь руководящие принципы. Вы можете прийти к решению своей проблемы с помощью или без использования этих принципов.

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

Если вы действительно думаете, что ваш класс не должен быть изменен, тогда используйте только Open/Closed principle. Как правило, я не вижу никаких проблем в модификации существующих классов Factory для добавления новых типов.

Ниже трех принципов действительно полезны для разработки решения

Interface_segregation_principle: клиент не должен быть вынужден зависеть от методов не использует

Не используйте жирные интерфейсы в вашем коде, где классы реализации должны переопределить неиспользуемые или несвязанные методы. Создавайте гранулярные интерфейсы и создавайте классы, которые реализуют эти гранулированные интерфейсы. Связанные SE вопрос:

Interface Segregation Principle- Program to an interface

Dependency_inversion_principle: Это хороший принцип. Вы должны программировать интерфейс, а не реализацию.

Liskov_substitution_principle: Используйте этот принцип, если вам нужно динамически изменять свою реализацию во время выполнения. Если ваше приложение не изменит его реализацию, вам может не потребоваться эта функция.

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

Answer 3

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

Как ваш пример, я возьму OCP. Ключевой концепцией OCP является то, что если ваш проект на 100% соответствует OCP, любой другой (может быть, посторонний, новый участник) может делать кодирование, не глядя на текущий код, а просто глядя на вашу документацию api (об обнаруженном методе) что действительно облегчает жизнь этого человека. А также нет необходимости тестировать существующий код снова и снова, потому что для существующего кода не будет никаких изменений. Но действительно есть ситуации, когда нам приходится нарушать OCP.

Ex:.

• новое требование (необходимо реализовать внутри существующего класса),

• Исправлена ​​ошибка, исправить

• ограниченной рамки поддержки (любая структура MVC) и т.д. .

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

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

Ex:

• Прогулка по левой стороне. (Чтобы вы могли видеть входящие транспортные средства)

• Пересекать только на пешеходном переходе (чтобы транспортные средства могли видеть вас четко, и они останавливались).

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

Я думаю, вы получили представление о принципах. :)

Answer 4

Я думаю, что я нашел первое, что нужно учитывать при написании кодов. Это UNIT TESTS.Согласные принципы, шаблоны проектирования и т. Д. - это инструменты, которые помогают делать модульные тесты. По словам меня, любой непредвиденный программист (например, я) должны применять ИСПЫТАНИЯ ЕДИНИЦЫ без каких-либо исключений. Результаты тестов уже приводят к тому, что программист стремится к лучшему дизайну.