Архитектурные принципы в мобильной разработке: что это такое, какие бывают и как применять

Принципы SOLID

Архитектурные принципы — это фундамент качественного кода. SOLID — акроним, введённый Робертом Мартином («Дядюшка Боб»), описывающий пять принципов объектно-ориентированного проектирования. Следование SOLID делает код более гибким, тестируемым и устойчивым к изменениям. Нарушение архитектурных принципов — одна из главных причин технического долга.

Рассмотрим каждый принцип. Single Responsibility Principle (SRP) — каждый класс должен иметь только одну причину для изменения. Open/Closed Principle (OCP) — классы открыты для расширения, но закрыты для модификации. Liskov Substitution Principle (LSP) — объекты подтипов должны заменять объекты базового типа без нарушения логики. Interface Segregation Principle (ISP) — много специализированных интерфейсов лучше одного общего. Dependency Inversion Principle (DIP) — зависимость от абстракций, а не от конкретных реализаций.

По данным анализа SonarQube (2025), нарушение принципов SOLID встречается в 68% коммерческих проектов. Самые частые проблемы — нарушение SRP (35%) и ISP (22%). В IT Sectr мы внедряем SOLID на этапе архитектурного ревью — это помогает выявить проблемы до того, как они перерастут в технический долг.

Single Responsibility Principle (SRP)

SRP (Принцип единственной ответственности) — самый важный и одновременно самый часто нарушаемый принцип SOLID. Он гласит: у класса должна быть только одна причина для изменения. Если класс делает слишком много — его сложно тестировать, изменять и понимать.

Типичное нарушение — класс, который одновременно обрабатывает данные, сохраняет их в базу и отправляет email-уведомления. Пример ниже показывает, как выглядит нарушение SRP на Kotlin и как его исправить.

// Нарушение SRP — класс делает три разных дела
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Валидация данных
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Сохранение в базу
        val user = User(email, name)
        database.save(user)
        
        // 3. Отправка уведомления
        emailService.sendWelcomeEmail(email, name)
    }
}

// Исправление — разделение на три класса
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

В исправленной версии каждый класс отвечает за свою задачу: UserValidator — за валидацию, UserRepository — за сохранение, NotificationService — за уведомления. Это делает код тестируемым и переиспользуемым — можно заменить реализацию базы данных без изменения логики валидации.

GRASP и Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — девять архитектурных принципов распределения ответственности между объектами, описанных Крейгом Ларманом. В отличие от SOLID, GRASP отвечает на вопрос «какой класс должен содержать этот метод?». Ключевые шаблоны: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, принцип минимальной связанности) — простое правило: объект должен общаться только с непосредственными соседями. Нельзя писать a.getB().getC().doSomething() — это создаёт жёсткую связь между классами. LoD улучшает переиспользование и упрощает тестирование.

В IT Sectr мы проверяем соблюдение LoD на Code Review. Если метод «проходит» через три и более объекта — это сигнал, что архитектуру нужно упростить. Нарушение LoD — один из самых распространённых Code Smell в больших проектах.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) и YAGNI (You Ain't Gonna Need It) — три базовых архитектурных принципа, известных каждому разработчику. Несмотря на простоту, их нарушение встречается постоянно.

DRY — не дублируйте код. Если одна и та же логика встречается в двух местах, вынесите её в общий метод или класс. Дублирование — главный источник багов: исправление в одном месте забывают применить в другом. DRY не означает, что нельзя иметь похожий код — важно, чтобы бизнес-логика не повторялась.

KISS — чем проще, тем лучше. Сложные решения с множеством абстракций и наследований часто избыточны. Начинайте с простого решения и усложняйте только по необходимости. YAGNI — не пишите код для функциональности, которая может понадобиться «когда-нибудь потом». Это приводит к раздуванию кодовой базы и усложнению поддержки.

DRY — Don't Repeat Yourself

DRY — это не просто отсутствие копипаста. Это принцип, согласно которому каждая часть знания или логики должна иметь единственное, однозначное представление в системе. Дублирование может быть явным (скопированный код) и неявным (одинаковая логика в разных слоях).

В IT Sectr мы используем метрики анализа кода для выявления дублирования. Инструменты вроде SonarQube и Detekt показывают процент дублированного кода. Значение выше 5% — повод для рефакторинга. Однако важно помнить: DRY не должен достигаться ценой неправильных абстракций — иногда два похожих куска кода лучше оставить как есть, если их объединение усложнит понимание.

Separation of Concerns и Modularity

Separation of Concerns (SoC, разделение ответственности) — архитектурный принцип, при котором система делится на независимые части (concerns), каждая из которых решает свою задачу. Классический пример — разделение на слои: presentation, business logic, data access. Каждый слой зависит только от нижележащего.

Modularity (модульность) — степень, в которой система может быть разбита на модули. Модуль — это логически связанная группа классов с чётко определённым интерфейсом. Модули должны быть слабо связаны (low coupling) и сильно связны (high cohesion).

Cohesion vs Coupling

Cohesion (связность) — мера того, насколько элементы внутри одного модуля связаны между собой. Высокая связность — это хорошо: класс делает одну вещь и делает её хорошо. Low coupling (слабая связанность) — мера того, насколько модули независимы друг от друга. Низкая связанность — это хорошо: изменение одного модуля не ломает другие.

Идеальная архитектура — это high cohesion и low coupling. На практике это означает: класс содержит методы, работающие над одними данными (cohesion), и зависит только от абстракций, а не от конкретных реализаций (coupling). Нарушение баланса приводит к «божественным объектам» (God Object) или «спагетти-коду».

Технический долг и Code Smell

Технический долг (Technical Debt) — это метафора, введённая Уордом Каннингемом, описывающая «проценты», которые команда платит за неоптимальные архитектурные решения и нарушение архитектурных принципов. Как и финансовый долг, технический долг бывает намеренным (решили сделать быстро, переделаем потом) и непреднамеренным (плохая архитектура из-за недостатка опыта).

Code Smell — это поверхностные признаки глубоких проблем в коде. Термин популяризировал Мартин Фаулер в книге «Refactoring». Типичные Code Smell: длинные методы, большие классы, длинные цепочки вызовов, дублирование кода, чрезмерное использование комментариев (вместо понятного кода).

В IT Sectr технический долг отслеживается в Jira в виде отдельных задач. Каждый спринт мы выделяем 20% времени на рефакторинг и погашение долга. Систематическая работа с техническим долгом — единственный способ избежать ситуации, когда добавление новой фичи занимает больше времени, чем её разработка с нуля.