> For the complete documentation index, see [llms.txt](https://appsecurity.gitbook.io/devops/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://appsecurity.gitbook.io/devops/ppc/tech/arch-services/arkhitekturnye-patterny/arkhitektura-koda.md).

# Архитектура кода

## ООП

ООП – базовый принцип построения кода

Плюсы:

* Поддержка свойств-абстракций: абстракция, наследование, полиморфизм

Минусы:

* Большое нагромождение концепций из ООП (фабрики, синглтоны, ...)&#x20;
* Легко ошибиться

## Принципы ООП

### SOLID

* Single Responsibility Principle — ваши компоненты (функции, классы, файлы) не должны решать сразу несколько задач, не превращаться в космолеты
* Open-Closed Principle — ваши компоненты (функции, классы) должны быть закрыты для модификации, но открыты для расширения. То есть, расширение функциональности не должно приводить к дописыванию внутрь ваших функций, которые не отвечают за расширяемую функциональность
* Liskov Substitution Principle — принцип замещения Барбары Лисков — если функция умеет работать с базовым классом, то она должна работать и со всеми наследниками
* Interface Segregation Principle — либо все наследники реализуют интерфейс, либо игнорируют. Можно разрешить через композицию интерфейсов. Данный принцип обозначает, что не нужно заставлять клиента (класс) реализовывать интерфейс, который не имеет к нему отношения.
* Dependency Inversion Principle — работаем с интерфейсами, а не с конкретными реализациями. Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те, и другие должны зависеть от абстракции. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

### KISS

**K**eep **i**t **s**imple and **s**tupid

* Создаем небольшие методы, выполняющие примерно то, что от них ожидают.&#x20;
* Каждый метод решает одну небольшую проблему.
* Возможно, вам не нужен ООП
* Даем полное наименование переменным, а не `a` (за буквы не платим)
* Гуглите решения
* Используйте Композицию вместо Наследования
* Длинные проверки разбиваем на отдельные переменные.

```swift
if (a > b || (c != d)) && (d < k && a < k) {
    print("Good job!")
}
// Заменяем на 
let jobIsGood = a > b || (c != d)`
let jobIsDone = (d < k && a < k)
if jobIsGood && jobIsDone {
    print("Good job!")
}
```

## Паттерны проектирования

Ресурс с описанием паттернов и с примерами на разных языках программирования: <https://refactoring.guru/>

### Паттерн Стратегия

Поведенческий паттерн проектирования, который определяет семейство схожих алгоритмов и каждый помещает в отдельный класс.

### Паттерн Прокси

Компонент, скрывающий конкретные обращения к разным ресурсам и предоставляющий единый интерфейс на основе аргументов
