Все данные, входящие в систему должны иметь одно представление.
Следование принципу DRY всегда приводит к декомпозиции сложных алгоритмов на простые функции. А декомпозиция сложных операций на более простые (и повторно используемые) значительно упрощает понимание программного кода. Повторное использование функций, вынесенных из сложных алгоритмов, позволяет сократить время разработки и тестирования новой функциональности.
Возможности, не описанные в системе, не должны реализовываться.
- Заказчик не должен оплачивать ненужный ему функционал;
- Разработчик не должен принимать решения за заказчика;
- Бесплатных функций в программных продуктах не бывает;
Нежелательные последствия:
- Тратится время, которое могло бы быть задействовано на нужные функции;
- Новые функции должны быть отлажены, задокументированы и сопровождены;
- Новая необязательная функциональность может ограничивать функциональность, которая будет добавлена в будущем;
- Антипаттерн SoftCode (малейшее действие требует конфигурации);
- Код должен иметь наименьшее необходимое количество классов и методов;
- Не имеет смысла реализовывать дополнительные функции без необходимости;
- Не стоит перегружать интерфейс теми опциями, которые не будут нужны большинству пользователей;
- Бессмысленно делать реализацию сложной бизнес-логики, которая учитывает абсолютно все возможные варианты;
- Не имеет смысла беспредельно увеличивать уровень абстракции;
- Бессмысленно закладывать в проект избыточные функции «про запас»;
- Не стоит подключать огромную библиотеку, если вам от неё нужна лишь пара функций;
- Абсолютная математическая точность или предельная детализация нужны не всегда;
- Принципы простого дизайна от Кента Бека (все тесты запускаются, отсутствует дублирование логики, явны намерения программиста);
S - Single responsibility- принцип единственности ответственности;O - Open-closed- принцип открытости/закрытости;L - Liskov substitution- принцип подстановки Барбары Лисков;I - Interface segregation- принцип разделения интерфейсов;D - Dependency inversion- принцип инверсии зависимостей;
Позволяют строить на базе ООП масштабируемые и сопровождаемые программные продукты с понятной бизнес-логикой.
Каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс. Все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.
Следование принципу:
- Разделение больших классов с большим количеством функционала;
- Слияние мелких классов и объединение в одном классе однотипной функциональности;
- Упрощает поддержку и расширение классов;
- Антипаттерны - типа GoD object;
- Требует осмысленного отношения;
- Active Record нарушает SRP;
Программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения. Это означает, что эти сущности могут менять свое поведение без изменения их исходного кода.
Однажды разработанная реализация класса в дальнейшем требует только исправления ошибок, а новые или изменённые функции требуют создания нового класса. Реализация интерфейса может быть унаследована и переиспользована, но интерфейс может и измениться в новой реализации.
Полиморфный принцип открытости/закрытости:
- Основывается на строгой реализации интерфейсов и на наследовании от абстрактных базовых классов или на полиморфизме.
- Созданный изначально интерфейс должен быть закрыт для модификаций, а новые реализации как минимум соответствуют этому изначальному интерфейсу, но могут поддерживать и другие, более расширенные.
Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы. Код обрабатывающий базовый класс, должен иметь возможность обрабатывать любого наследника базового класса.
Частое нарушение - бросание исключений в неподдерживаемых методах.
Много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения. Клиенты не должны зависеть от методов, которые они не используют.
- в формулировке Роберта Мартина декларирует, что клиенты не должны зависеть от методов, которые они не используют. То есть если какой-то метод интерфейса не используется клиентом, то изменения этого метода не должны приводить к необходимости внесения изменений в клиентский код.
- Следование принципу ISP заключается в создании интерфейсов, которые достаточно специфичны и требуют только необходимый минимум реализаций методов
- Избыточные интерфейсы, напротив, могут требовать от реализующего класса создание большого количества методов, причём даже таких, которые не имеют смысла в контексте класса.
- перекликается с принципом единственной ответственности
- снижает сложность поддержки и развития приложения
- Чем проще и минималистичнее используемый интерфейс, тем менее ресурсоёмкой является его реализация в новых классах, тем меньше причин его модифицировать
- Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
- Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Все классы должны использоваться через интерфейсы (при случаях, когда один класс использует другой).