91 lines
4.3 KiB
Markdown
91 lines
4.3 KiB
Markdown
# Рефакторинг - Краткое описание
|
||
|
||
## Выполненные изменения
|
||
|
||
### 1. StorageSQL.java (248 → ~150 строк)
|
||
|
||
**Проблемы:**
|
||
- Смешивание логики подключения, миграций и CRUD операций
|
||
- Дублирование кода в методах sendUpdate/sendUpdateSuppressed
|
||
- Отсутствие разделения ответственностей
|
||
|
||
**Решение:**
|
||
Разделен на 3 класса:
|
||
- `SQLConnectionManager` - управление подключением к БД
|
||
- `SQLQueryExecutor` - выполнение SQL запросов
|
||
- `SQLMigrationManager` - управление миграциями схемы БД
|
||
|
||
**Преимущества:**
|
||
- Каждый класс отвечает за одну задачу (Single Responsibility Principle)
|
||
- Легче тестировать и поддерживать
|
||
- Упрощена логика переподключения
|
||
|
||
### 2. Session.java (236 → ~120 строк)
|
||
|
||
**Проблемы:**
|
||
- Слишком много ответственностей (игроки, спектаторы, видимость, мут)
|
||
- Дублирование логики в add/remove методах
|
||
- Сложная логика уведомлений
|
||
|
||
**Решение:**
|
||
Создан класс `SessionUserManager` для управления пользователями
|
||
|
||
**Преимущества:**
|
||
- Session теперь делегирует управление пользователями
|
||
- Логика уведомлений инкапсулирована
|
||
- Проще добавлять новые типы пользователей
|
||
|
||
### 3. ParkourUser.java (220 → ~100 строк)
|
||
|
||
**Проблемы:**
|
||
- Смешивание статических методов регистрации и instance методов
|
||
- Сложная логика scoreboard встроена в класс
|
||
- Запутанные методы register/unregister/leave
|
||
|
||
**Решение:**
|
||
Разделен на 3 класса:
|
||
- `UserRegistry` - регистрация и управление пользователями
|
||
- `ScoreboardManager` - управление scoreboard
|
||
- `BungeeUtil` - утилиты для BungeeCord
|
||
|
||
**Преимущества:**
|
||
- Четкое разделение статической и instance логики
|
||
- Scoreboard логика изолирована и переиспользуема
|
||
- Упрощена логика регистрации/выхода
|
||
|
||
### 4. ParkourPlayer.java (202 → ~150 строк)
|
||
|
||
**Проблемы:**
|
||
- Огромная статическая инициализация PLAYER_COLUMNS
|
||
- Дублирование логики с ParkourUser
|
||
- Сложный метод setSettings
|
||
|
||
**Решение:**
|
||
Создан класс `PlayerSettingsManager` для управления настройками
|
||
|
||
**Преимущества:**
|
||
- Настройки и их маппинг инкапсулированы
|
||
- Легче добавлять новые настройки
|
||
- Упрощена логика применения настроек
|
||
|
||
## Итоговая статистика
|
||
|
||
| Файл | Было строк | Стало строк | Новых классов |
|
||
|------|------------|-------------|---------------|
|
||
| StorageSQL.java | 248 | ~150 | 3 |
|
||
| Session.java | 236 | ~120 | 1 |
|
||
| ParkourUser.java | 220 | ~100 | 3 |
|
||
| ParkourPlayer.java | 202 | ~150 | 1 |
|
||
| **ИТОГО** | **906** | **~520** | **8** |
|
||
|
||
## Принципы, примененные в рефакторинге
|
||
|
||
1. **Single Responsibility Principle (SRP)** - каждый класс отвечает за одну задачу
|
||
2. **Separation of Concerns** - разделение логики по разным классам
|
||
3. **DRY (Don't Repeat Yourself)** - устранение дублирования кода
|
||
4. **Encapsulation** - инкапсуляция сложной логики в отдельные классы
|
||
5. **Delegation** - делегирование задач специализированным классам
|
||
|
||
## Обратная совместимость
|
||
|
||
Все публичные API остались без изменений. Рефакторинг затронул только внутреннюю структуру классов.
|