Принципы. SOLID.

SOLID - акроним из первых букв названий пяти принципов разработки программного обеспечения, названных Робертом Мартином в начале 2000-х.

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

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

Принцип единственной ответственности (Single responsibility principle, SRP).

На каждый объект должна быть возложена одна единственная обязанность.

Другими словами — конкретный класс должен решать конкретную задачу — ни больше, ни меньше. Не должно быть больше одной причины для изменения класса, иначе получим хрупкий дизайн: правим одно - ломаем другое. Можно применить не только к классам, но и к методам, модулям, подсистемам и системам.

Принцип открытости/закрытости (Open-closed, OCP)

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

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

Принцип подстановки Барбары Лисков (Liskov Substitution Principle, LSP)

Объекты в программе могут быть заменены их наследниками без изменения свойств программы.<.p>

Наследующий класс должен дополнять, а не замещать поведение базового класса.

Принцип разделения интерфейса (Interface Segregation Principle, ISP)

Клиенты не должны зависеть от методов, которые они не используют.

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

Принцип инверсии зависимостей (Dependency Inversion Principle, DIP)

• Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
• Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Другими словами: зависимости должны строится на абстракциях, а не на конкретных реализациях.