Как относишься к классам от 2000 строк

Мое отношение к большим классам

Как опытный разработчик, я отношусь к классам размером в 2000+ строк крайне негативно, считая их антипаттерном и серьезной проблемой в поддержке кодовой базы. Такой размер нарушает ключевые принципы SOLID, особенно Single Responsibility Principle (SRP) — класс явно берет на себя слишком много обязанностей.

Проблемы больших классов

Класс-божество (God Class) размером 2000 строк создает множество проблем:

• Сложность понимания: Разработчик не может мысленно охватить всю логику класса, что замедляет внесение изменений
• Высокая связность (High Coupling): Класс становится центром притяжения зависимостей, изменения в нем затрагивают множество других компонентов
• Сложность тестирования: Написание юнит-тестов превращается в мучение — требуется mock-объектов десятки зависимостей
• Проблемы с параллельной разработкой: Несколько разработчиков не могут работать с одним классом одновременно без постоянных конфликтов слияния
• Нарушение инкапсуляции: В таком классе приватные детали реализации неизбежно "просачиваются" наружу

Практический пример проблемы

Рассмотрим типичный UserManager на 2000 строк, который делает "всё":

// АНТИПАТТЕРН: Класс делает слишком много
class UserManager {
    // Поля для разных ответственностей
    private val apiClient: ApiClient
    private val database: Database
    private val cache: Cache
    private val prefs: SharedPreferences
    private val notificationManager: NotificationManager
    private val analytics: Analytics
    private val imageLoader: ImageLoader
    
    // 50+ методов, отвечающих за:
    // - Аутентификацию
    // - Работу с профилем
    // - Уведомления
    // - Кэширование
    // - Аналитику
    // - Валидацию данных
    // - Форматирование
    // - и многое другое...
    
    fun login(email: String, password: String) { /* 150 строк */ }
    fun logout() { /* 100 строк */ }
    fun updateProfile(user: User) { /* 200 строк */ }
    fun uploadAvatar(image: Bitmap) { /* 150 строк */ }
    fun sendNotification(message: String) { /* 80 строк */ }
    fun trackEvent(event: String) { /* 50 строк */ }
    // ... и еще 40 методов
}

Стратегии рефакторинга

Вместо одного класса-монолита я применяю несколько стратегий:

1. Выделение отдельных классов по ответственностям:

// Каждый класс отвечает за одну вещь
class AuthenticationService(private val apiClient: ApiClient) {
    fun login(email: String, password: String) { /* 40 строк */ }
    fun logout() { /* 20 строк */ }
}

class UserProfileRepository(
    private val apiClient: ApiClient, 
    private val database: Database
) {
    fun updateProfile(user: User) { /* 60 строк */ }
    fun getProfile(userId: String) { /* 40 строк */ }
}

class NotificationService(private val notificationManager: NotificationManager) {
    fun sendNotification(message: String) { /* 30 строк */ }
}

class AnalyticsTracker(private val analytics: Analytics) {
    fun trackEvent(event: String, params: Map<String, Any>) { /* 20 строк */ }
}

1. Использование композиции вместо наследования:

class UserManager(
    private val authService: AuthenticationService,
    private val profileRepo: UserProfileRepository,
    private val notificationService: NotificationService
) {
    // Тонкий фасад, делегирующий работу специализированным сервисам
    fun login(email: String, password: String) {
        authService.login(email, password)
    }
    
    fun updateProfileWithNotification(user: User, message: String) {
        profileRepo.updateProfile(user)
        notificationService.sendNotification(message)
    }
}

1. Применение принципов Clean Architecture/DDD:
   • Выделение Domain Layer с бизнес-логикой
   • Создание Data Layer для работы с данными
   • Отделение Presentation Layer для UI-логики

Когда большой класс может быть оправдан?

Исключительно редкие случаи:

• Сгенерированный код (например, кодогенераторами для парсинга)
• Унаследованный легаси-код, который пока нельзя трогать
• Высокооптимизированные нативные компоненты, где производительность критична

Моя практика в проектах

Я устанавливаю строгие лимиты в проектах:

• Предупреждение: 300+ строк — стоит задуматься о рефакторинге
• Критично: 500+ строк — обязательный рефакторинг в следующем спринте
• Недопустимо: 1000+ строк — блокирую merge request

Использую статические анализаторы (Detekt, ktlint с правилом MaxLineLength) для автоматического контроля. В code review сразу указываю на большие классы и предлагаю конкретные пути рефакторинга.

Золотое правило: Класс должен решать одну задачу, и делать это хорошо. Если для описания ответственности класса требуется союз "и" ("отвечает за аутентификацию И кэширование И аналитику"), это явный сигнал к разделению.