Observer — conceptele cheie ale pattern-ului de abonare la modificări

Ce este Observer: esența pattern-ului observator?

Observer (observator) — un pattern comportamental GoF care definește o dependență „unu la mulți" între obiecte. Când un obiect (Subject sau Observable) își schimbă starea, toate obiectele dependente (Observers) sunt notificate și actualizate automat. Pattern-ul implementează cuplarea slabă: editorul nu cunoaște clasele concrete ale abonaților — doar că acestea implementează interfața Observer.

Structura Observer include interfața Subject cu metodele attach(), detach(), notify() și interfața Observer cu metoda update(). ConcreteSubject stochează starea și lista de abonați. ConcreteObserver implementează update() și reacționează la modificări. În dezvoltarea mobilă, implementarea clasică GoF este rar întâlnită — este înlocuită de mecanisme încorporate: NotificationCenter, Combine, Flow, LiveData, care implementează aceeași idee cu API modern.

Modelul Push vs Pull — în modelul Push, Subject trimite date tuturor abonaților (NotificationCenter.post). În modelul Pull, Subject doar notifică, iar abonatul preia singur datele. Android LiveData folosește Push (datele sunt transmise în observe), RxJava/Flow suportă ambele modele. Alegerea depinde de sarcină: Push este mai simplu pentru actualizări UI, Pull este mai eficient pentru volume mari de date pe care abonatul poate nu dorește să le primească.

Observer în iOS: NotificationCenter, Combine și KVO

NotificationCenter — mecanismul încorporat iOS/macOS pentru implementarea Observer. Editorul trimite Notification prin NotificationCenter.default.post(name:, object:, userInfo:). Abonatul se înregistrează prin addObserver(forName:, queue:, using:). NotificationCenter suportă notificări numite (Notification.Name) și poate transmite orice date în userInfo. UIKeyboardWillShowNotification, UIApplicationDidEnterBackgroundNotification — exemple de sistem.

extension Notification.Name {
    static let userDidLogin = Notification.Name("userDidLogin")
}

// Editor
NotificationCenter.default.post(
    name: .userDidLogin,
    object: nil,
    userInfo: ["userId": "123"]
)

// Abonat
class ProfileViewModel {
    private var observers: [NSObjectProtocol] = []

    func startObserving() {
        let observer = NotificationCenter.default.addObserver(
            forName: .userDidLogin,
            object: nil,
            queue: .main
        ) { [weak self] notification in
            guard let userId = notification.userInfo?["userId"] as? String else { return }
            // Abonatul reacționează la eveniment
            self?.loadProfile(userId: userId)
        }
        observers.append(observer)
    }

    func stopObserving() {
        observers.forEach { NotificationCenter.default.removeObserver($0) }
        observers.removeAll()
    }
}

Combine framework — o alternativă reactivă modernă la NotificationCenter, disponibilă din iOS 13. Publisher (NotificationCenter, URLSession.Timer) — editor, Subscriber (sink, assign) — abonat. Combine adaugă operatori (map, filter, combineLatest) pentru transformarea fluxului de date. @Published — property wrapper care notifică automat abonații despre modificări. În MVVM cu SwiftUI, Combine înlocuiește NotificationCenter pentru legarea ViewModel și View.

KVO (Key-Value Observing) — un mecanism vechi ObjC/Swift pentru observarea proprietăților individuale ale obiectelor. @objc dynamic var name: String — proprietatea observată. observe(.name) — abonare. KVO funcționează doar cu clase compatibile @objc și moștenirea ObjC. Apple recomandă Combine și @Published în loc de KVO în proiecte noi. KVO rămâne relevant pentru compatibilitatea UIKit în proiecte hibride.

Observer în Android: LiveData, StateFlow și SharedFlow

LiveData — o componentă Android Architecture Components pentru implementarea Observer. Clasă Observable care notifică abonații despre modificările datelor. LiveData ține cont de ciclul de viață: abonații (LifecycleOwner) se dezabonează automat la distrugere. LiveData este modelul Push: datele sunt transmise în observe(). LiveData este blocul de construcție de bază MVVM în Android înainte de introducerea Jetpack Compose.

// ViewModel — editor
class UserViewModel : ViewModel() {
    private val _user = MutableLiveData<User?>(null)
    val user: LiveData<User?> = _user

    fun loadUser(id: String) {
        viewModelScope.launch {
            val result = userRepository.getUser(id)
            _user.value = result
        }
    }
}

// Fragment — abonat
class UserFragment : Fragment() {
    private val viewModel: UserViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        viewModel.user.observe(viewLifecycleOwner) { user ->
            // Abonatul reacționează la modificări
            userName.text = user?.name
            userEmail.text = user?.email
        }
    }
}

StateFlow și SharedFlow — tipuri reactive din Kotlin Coroutines care au înlocuit LiveData în Jetpack Compose. StateFlow — state holder observabil cu o valoare curentă fixă. SharedFlow — hot flow configurabil fără stare, potrivit pentru evenimente unice (navigare, toasturi). Ambele tipuri sunt strâns integrate cu Compose: collectAsState(), collectAsEffect(). StateFlow este obligatoriu în proiectele Android moderne cu Compose.

LiveData vs StateFlow — LiveData este legat de Android Lifecycle, StateFlow este independent de platformă. StateFlow suportă coroutines, operatori (map, filter) și se testează fără dependințe Android. LiveData este mai simplu pentru compatibilitatea cu Java. Google recomandă StateFlow pentru proiecte noi cu Kotlin + Compose, LiveData — pentru suportul proiectelor vechi sau cod Java.

Gestionarea abonamentelor și scurgeri de memorie

Scurgeri de memorie (memory leaks) — principala problemă a Observer fără gestionarea corectă a abonamentelor. Dacă abonatul (Activity, Fragment, UIViewController) este distrus dar nu s-a dezabonat, editorul continuă să păstreze referința către el, iar garbage collector nu poate elibera memoria. În Android, LifecycleOwner (Activity/Fragment) trebuie să apeleze removeObserver() sau să folosească observe(viewLifecycleOwner). În iOS — removeObserver în deinit sau disposeBag în Combine.

Referință slabă (weak reference) în abonați — în blocul de abonare folosește [weak self] în Swift și referă-te la lifecycle scope în Kotlin. LiveData gestionează automat abonamentul prin LifecycleOwner — abonamentul este activ doar când Lifecycle este în starea STARTED sau RESUMED. StateFlow în Compose folosește collectAsState() ținând cont de lifecycle. NotificationCenter în iOS necesită [weak self] explicit, deoarece closure-ul face referință puternică la self.

Observer vs Publisher-Subscriber: care este diferența

Observer (GoF) și Publisher-Subscriber (PubSub) — pattern-uri similare, dar diferite. În Observer, editorul notifică direct abonații apelând metodele lor. Editorul știe despre abonați (stochează o listă). În PubSub, editorul și abonatul nu știu unul despre celălalt — între ei se află un intermediar (Event Bus, Message Queue, NotificationCenter). Editorul trimite un mesaj pe un canal, abonatul ascultă canalul. PubSub asigură o cuplare mai slabă.

Exemple de PubSub în dezvoltarea mobilă — NotificationCenter în iOS poate fi considerat PubSub: editorul nu cunoaște abonații — doar publică notificarea. EventBus sau Otto în Android (învechite). SharedFlow cu BroadcastChannel — PubSub în lumea Kotlin. În sisteme distribuite, PubSub se implementează prin RabbitMQ, Kafka, Google PubSub. Pentru dezvoltarea mobilă, PubSub este util în arhitectura modulară, unde modulele nu trebuie să depindă unele de altele.

Ce să alegi — pentru actualizări UI (ViewModel → View) folosește Observer (LiveData, StateFlow, @Published). Pentru evenimente intermodule (autentificare, deconectare, schimbare temă) — PubSub (SharedFlow, NotificationCenter, EventBus). Observer este mai simplu și mai eficient în cadrul unui ecran, PubSub este mai flexibil pentru evenimente globale, dar mai dificil de depanat din cauza dependințelor implicite.