Architektura i wzorce w programowaniu mobilnym: co to jest, jakie są rodzaje i jak stosować

Główne wzorce architektoniczne

Wzorzec architektoniczny określa, jak odpowiedzialności są rozdzielane między klasy aplikacji. Wybór wzorca wpływa na łatwość dodawania nowych ekranów i testowania kodu.

MVC (Model-View-Controller)

MVC to klasyczny wzorzec, w którym Model odpowiada za dane, View za wyświetlanie, a Controller za logikę. W iOS MVC jest domyślne (UIViewController), w Android — Activity. Wadą jest to, że Controller często staje się "masywny" (Massive View Controller). Według ankiety wśród programistów iOS (Reddit, 2025), 62% wskazuje MVC jako główną przyczynę nieczytelnego kodu w starych projektach.

MVP (Model-View-Presenter)

MVP różni się tym, że Presenter zarządza View przez interfejs, poprawiając testowalność. MVP było popularne w Android przed Jetpack, ale ustępuje MVVM pod względem wygody.

MVVM (Model-View-ViewModel)

MVVM to zalecany przez Google wzorzec dla Android i przez Apple dla iOS. ViewModel przechowuje stan, a View subskrybuje zmiany poprzez Data Binding lub @Published. ViewModel nie zależy od View i jest łatwy do testowania. W IT Sectr używamy MVVM jako głównego wzorca we wszystkich projektach.

MVI i VIPER

MVI to wzorzec reaktywny, w którym każde działanie przechodzi cykl Intent → Model → View. MVI gwarantuje przewidywalny stan. VIPER to wzorzec iOS z pięcioma warstwami (View, Interactor, Presenter, Entity, Router), zapewniający maksymalną izolację, ale wymagający dużo kodu szablonowego.

Clean Architecture

Clean Architecture to koncepcja Roberta Martina, która dzieli aplikację na warstwy: zewnętrzne (UI, DB, sieć) zależą od wewnętrznych (logika biznesowa, encje). W programowaniu mobilnym Clean Architecture obejmuje trzy warstwy: data (repozytoria), domain (Use Cases) i presentation (ViewModels, UI).

Repository Pattern to kluczowy komponent Clean Architecture, abstrahujący źródło danych. Repozytorium decyduje, czy pobrać dane z sieci czy lokalnego magazynu (Room, Core Data) i zwraca ujednolicony format. Według Google (Architecture Guide, 2025), Repository Pattern jest zalecany dla każdej aplikacji z żądaniami sieciowymi. Clean Architecture jest uzasadniona w projektach od 3–5 ekranów — dla prostych aplikacji zacznij od MVVM.

Wzorce kreacyjne

Singleton

Singleton to wzorzec architektoniczny gwarantujący pojedynczą instancję klasy i zapewniający globalny punkt dostępu do niej. Jest używany dla baz danych, menedżerów ustawień i pamięci podręcznej. W Kotlin tworzy się go przez object. Wadą jest to, że komplikuje testowanie z powodu globalnego stanu.

Factory i Builder

Factory deleguje tworzenie obiektów do metody fabrycznej — zamiast new wywołujesz fabrykę. Builder to wzorzec stopniowego konstruowania złożonych obiektów z wieloma parametrami (AlertDialog.Builder, NotificationCompat.Builder). Builder poprawia czytelność i pozwala obiektom pozostać niezmiennymi po złożeniu.

Wzorce strukturalne i behawioralne

Adapter, Facade, Delegate, Protocol

Adapter to wzorzec architektoniczny przekształcający interfejs jednej klasy na interfejs oczekiwany przez klienta. W Android jest to RecyclerView.Adapter. Facade zapewnia uproszczony interfejs do złożonego systemu — na przykład fasada dla API ukrywająca szczegóły uwierzytelniania. Delegate to wzorzec iOS, w którym obiekt deleguje zadanie (UITableViewDelegate). Protocol to odpowiednik interfejsu w Swift.

Observer i Strategy

Observer to wzorzec subskrypcji zmian: podmiot powiadamia subskrybentów o aktualizacjach. W programowaniu mobilnym Observer jest podstawą LiveData, StateFlow, RxJava i Combine. Strategy to wzorzec wymiennych algorytmów: podłączasz inną strategię (sortowanie, walidacja) bez wielu instrukcji if-else.

Wstrzykiwanie zależności i zarządzanie stanem

Dependency Injection to wzorzec architektoniczny, w którym obiekt otrzymuje zależności z zewnątrz zamiast tworzyć je samodzielnie. Zamiast new Database() przekazujesz bazę danych przez konstruktor. DI upraszcza testowanie — możesz użyć Mock zamiast prawdziwej bazy danych — i ułatwia wymianę implementacji. Popularne frameworki DI: Dagger i Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — nakładka na Dagger zalecana przez Google — zmniejsza konfigurację DI 3-krotnie.

Service Locator to alternatywa dla DI z centralnym rejestrem zależności. Prostszą w implementacji, ale ukrywa zależności klasy, utrudniając testowanie. Nowoczesne projekty preferują DI przez Hilt lub Koin.

Zarządzanie stanem we Flutter

We Flutter zarządzanie stanem to osobny ekosystem. Redux — pojedynczy Store ze zmianami przez Actions → Reducer → State. BLoC od Google rozdziela zdarzenia i stany przez Stream. Provider — prosty kontener DI zalecany przez Google dla Flutter do 2023. Riverpod — ulepszony Provider rozwiązujący problemy z kompilacją i testowaniem. GetX — mikro-framework z routingiem, DI i stanem. Początkującym programistom Flutter polecamy Provider lub Riverpod jako najlepiej udokumentowane rozwiązania.

Zasady SOLID i DRY

Oprócz konkretnych wzorców istnieją ogólne zasady projektowania architektury, które mają zastosowanie w każdym języku i frameworku.

SOLID — pięć zasad programowania obiektowego: Single Responsibility (jedna klasa — jedno zadanie), Open-Closed (otwarta na rozszerzanie, zamknięta na modyfikacje), Liskov Substitution (klasy pochodne zastępują bazową), Interface Segregation (małe interfejsy), Dependency Inversion (zależność od abstrakcji). W programowaniu mobilnym SRP to najbardziej użyteczna zasada: każda klasa robi tylko jedną rzecz. Według doświadczenia IT Sectr, naruszenie SRP jest przyczyną 70% problemów z testowaniem w komercyjnych projektach.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

Przykład w Kotlin pokazuje, jak z jednej klasy UserManager z czterema obowiązkami otrzymujemy cztery klasy z jednym obowiązkiem każda. Taki kod jest łatwiejszy do testowania, modyfikowania i ponownego użycia.

DRY (Don't Repeat Yourself) — unikaj powielania kodu. Wyodrębniaj powtarzającą się logikę do wspólnych metod lub klas. KISS (Keep It Simple, Stupid) — prostota jest ważniejsza niż elegancja. YAGNI (You Aren't Gonna Need It) — nie pisz kodu na coś, co może nie być potrzebne. Te zasady pomagają pisać czysty, łatwy w utrzymaniu kod bez nadmiarowości.

Wzorce platformy Android

ViewModel (Android) to komponent architektury Jetpack do przechowywania stanu UI, odporny na obrót ekranu. ViewModel nie zawiera odwołań do Activity i jest automatycznie czyszczony. LiveData — obserwowalny kontener danych ze świadomością cyklu życia. StateFlow — nowoczesny zamiennik LiveData oparty na Kotlin Flow. SharedFlow — Hot Flow dla zdarzeń jednorazowych (nawigacja, toasty).

Data Binding i Two-Way Binding — mechanizmy wiązania UI i danych w Android. Data Binding deklaruje połączenie w XML; Two-Way Binding automatycznie aktualizuje pole w ViewModel. Unidirectional Data Flow — zasada, w której dane płyną w jednym kierunku: State → UI → Event → State. W IT Sectr używamy Unidirectional Data Flow we wszystkich nowych projektach — zmniejsza liczbę błędów spowodowanych nieoczekiwanymi zmianami stanu.