Mit tudsz mondani a tiszta architektúráról?

Tiszta Architektúra (Clean Architecture), amit Robert Martin ("Uncle Bob") népszerűsített, egy olyan elvek összessége a kód szervezéséhez, amelyek rugalmas, tesztelhető és könnyen karbantartható rendszerek létrehozására irányulnak.

Főbb ötletek:

1. Rétegekre bontás: A kód koncentrikus körökbe van osztva, ahol a belső körök tartalmazzák az üzleti logikát, a külső körök pedig a megvalósítás részleteit (UI, adatbázisok, külső API-k).
2. Belső rétegektől való függőség: A külső rétegek a belsőktől függenek, de nem fordítva. Ez az függőség fordított irányelve révén érhető el.
3. Encapsulation: Minden réteg elrejti a saját megvalósításának részleteit a külső rétegek elől.
4. Tesztelhetőség: A központi rétegekben lévő üzleti logika független a külső részletektől, így könnyen izolálható és tesztelhető.
5. Függetlenség a keretrendszerektől: Az üzleti szabályok nem kötődnek konkrét keretrendszerekhez, UI-hoz vagy adatbázisokhoz.

Rétegek (példa):

• Entities: Üzleti objektumokat és szabályokat tartalmaz (pl. User osztály és a felhasználóhoz kapcsolódó üzleti logika).
• Use Cases (Interactors): Az alkalmazás specifikus üzleti logikáját tartalmazza (pl. GetUserUseCase). Ezek koordinálják az interakciót az Entities és a Gateway interfészek között.
• Interface Adapters: Az adatok külső forrásokból a Use Cases és Entities által értelmezhető formátumba alakítják (pl. UI prezenterek, adatbázis implementációk).
• Frameworks & Drivers: A külső réteg, amely keretrendszereket tartalmaz (UI, adatbázisok, webszolgáltatások).

A függőség fordított irányelve kulcsfontosságú szerepet játszik. A belső rétegek határozzák meg az interfészeket (Gateway Interfaces), és a külső rétegek valósítják meg ezeket. Ez a következő diagramon látható:

+-----------------+      +-------------------+      +--------------------+      +------------------------+
| Frameworks &    |----->|   Interface       |<-----|    Use Cases       |<-----|        Entities          |
| Drivers (UI, DB)|      |   Adapters        |      |  (Interactors)     |      |      (Business Rules)    |
+-----------------+      |  (Presenters,     |      |                    |      +------------------------+
                         |  Gateway Impls)   |      |                    |
                         +-------------------+      +--------------------+

Az irányok mutatják a függőségek irányát. Minden függőség befelé mutat, az Entities réteg felé.

Android fejlesztésben a Tiszta Architektúra gyakran a következő komponensekkel valósul meg:

• UI Layer (Prezentáció): Activity, Fragment, ViewModel, UI logika. A Domain Layer-től függ.
• Domain Layer (Use Cases): Az alkalmazás üzleti logikája. Nem függ más rétegektől.
• Data Layer: Adatforrások (hálózatok, adatbázisok), repository-k. Megvalósítják a Domain Layer-ben meghatározott interfészeket.

Példa struktúra:

root
├── app
│   ├── src
│   │   └── main
│   │       └── java
│   │           └── com
│   │               └── example
│   │                   └── myapp
│   │                       ├── presentation  // UI Layer (ViewModel, Activities, Fragments)
│   │                       │   ├── ui
│   │                       │   └── viewmodel
│   │                       ├── domain      // Domain Layer (Use Cases, Entities, Interfaces)
│   │                       │   ├── entity
│   │                       │   ├── repository  // Domain Interfaces
│   │                       │   └── usecase
│   │                       └── data        // Data Layer (Repositories, Data Sources, Mappers)
│   │                           ├── local       // Local Data Source (Room)
│   │                           ├── remote      // Remote Data Source (Retrofit)
│   │                           ├── mapper
│   │                           └── repository  // Data Implementations extending Domain Interfaces
│   └── build.gradle
└── build.gradle

Előnyök:

• Tesztelhetőség: Az üzleti logika izolált és könnyen tesztelhető.
• Rugalmasság: Könnyen cserélhetőek a külső függőségek (pl. Room-ról Realm-re váltás).
• Karbantarthatóság: A világos felelősségi körök megkönnyítik a kód megértését és karbantartását.
• Függetlenség a technológiától: Az üzleti logika nem kötött specifikus Android keretrendszerekhez vagy könyvtárakhoz.

Hátrányok:

• Komplexitás: Kezdetben bonyolultabb lehet megérteni és megvalósítani, különösen kisebb projektek esetén.
• Több kód: Több osztály és interfész írását igényli, összehasonlítva az egyszerűbb architektúrákkal.

Összességében a Tiszta Architektúra egy erőteljes megközelítés a skálázható és könnyen karbantartható Android alkalmazások létrehozásához, különösen közepes és nagyobb projektek esetén. Elősegíti a fejlesztést az üzleti logika körül, nem pedig a technikai részletek körül.