SoC w rozwoju mobilnym: co to jest, zasady i podział odpowiedzialności

Co oznacza skrót SoC

SoC oznacza Separation of Concerns — „podział odpowiedzialności” lub „rozdzielenie obszarów zainteresowań”. W kontekście programowania termin concern oznacza dowolną wyodrębnialną funkcjonalność: wyświetlanie interfejsu użytkownika, obsługę kliknięć, walidację danych, komunikację sieciową lub pracę z bazą danych. Zasada SoC nakazuje grupowanie kodu wokół tych obszarów tak, aby zmiany w jednym nie wpływały na pozostałe.

Skrót SoC jest szeroko używany w literaturze technicznej, dyskusjach architektonicznych i dokumentacji frameworków. Na przykład w dokumentacji Android Architecture Components wielokrotnie przywołuje się SoC jako motywację do rozdzielenia ViewModel i View. W społeczności iOS termin ten jest używany przy omawianiu problemu Massive View Controller — bezpośredniego skutku braku SoC.

Ważne jest, aby zrozumieć, że SoC to nie jednorazowe działanie, ale ciągły proces. W miarę rozwoju aplikacji pojawiają się nowe obszary odpowiedzialności i architektura wymaga ponownego przeglądu. Dobra baza kodu przechodzi kilka iteracji podziału, zanim osiągnie stabilny stan, w którym każdy concern jest izolowany i zarządzalny.

SoC a Separation of Concerns

Separation of Concerns i jego skrót SoC oznaczają tę samą zasadę. Różnica polega tylko na kontekście użycia: pełna nazwa stosowana jest w formalnych dokumentach, materiałach edukacyjnych i przy pierwszym wyjaśnianiu koncepcji nowym programistom. SoC jest wygodne w dyskusjach technicznych, code review i dokumentacji, gdzie liczy się zwięzłość.

W środowisku profesjonalnym oba terminy są wymienne. Programista może powiedzieć „tu naruszono SoC” lub „to narusza Separation of Concerns” — znaczenie się nie zmienia. Jednak w ogłoszeniach o pracę i wymaganiach architektonicznych częściej występuje pełna nazwa, podczas gdy na czatach i w code review — skrót. Znajomość obu wariantów jest niezbędna do swobodnego wejścia w branżę.

Istnieje zamieszanie terminologiczne: skrót SoC jest również używany w kontekście sprzętowym dla System-on-a-Chip (system na chipie). W programowaniu mobilnym kontekst jest zawsze jasny na podstawie otoczenia — jeśli dyskusja dotyczy architektury kodu, chodzi o Separation of Concerns. W tym artykule SoC zawsze odnosi się do zasady podziału odpowiedzialności.

Jak SoC stosuje się w architekturze mobilnej

Architektura trójwarstwowa to najczęstszy sposób realizacji SoC w aplikacjach mobilnych. Dzieli kod na Presentation (UI), Domain (logika biznesowa) i Data (praca ze źródłami). Każda warstwa zawiera ściśle określone typy klas i jest izolowana od sąsiednich poprzez interfejsy. To podejście jest równie skuteczne w projektach iOS, Android i Flutter.

Warstwa Presentation i ViewModel

View i ViewModel tworzą warstwę prezentacji. View odpowiada za renderowanie interfejsu i przekazywanie zdarzeń użytkownika. ViewModel przechowuje stan ekranu i przekształca dane z warstwy Domain do formatu gotowego do wyświetlenia. ViewModel nie ma referencji do Activity, Fragment ani UIViewController — zapewnia to SoC między UI a logiką.

Na przykład w Android Jetpack ViewModel przetrwa obrót ekranu, a UI jest odtwarzane. Bez SoC należałoby przechowywać stan w Activity, mieszając zarządzanie cyklem życia z danymi. ViewModel rozwiązuje to zadanie w izolacji, demonstrując czystą implementację zasady podziału odpowiedzialności.

Warstwa Domain i Use Cases

Use Cases zawierają reguły biznesowe niezależne od platformy. Ta warstwa nie importuje Android SDK, iOS UIKit ani Flutter framework. Use Case pobiera dane z Repository, stosuje do nich logikę biznesową i zwraca wynik. Dzięki SoC jeden Use Case może być ponownie używany na różnych ekranach i platformach.

Klasycznym przykładem jest ValidateAndSaveUseCase dla formularza rejestracji. Sprawdza poprawność emaila i hasła, wywołuje UserRepository w celu zapisania i zwraca ValidationResult. Ani UI, ani baza danych nie znają reguł walidacji — są one skoncentrowane w jednym miejscu, co ułatwia ich zmianę.

Warstwa Data i Repository

Repository abstrahuje źródła danych od reszty aplikacji. ViewModel nie wie, skąd pochodzą dane — z REST API, GraphQL, lokalnej bazy danych czy cache. Repository decyduje, które źródło użyć, i ukrywa tę logikę za interfejsem. To SoC między pozyskiwaniem danych a ich konsumpcją.

DataSource zapewnia jeszcze głębszy podział: RemoteDataSource odpowiada tylko za żądania HTTP, LocalDataSource — za pracę z Room, CoreData lub SharedPreferences. Repository łączy je, stosując strategie buforowania. Każdy DataSource może być wymieniany niezależnie, co jest krytyczne przy migracji między serwerami lub bazami danych.

Taki wielowarstwowy system DataSource realizuje SoC na poziomie infrastruktury: komunikacja sieciowa, przechowywanie lokalne i buforowanie to oddzielne concerns, każdy z własną logiką i cyklem życia. Przy zmianie klienta HTTP zmienia się tylko RemoteDataSource, a Repository i wyższe warstwy pozostają nietknięte, co potwierdza praktyczną wartość podziału odpowiedzialności.

SoC we wzorcach architektonicznych

MVP (Model-View-Presenter) — jeden z pierwszych wzorców jawnie realizujących SoC w programowaniu mobilnym. Presenter zawiera logikę i zarządza View poprzez interfejs. View jest pasywna — tylko wyświetla to, co mówi Presenter. Podział upraszcza testowanie: Presenter testuje się bez emulatora, a View pozostaje na tyle proste, że nie ma w nim nic do zepsucia.

MVVM dodał powiązanie reaktywne: View subskrybuje zmiany ViewModel przez Observable lub StateFlow. ViewModel nie przechowuje referencji do View, co eliminuje ryzyko wycieku pamięci i jeszcze silniej rozdziela concerns. W Android MVVM stał się standardem dzięki Jetpack ViewModel i LiveData, w iOS — dzięki Combine i RxSwift.

Clean Architecture Roberta Martina doprowadza SoC do radykalnego podziału na pierścienie. Zewnętrzny pierścień (frameworki i sterowniki) zależy od wewnętrznego (encje), ale nie odwrotnie. W praktyce projekty mobilne rzadko realizują wszystkie cztery pierścienie — wystarczy Domain i Data wokół Presentation. Ale sama zasada zależności „do wewnątrz” daje znaczące korzyści przy zmianie frameworków.

// View — tylko wyświetlanie, bez logiki
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — zawiera logikę ekranu, nie zna UIKit
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — logika biznesowa, niezależna od platformy
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

Przykład pokazuje trzy poziomy SoC: LoginViewController tylko przekazuje zdarzenia, LoginViewModel zarządza stanem, LoginUseCase zawiera reguły biznesowe. Każda klasa jest testowana niezależnie, a zmiana frameworka UI nie wpływa na Use Case.

Typowe naruszenia SoC w projektach mobilnych

Massive View Controller — najczęstsze naruszenie SoC w iOS. Klasa, która zarządza UI, obsługuje żądania sieciowe, parsuje JSON i zapisuje dane, narusza zasadę na wszystkich poziomach. Rozwiązanie — wydzielić każdą odpowiedzialność do osobnego komponentu: NetworkingService, JSONParser, CoreDataStack, pozostawiając ViewController tylko zarządzanie View.

W Android analogiczny problem — God Activity lub God Fragment. Jedna aktywność, która ładuje dane, waliduje formularze, pokazuje dialogi i aktualizuje UI. Leczone przez wprowadzenie ViewModel i Repository, które przejmują zarządzanie stanem i danymi. ViewModel chroni również przed utratą danych przy obrocie ekranu.

Trzecie naruszenie — mieszanie kodu platformowego i biznesowego. Na przykład umieszczenie żądania HTTP bezpośrednio w SwiftUI View lub Android Composable. To czyni kod nieprzenośnym i trudnym do testowania. Prawidłowe podejście — przenieść żądanie do Repository, które jest wywoływane przez Use Case, a View tylko subskrybuje wynik. Każdy element systemu rozwiązuje swoje zadanie i nie wychodzi poza jego granice.