> For the complete documentation index, see [llms.txt](https://dev-ttf.gitbook.io/global-tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev-ttf.gitbook.io/global-tech/osnovnoe/gaidy/principy-solid.md).
# Принципы SOLID
### [**Определение, примеры их нарушения и их исправление по SOLID**](https://metanit.com/sharp/patterns/5.1.php)
### **SOLID**
Термин "SOLID" представляет собой акроним для набора практик проектирования программного кода и построения гибкой и адаптивной программы. Данный термин был введен 15 лет назад известным американским специалистом в области программирования Робертом Мартином
Сам акроним образован по первым буквам названий SOLID-принципов:
* **S**ingle Responsibility Principle (Принцип единственной обязанности)
* **O**pen/Closed Principle (Принцип открытости/закрытости)
* **L**iskov Substitution Principle (Принцип подстановки Лисков)
* **I**nterface Segregation Principle (Принцип разделения интерфейсов)
* **D**ependency Inversion Principle (Принцип инверсии зависимостей)
### **Single Responsibility Principle**
**Принцип единственной обязанности** (Single Responsibility Principle) можно сформулировать так:\
**У класса должна быть только одна причина для изменения**\
Под обязанностью здесь понимается набор функций, которые выполняют единую задачу. Суть этого принципа заключается в том, что класс должен выполнять одну единственную задачу. Весь функционал класса должен быть целостным, обладать высокой связностью (high cohesion).
#### **Нарушение SRP**
Допустим в классе Report написано очень много разных способов вывести репорт пользователю. Если мы поменяем Text на какой-то метод, то нам придется править каждый из методов печати, т.к. они работали напрямую с Text. Это очень долго, да и сам класс получился очень большим, а в более сложных и реальных системах нарушение SRP может окончательно запутать программиста, если он решится что-то поменять в коде. Нарушение этого принципе не столько ограничивает программиста, сколько заставляет его писать лишний код по мере роста проекта, в котором легко запутаться
#### **Применение SRP**
Проблему бесконечного наращивания и уменьшение его связанности можно решить созданием интерфейса IPrinter, и его реализацией в виде ConsolePrinter и FilePrinter. При применении SRP в начале будет казаться, что мы только усложняет код, и увеличиваем его в размерах, но по мере разработки проекта он не будет так сильно дальше усложнятся и разрастаться, по сравнению с кодом, который был написан без соблюдения SRP
### Open/Closed Principle
**Принцип открытости/закрытости** (Open/Closed Principle) можно сформулировать так:\
**Сущности программы должны быть открыты для расширения, но закрыты для изменения.**\
Суть этого принципа состоит в том, что система должна быть построена таким образом, что все ее последующие изменения должны быть реализованы с помощью добавления нового кода, а не изменения уже существующего, за исключением фикса багов и рефакторинга
### Liskov Substitution Principle
**Принцип подстановки Лисков** (Liskov Substitution Principle) представляет собой некоторое руководство по созданию иерархий наследования.\
В общем случае данный принцип можно сформулировать так:\
**Должна быть возможность вместо базового типа подставить любой его подтип.**
Фактически принцип подстановки Лисков помогает четче сформулировать иерархию классов, определить функционал для базовых и производных классов и избежать возможных проблем при применении полиморфизма.
#### **Нарушение LSP**
Класс Square перестает быть квадратом, потому что подвергается некорректным изменением под видом обычного прямоугольника, которого наследует. Решение данной ситуации – не наследовать Square от Rectangle, а делать 2 разных класса
#### 
### **Interface Segregation Principle**
**Принцип разделения интерфейсов** (Interface Segregation Principle) относится к тем случаям, когда классы имеют "жирный интерфейс", то есть слишком раздутый интерфейс, не все методы и свойства которого используются и могут быть востребованы. Таким образом, интерфейс получатся слишком избыточен Принцип разделения интерфейсов можно сформулировать так:\
**Клиенты не должны вынужденно зависеть от методов, которыми не пользуются.**\
При нарушении этого принципа клиент, использующий некоторый интерфейс со всеми его методами, зависит от методов, которыми не пользуется, и поэтому оказывается восприимчив к изменениям в этих методах. В итоге мы приходим к жесткой зависимости между различными частями интерфейса, которые могут быть не связаны при его реализации.
#### **Нарушение ISP**
ISP нарушается когда мы оставляем части интерфейса не реализованными. Это говорит нам о том, что интерфейс можно разбить на более мелкие интерфейсы
#### **Применение ISP**
### Dependency Inversion Principle
**Принцип инверсии зависимостей** (Dependency Inversion Principle) служит для создания слабосвязанных сущностей, которые легко тестировать, модифицировать и обновлять. Этот принцип можно сформулировать следующим образом:
**Классы верхнего уровня не должны зависеть от классов нижнего уровня. И те и другие должны зависеть от абстракций. Абстракции не должны зависеть от деталей класса. Детали класса должны зависеть от абстракций.**
#### **Нарушение DIP**
**Класс Book, представляющий книгу, использует для печати класс ConsolePrinter. При подобном определении класс Book зависит от класса ConsolePrinter. Более того мы жестко определили, что печать книгу можно только на консоли с помощью класса ConsolePrinter**
#### **Использование DIP**
Конкретную реализацию можно представить как абстракцию (интерфейс), и уже работать только с ней
Таким образом мы можем реализовывать конкретные классы на основании сделанной абстракции
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://dev-ttf.gitbook.io/global-tech/osnovnoe/gaidy/principy-solid.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
