Архитектурни принципи в мобилната разработка: какво представляват, какви видове има и как да се прилагат

Принципи 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. Той гласи: класът трябва да има само една причина за промяна. Ако един клас прави твърде много, е трудно да се тества, променя и разбира.

Типично нарушение е клас, който едновременно обработва данни, записва ги в базата данни и изпраща имейл известия. Примерът по-долу показва нарушение на 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 по време на преглед на кода. Ако даден метод «преминава» през три или повече обекта, това е сигнал, че архитектурата се нуждае от опростяване. Нарушаването на 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 и Модулност

Separation of Concerns (SoC) — архитектурен принцип, при който системата се разделя на независими части (concerns), всяка от които решава своя собствена задача. Класически пример е разделянето на слоеве: презентация, бизнес логика, достъп до данни. Всеки слой зависи само от слоя под него.

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

Кохезия vs Свързаност

Кохезия (Cohesion) — мярка за това колко елементите в рамките на един модул са свързани помежду си. Високата кохезия е добра: класът прави едно нещо и го прави добре. Ниска свързаност (Low coupling) — мярка за това колко независими са модулите един от друг. Ниската свързаност е добра: промяната на един модул не нарушава другите.

Идеалната архитектура е висока кохезия и ниска свързаност. На практика това означава: класът съдържа методи, които работят върху едни и същи данни (кохезия), и зависи само от абстракции, а не от конкретни реализации (свързаност). Дисбалансът води до «Божествени обекти» или «спагетен код».

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

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

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

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