Skip to content

Commit 4ccdce8

Browse files
committed
Паттерны
1 parent c004def commit 4ccdce8

2 files changed

Lines changed: 186 additions & 1 deletion

File tree

docs/theory/patterns.md

Lines changed: 185 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,185 @@
1+
---
2+
sidebar_position: 13
3+
sidebar_label: ООП и паттерны
4+
title: ООП и паттерны
5+
---
6+
Справочник по ООП и паттернам проектирования
7+
8+
## Основы ООП
9+
10+
#### **Абстракция**
11+
**Что это:** Выделение главных характеристик объекта, игнорирование несущественных деталей
12+
**Зачем:** Упрощение сложных систем, работа на уровне "что делает", а не "как делает"
13+
**Как:** Создание классов и интерфейсов, которые определяют общее поведение
14+
15+
#### **Инкапсуляция**
16+
**Что это:** Объединение данных и методов в одном объекте, скрытие внутренней реализации
17+
**Зачем:** Защита данных, контроль доступа, упрощение использования
18+
**Как:** Использование модификаторов доступа (public, private, protected)
19+
20+
#### **Наследование**
21+
**Что это:** Создание нового класса на основе существующего с наследованием его свойств
22+
**Зачем:** Повторное использование кода, создание иерархий классов
23+
**Как:** Класс-наследник получает все поля и методы родительского класса
24+
25+
#### **Полиморфизм**
26+
**Что это:** Возможность объектов разных типов обрабатываться через единый интерфейс
27+
**Зачем:** Гибкость кода, работа с разными типами через общие методы
28+
**Как:** Переопределение методов в наследниках, использование интерфейсов
29+
30+
## Паттерны проектирования (от простых к сложным)
31+
32+
### Простые паттерны для начала
33+
34+
**1. Одиночка (Singleton)**
35+
- Гарантирует один экземпляр класса во всей программе
36+
- Глобальная точка доступа
37+
- *Пример:* Настройки приложения, подключение к базе данных
38+
39+
**2. Фабрика (Factory)**
40+
- Создает объекты без указания конкретного класса
41+
- Централизованное создание объектов
42+
- *Пример:* Создание документов разных типов
43+
44+
**3. Строитель (Builder)**
45+
- Пошаговое создание сложных объектов
46+
- Разделение конструирования и представления
47+
- *Пример:* Построение SQL-запросов, конфигураций
48+
49+
**4. Адаптер (Adapter)**
50+
- Преобразует интерфейс одного класса в другой
51+
- Совмещение несовместимых интерфейсов
52+
- *Пример:* Адаптер для работы со старым API
53+
54+
### Структурные паттерны
55+
56+
**5. Декоратор (Decorator)**
57+
- Динамически добавляет новую функциональность объектам
58+
- Альтернатива наследованию для расширения
59+
- *Пример:* Добавление логирования, кэширования
60+
61+
**6. Фасад (Facade)**
62+
- Простой интерфейс для сложной системы
63+
- Скрывает сложность подсистем
64+
- *Пример:* Упрощенный API для работы с базой данных
65+
66+
**7. Компоновщик (Composite)**
67+
- Объединение объектов в древовидные структуры
68+
- Единый интерфейс для отдельных объектов и их композиций
69+
- *Пример:* Файловая система, элементы интерфейса
70+
71+
### Поведенческие паттерны
72+
73+
**8. Наблюдатель (Observer)**
74+
- Один объект уведомляет других об изменениях
75+
- Слабосвязанная система
76+
- *Пример:* События в UI, уведомления
77+
78+
**9. Стратегия (Strategy)**
79+
- Определяет семейство алгоритмов
80+
- Возможность замены алгоритмов на лету
81+
- *Пример:* Разные алгоритмы сортировки, способы оплаты
82+
83+
**10. Состояние (State)**
84+
- Объект меняет поведение при изменении состояния
85+
- Альтернатива большим условным операторам
86+
- *Пример:* Состояния заказа (новый, оплачен, доставлен)
87+
88+
**11. Шаблонный метод (Template Method)**
89+
- Определяет скелет алгоритма
90+
- Некоторые шаги делегирует подклассам
91+
- *Пример:* Алгоритм приготовления напитков (кофе/чай)
92+
93+
**12. Посредник (Mediator)**
94+
- Централизованное управление взаимодействием объектов
95+
- Уменьшает связанность между компонентами
96+
- *Пример:* Диспетчер сообщений, контроллер чата
97+
98+
## Принципы разработки
99+
100+
### KISS (Keep It Simple, Stupid)
101+
- Делайте код максимально простым
102+
- Избегайте ненужной сложности
103+
- Простота = надежность + понятность
104+
105+
### DRY (Don't Repeat Yourself)
106+
- Каждая часть знания должна иметь единственное представление
107+
- Дублирование = источник ошибок
108+
- Выносите общую логику в отдельные функции/классы
109+
110+
### SOLID
111+
112+
**S — Single Responsibility**
113+
Один класс = одна ответственность
114+
115+
**O — Open/Closed**
116+
Открыт для расширения, закрыт для модификации
117+
118+
**L — Liskov Substitution**
119+
Наследники должны заменять родителей
120+
121+
**I — Interface Segregation**
122+
Много специализированных интерфейсов лучше одного большого
123+
124+
**D — Dependency Inversion**
125+
Зависите от абстракций, а не от конкретных классов
126+
127+
### PoC (Proof of Concept)
128+
- Прототип для проверки идеи
129+
- Минимальная реализация для демонстрации возможности
130+
- Техническое обоснование перед полной разработкой
131+
132+
### MVP (Minimum Viable Product)
133+
- Продукт с минимальным, но достаточным функционалом
134+
- То, что можно отдать первым пользователям
135+
- Основа для сбора обратной связи и итераций
136+
137+
### MVC (Model-View-Controller)
138+
- Разделение приложения на три компонента:
139+
- **Model** — данные и бизнес-логика
140+
- **View** — отображение, пользовательский интерфейс
141+
- **Controller** — обработка ввода, связь Model и View
142+
- Четкое разделение ответственности
143+
144+
### DDD (Domain-Driven Design)
145+
- Разработка, ориентированная на предметную область
146+
- Основные понятия:
147+
- **Доменная модель** — центральная часть
148+
- **Универсальный язык** — общий язык для разработчиков и экспертов
149+
- **Ограниченный контекст** — границы моделей
150+
- **Сущности, Объекты-значения, Агрегаты** — строительные блоки
151+
- Фокус на бизнес-логике, а не технических деталях
152+
153+
## Когда что использовать
154+
155+
#### **На этапе анализа:**
156+
- **DDD** — для понимания предметной области
157+
- **PoC** — для проверки технических гипотез
158+
159+
#### **На этапе проектирования:**
160+
- **SOLID** — для проектирования архитектуры
161+
- **Паттерны** — для решения конкретных задач проектирования
162+
- **MVC** — для организации структуры приложения
163+
164+
#### **На этапе разработки:**
165+
- **KISS** — при написании каждого метода
166+
- **DRY** — при обнаружении дублирования
167+
- **SOLID** — при создании и рефакторинге классов
168+
169+
#### **На этапе выпуска:**
170+
- **MVP** — для определения первого релиза
171+
- Итеративное развитие на основе обратной связи
172+
173+
## Правила хорошего тона
174+
175+
1. **Начинайте с простого** (KISS)
176+
2. **Избегайте дублирования** (DRY)
177+
3. **Соблюдайте принципы SOLID**
178+
4. **Используйте паттерны обдуманно**, а не везде
179+
5. **Думайте о предметной области** (DDD)
180+
6. **Разделяйте ответственность** (MVC)
181+
7. **Итеративно развивайте продукт** (MVP)
182+
183+
## Материалы
184+
185+
* [Примеры использования паттернов в 1С](https://leobrn.github.io/ones-patterns/)

docs/theory/technologies_services/_category_.json

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"label": "Технологии и сервисы 1С",
3-
"position": 13,
3+
"position": 14,
44
"link": {
55
"slug": "technologies_services",
66
"type": "generated-index"

0 commit comments

Comments
 (0)