Принципы проектирования
YAGNI
«You Ain’t Gonna Need It» — «Вам это не понадобится»
Процесс и принцип проектирования ПО, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.
DRY
Don’t repeat yourself - не повторяйте себя
Это принцип разработки программного обеспечения, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования. Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы». Он был сформулирован Энди Хантом и Дэйвом Томасом в их книге The Pragmatic Programmer.
KISS
Keep It Stupid Simple (Keep it short and simple / Keep it simple, stupid) - Придерживайся простоты
Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности.
SLAP
Single Level of Abstraction Principle - «Принцип единого уровня абстракций»
Диктует нам, как мы должны организовывать свой код (в частности, функции), чтобы он оставался поддерживаемым.
SOLID
SOLID это аббревиатура пяти основных принципов проектирования в объектно-ориентированном программировании, предложенных Робертом Мартином:
- Single responsibility — принцип единственной ответственности
- Open-closed — принцип открытости / закрытости
- Liskov substitution — принцип подстановки Барбары Лисков
- Interface segregation — принцип разделения интерфейса
- Dependency inversion — принцип инверсии зависимостей
SRP
Single Responsibility Principle - «Принцип единой ответственности», SRP
В чем-то похож на SLAP, но направлен на объектно-ориентированное программирование. Этот принцип гласит, что объекты и классы (а также функции и методы) нужно организовывать так, чтобы каждый из них имел только одну зону ответственности.
OCP
Open-Closed Principle - «Принцип открытости-закрытости»
Требует, чтобы код был открыт для новых, будущих дополнений, и чтобы при их добавлении не приходилось изменять уже написанный код. Этот принцип в большей степени затрагивает вопросы архитектуры, чем кода как такового.
LSP
Liskov Substitution Principle - «Принцип подстановки Барбары Лисков»
Назван в честь его автора, Барбары Лисков. Суть его в том, что каждый подтип должен дополнять, а не заменять базовый тип.
ISP
Interface Segregation Principle - «Принцип разделения интерфейса»
Это еще один принцип, затрагивающий тему организации кода.
DIP
Dependency Inversion Principle - «Принцип инверсии зависимостей»
Как и OCP, DIP, в большей степени касается общей архитектуры кода. Фактически, это один из самых важных принципов проектирования архитектуры кода.
код должен быть написан так, чтобы детали реализации (например, пользовательский интерфейс или база данных) зависели от основной логики (правил бизнеса), а не наоборот.
все эти зависимости не должны быть прямыми. Их нужно абстрагировать при помощи интерфейсов, чтобы основная логика работала со всем, что бы ей ни передали, требуя для этого только какой-нибудь простой «мост».
CQS
Command-Query Separation - разделения команд и запросов
Все функции некоторого интерфейса должны быть или некоторыми запросами, возвращающими ответ, или командами, изменяющими состояние системы, но не одновременно. Никогда функция не должна возвращать ответ и изменять состояние системы одновременно.
LoD
Law of Demeter - закон Деметры
Говорит нам примерно следующее: «не разговаривай с незнакомцами и не создавайте ненужных зависимостей». Закон Деметры — это, скорее, рекомендация, о которой стоит помнить.
IoC
Inversion of Control - Инверсия управления
Важный принцип объектно-ориентированного программирования, используемый для уменьшения зацепления (связанности) в компьютерных программах. Он подразумевает что ходом программы управляет внешний, по отношению к ней, фреймворк. Dependency Injection (DI) является частью IoC.
DI
Dependency Injection - Внедрение зависимости
Стиль разработки программного кода, когда в зависимости класса не создаются им напрямую, а внедряются из вне. При этом уменьшается связанность кода, но теряется контроль над созданием и временем жизни объектов, от которых зависит класс.
DAMP
Descriptive And Meaningful Phrases - Описательные и значимые фразы
Принцип написания модульных тестов таким образом, чтобы происходящее в них можно было понять без дополнительных комментариев и документации. Достигается использованием описательных имен и допускает небольшие нарушения принципа DRY при необходимости.
AAA (3A)
Arrange Act Assert - Условие, Действие, Проверка
Это шаблон для форматирования Unit тестов. Обозначающий разделения теста на 3 части
- Arrange - все необходимые подготовки и входные данные
- Act - собственно, вызов того метода который вы тестируете
- Assert - проверка, что метод делает то что надо
GRASP
General Responsibility Assignment Software Patterns - общие шаблоны распределения ответственностей
Это набор шаблонов, используемых в объектно-ориентированном проектировании для решения общих задач по назначению ответственностей классам и объектам.
Information Expert
Информационный эксперт – класс, сосредотачивающий информацию о конкретной предметной области. Операции над ней также передаются в его ответственность. Например, Aсcount хранит информацию о счете и может предоставить выписку с него.
Creator (Создатель)
Классы, создающие другие классы. Это может быть фабрика, пул и т.д.
Controller (Контроллер)
Объект, который несет в себе управляющие функции (не путать с бизнес-логикой приложения). Яркий пример - Контроллер в шаблоне MVC.
Low Coupling (Низкая связанность)
Данный принцип декларирует программирование на основе интерфейсов и абстракций, а не конкретных реализаций. Это способствует упрощению повторного использования кода, его поддержки, модификации, тестированию.
High Cohesion (Высокое сцепление)
Методы внутри классы должны быть тесно связаны между собой. Это еще одна гарантия, того что класс обеспечивается реализацию четко определенной единственной ответственности. Классы с низким сцеплением легко можно разделить на несколько.
Pure Fabrication (Чистая выдумка)
Представляет собой классы, которые не отображают реальных объектов из предметной области приложения. Например, репозиторий, используемый для сохранения и загрузки объектов из хранилища.
Indirection (Посредник)
Необходим для устранения сильной связанности нескольких классов. На него ложится ответственность организации взаимодействия между ними. К слову, Контроллер в MVC является также посредником между Моделью и Представлением.
Protected Variations (Защищенные изменения)
Данный принцип предполагает определение объектов, которые наиболее вероятно будут подвержены изменениям, и применение мер, по минимизации влияний этих изменений на остальные части приложения.
Polymorphism (Полиморфизм)
Возможность объектов с одинаковой спецификацией иметь различную реализацию.
OR
Occam’s Razor - Бритва Оккама
Суть в том, что не нужно создавать лишние методы, классы и переменные, если в них нет нужды.
BDUF
Big Design Up Front - Глобальное проектирование прежде всего
Этот подход к разработке программного обеспечения очень важен, и его часто игнорируют. Прежде чем переходить к реализации, убедитесь, что все хорошо продумано.
APO
Avoid Premature Optimization - Избегайте преждевременной оптимизации
Преждевременная оптимизация может привести к задержкам в коде и, следовательно, увеличит затраты времени на вывод функций на рынок.
Многие считают преждевременную оптимизацию корнем всех зол.
POLA
Principle Of Least Astonishment - Принцип наименьшего удивления
Не заставляйте удивляться других программистов вашему коду. Нужно программировать просто, понятно и очевидно, чтобы любой другой специалист мог прочитать ваше творение. Имена и названия методов и классов должны нести информативность и быть лаконичными. Вызываемый метод должен соответствовать тому, для чего он вызывается и как он называется.
Источники: