Само по себе применение ООП не означает, что разработчик застрахован от возможности создания непонятного, запутанного кода, который тяжело поддерживать. Чтобы помочь всем желающим разрабатывать качественные ООП-приложения, разработаны принципы объектно-ориентированного программирования и проектирования.

SOLID (сокр. от англ. single responsibility, open-closed, Liskov substitution, interface segregation и dependency inversion) в программировании — это пять основных принципов объектно-ориентированного программирования и проектирования.

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

S Принцип единственной ответственности (The Single Responsibility Principle)
Каждый класс выполняет лишь одну задачу. Нарушение этого принципа приводит к тому, что класс отвечает за решение нескольких задач, его подсистемы, реализующие решение этих задач, оказываются связанными друг с другом. Изменения в одной такой подсистеме ведут к изменениям в другой.

O Принцип открытости/закрытости (The Open Closed Principle)
Программные сущности должны быть открыты для расширения, но закрыты для модификации.

L Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы. Смысл этого принципа заключаются в том, чтобы классы-наследники могли бы использоваться вместо родительских классов, от которых они образованы, не нарушая работу программы. Если оказывается, что в коде проверяется тип класса, значит принцип подстановки нарушается. Наследующий класс должен дополнять, а не изменять базовый.

I Принцип разделения интерфейса (The Interface Segregation Principle)
Много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения. Создавайте узкоспециализированные интерфейсы, предназначенные для конкретного клиента. Клиенты не должны зависеть от интерфейсов, которые они не используют.

D Принцип инверсии зависимостей (The Dependency Inversion Principle)
Объектом зависимости должна быть абстракция, а не что-то конкретное. Абстракции не должны зависеть от деталей. Наоборот, детали должны зависеть от абстракций. Модули верхних уровней не должны зависеть от модулей нижних уровней. Соответственно, модули и верхних и нижних уровней должны зависеть от абстракций.
В процессе разработки программного обеспечения существует момент, когда функционал приложения перестаёт помещаться в рамках одного модуля. Когда это происходит, нам приходится решать проблему зависимостей модулей. В результате, например, может оказаться так, что высокоуровневые компоненты зависят от низкоуровневых компонентов.

Среди других принципов можно выделить следующие:

DRY (сокр. от англ. Don’t repeat yourself). Это принцип разработки программного обеспечения, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования. Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы». Когда принцип DRY применяется успешно, изменение единственного элемента системы не требует внесения изменений в другие, логически не связанные элементы. Те элементы, которые логически связаны, изменяются предсказуемо и единообразно. Нарушения принципа DRY называют WET — «Write Everything Twice» (рус. Пиши всё по два раза) или «We enjoy typing» (Нам нравится печатать). Это игра английских слов «dry» (рус. сухой) и «wet» (рус. влажный).

GRASP (англ. general responsibility assignment software patterns — общие шаблоны распределения ответственностей) — шаблоны, используемые в объектно-ориентированном проектировании для решения общих задач по взаимодействию классов и объектов. В соответствии с этим принципом, вместо того, чтобы изобретать велосипед, используем известные шаблоны проектирования.

KISS (акроним для Keep it simple, stupid) — принцип проектирования, принятый в ВМС США в 1960. Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности. Этот принцип запрещающает использование более сложных средств, чем необходимо.

YAGNI (англ. — «You aren't gonna need it»; «Вам это не понадобится») — процесс и принцип проектирования программного обеспечения, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.

--