SoC in mobiele ontwikkeling: wat het is, principes en scheiding van verantwoordelijkheden

Wat betekent de afkorting SoC

SoC staat voor Separation of Concerns — „scheiding van verantwoordelijkheden" of „scheiding van interessegebieden". In de context van programmeren verwijst de term concern naar elke afzonderlijke functionaliteit: weergave van de gebruikersinterface, verwerking van klikken, gegevensvalidatie, netwerkcommunicatie of werken met een database. Het SoC-principe schrijft voor om code rond deze gebieden te groeperen, zodat wijzigingen in het ene geen invloed hebben op de andere.

De afkorting SoC wordt veel gebruikt in technische literatuur, architectuurdiscussies en documentatie van frameworks. In de documentatie van Android Architecture Components wordt bijvoorbeeld herhaaldelijk verwezen naar SoC als motivatie voor het scheiden van ViewModel en View. In de iOS-gemeenschap wordt de term gebruikt bij het bespreken van het Massive View Controller-probleem — een direct gevolg van het ontbreken van SoC.

Het is belangrijk om te begrijpen dat SoC geen eenmalige actie is, maar een continu proces. Naarmate de applicatie groeit, ontstaan er nieuwe verantwoordelijkheidsgebieden en moet de architectuur opnieuw worden bekeken. Een goede codebase doorloopt verschillende iteraties van verdeling voordat het een stabiele toestand bereikt waarin elke concern geïsoleerd en beheersbaar is.

SoC vs Separation of Concerns

Separation of Concerns en de afkorting SoC duiden hetzelfde principe aan. Het verschil zit alleen in de gebruiksscontext: de volledige naam wordt gebruikt in formele documenten, lesmateriaal en bij de eerste uitleg van het concept aan nieuwe ontwikkelaars. SoC is handig in technische discussies, code reviews en documentatie waar beknoptheid belangrijk is.

In een professionele omgeving zijn beide termen uitwisselbaar. Een ontwikkelaar kan zeggen „hier is SoC geschonden" of „dit schendt Separation of Concerns" — de betekenis verandert niet. In vacatures en architectuureisen komt echter vaker de volledige naam voor, terwijl in chats en code reviews de afkorting wordt gebruikt. Kennis van beide varianten is noodzakelijk voor een comfortabele toegang tot de industrie.

Er is terminologische verwarring: de afkorting SoC wordt ook gebruikt in hardwarecontext voor System-on-a-Chip (systeem op een chip). In mobiele ontwikkeling is de context altijd duidelijk uit de omgeving — als de discussie over codearchitectuur gaat, is Separation of Concerns bedoeld. In dit artikel verwijst SoC overal naar het principe van scheiding van verantwoordelijkheden.

Hoe SoC wordt toegepast in mobiele architectuur

Drielagenarchitectuur — de meest voorkomende manier om SoC te implementeren in mobiele applicaties. Het verdeelt code in Presentation (UI), Domain (bedrijfslogica) en Data (werken met bronnen). Elke laag bevat strikt gedefinieerde klassen en is via interfaces van buren geïsoleerd. Deze aanpak is even effectief voor iOS-, Android- en Flutter-projecten.

Presentatielaag en ViewModel

View en ViewModel vormen de presentatielaag. View is verantwoordelijk voor het weergeven van de interface en het doorgeven van gebruikersgebeurtenissen. ViewModel slaat de schermstatus op en converteert gegevens uit de Domain-laag naar een formaat dat klaar is voor weergave. ViewModel heeft geen verwijzingen naar Activity, Fragment of UIViewController — dit zorgt voor SoC tussen UI en logica.

In Android Jetpack overleeft ViewModel bijvoorbeeld schermrotatie, terwijl UI opnieuw wordt aangemaakt. Zonder SoC zouden we de status in Activity moeten opslaan, waardoor levenscyclusbeheer met gegevens wordt vermengd. ViewModel lost deze taak geïsoleerd op en demonstreert een zuivere implementatie van het principe van scheiding van verantwoordelijkheden.

Domain-laag en Use Cases

Use Cases bevatten platformonafhankelijke bedrijfsregels. Deze laag importeert geen Android SDK, iOS UIKit of Flutter framework. Use Case haalt gegevens uit Repository, past er bedrijfslogica op toe en retourneert het resultaat. Dankzij SoC kan één Use Case op verschillende schermen en platformen worden hergebruikt.

Een klassiek voorbeeld — ValidateAndSaveUseCase voor een registratieformulier. Het controleert de juistheid van e-mail en wachtwoord, roept UserRepository aan voor opslag en retourneert ValidationResult. Noch UI, noch de database kennen de validatieregels — ze zijn geconcentreerd op één plek, wat wijzigingen vereenvoudigt.

Data-laag en Repository

Repository abstraheert gegevensbronnen van de rest van de applicatie. ViewModel weet niet waar de gegevens vandaan komen — REST API, GraphQL, lokale database of cache. Repository beslist welke bron te gebruiken en verbergt deze logica achter een interface. Dit is SoC tussen gegevensophaling en -consumptie.

DataSource zorgt voor een nog diepere scheiding: RemoteDataSource is alleen verantwoordelijk voor HTTP-verzoeken, LocalDataSource — voor werken met Room, CoreData of SharedPreferences. Repository combineert ze en past cachingstrategieën toe. Elke DataSource kan onafhankelijk worden vervangen, wat cruciaal is bij migratie tussen servers of databases.

Een dergelijk meerlagig DataSource-systeem implementeert SoC op infrastructuurniveau: netwerkcommunicatie, lokale opslag en caching — afzonderlijke concerns, elk met hun eigen logica en levenscyclus. Bij het vervangen van de HTTP-client verandert alleen RemoteDataSource, terwijl Repository en hogere lagen onaangetast blijven, wat de praktische waarde van scheiding van verantwoordelijkheden bevestigt.

SoC in architectuurpatronen

MVP (Model-View-Presenter) — een van de eerste patronen die SoC expliciet implementeert in mobiele ontwikkeling. Presenter bevat de logica en beheert View via een interface. View is passief — het toont alleen wat Presenter zegt. De scheiding vereenvoudigt testen: Presenter wordt getest zonder emulator, en View blijft zo eenvoudig dat er niets kapot kan gaan.

MVVM voegde reactieve binding toe: View abonneert zich op wijzigingen in ViewModel via Observable of StateFlow. ViewModel bewaart geen verwijzing naar View, waardoor geheugenlekken worden geëlimineerd en concerns nog sterker worden gescheiden. In Android werd MVVM de standaard dankzij Jetpack ViewModel en LiveData, in iOS — dankzij Combine en RxSwift.

Clean Architecture van Robert Martin brengt SoC tot een radicale verdeling in ringen. De buitenste ring (frameworks en stuurprogramma's) is afhankelijk van de binnenste (entiteiten), maar niet andersom. In de praktijk implementeren mobiele projecten zelden alle vier ringen — Domain- en Data-lagen rond Presentation zijn voldoende. Maar het principe van afhankelijkheid „naar binnen" biedt aanzienlijke voordelen bij het wisselen van frameworks.

// View — alleen weergave, zonder logica
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

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

// ViewModel — bevat schermlogica, kent UIKit niet
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

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

// Use Case — bedrijfslogica, onafhankelijk van platform
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)
    }
}

Het voorbeeld toont drie niveaus van SoC: LoginViewController geeft alleen gebeurtenissen door, LoginViewModel beheert de status, LoginUseCase bevat bedrijfsregels. Elke klasse wordt onafhankelijk getest en het wijzigen van het UI-framework heeft geen invloed op Use Case.

Typische SoC-schendingen in mobiele projecten

Massive View Controller — de meest voorkomende SoC-schending in iOS. Een klasse die UI beheert, netwerkverzoeken verwerkt, JSON parseert en gegevens opslaat, schendt het principe op alle niveaus. Oplossing — elke verantwoordelijkheid in een aparte component onderbrengen: NetworkingService, JSONParser, CoreDataStack, en ViewController alleen View-beheer overlaten.

In Android is er een vergelijkbaar probleem — God Activity of God Fragment. Eén activiteit die gegevens laadt, formulieren valideert, dialogen toont en UI bijwerkt. Behandeling door ViewModel en Repository te introduceren, die status- en gegevensbeheer overnemen. ViewModel beschermt ook tegen gegevensverlies bij schermrotatie.

De derde schending — het vermengen van platform- en bedrijfscode. Bijvoorbeeld het plaatsen van een HTTP-verzoek direct in een SwiftUI View of Android Composable. Dit maakt code niet draagbaar en moeilijk te testen. De juiste aanpak — het verzoek naar Repository verplaatsen, dat via Use Case wordt aangeroepen, en View abonneert zich alleen op het resultaat. Elk onderdeel van het systeem lost zijn eigen taak op en overschrijdt zijn grenzen niet.