La cererea cititorilor, următorul articol privind modelele de design va fi dedicat modelului Observer (Observer). Acest model de design este, de asemenea, cunoscut sub numele Dependents and Publisher-Subscriber.
Implementarea acestui model este utilizată pentru a monitoriza starea obiectelor din sistem. Dacă starea obiectelor se schimbă în timpul ciclului lor de viață, Observatorul notifică alte părți ale sistemului despre aceste evenimente.
În acest articol, voi încerca să descriu acest model cât mai simplu și mai ușor posibil și să dau un exemplu de cod Java care implementează Observatorul.
În ce cazuri este folosit Observatorul?
- Dacă un obiect ar trebui să trimită mesaje către alte obiecte, dar nu poate sau nu ar trebui să știe despre dispozitivul lor intern;
- Dacă modificați alte obiecte atunci când schimbați un obiect;
- Pentru a preveni legăturile puternice între obiectele sistemului;
- Monitorizarea stării anumitor obiecte ale sistemului;
Un obiect observabil, sau mai degrabă un subiect sau subiect, trebuie să furnizeze o interfață pentru înregistrarea și dezabonarea ascultătorilor.
Ei bine, observatorii înșiși ar trebui cel puțin să aibă o metodă deschisă prin care să fie o alertă despre schimbarea stării subiectului. Această metodă este adesea numită notificare.
Deoarece pot fi mulți observatori, puteți utiliza colecția de observatori pentru a simplifica lucrul cu ei. Folosesc acest cod în acest caz:
Clasa EmptyObserver poate fi utilă dacă observatorul are un număr suficient de mare de metode de notificare. Apoi, folosind clase anonime, putem crea cu ușurință observatorii "foarte specializați" de care avem nevoie (cei cu un număr limitat de metode) în mișcare:
Mai mult, o instanță a clasei observatorilor este plasată în subiectul în spatele căruia urmează să se desfășoare observația. În toate locurile de cod în care se desfășoară acțiunea care ne interesează cu clasa subiect, adăugăm apelul corespunzător pentru a anunța metoda din colecția observatorului:
Un exemplu clasic de utilizare a modelului Observer sunt clasele din pachetul Java Swing. În modelul Swing, observatorul este folosit pentru a organiza o interdependență slabă între model și obiectele grafice. Metodele de notificare sunt numite atunci când valorile proprietăților modelului se schimbă și transmit informații widget-urilor.
Apropo, recomand foarte mult ca toată lumea să vadă codul sursă al Java Swing. Aceasta este într-adevăr o bibliotecă proiectată foarte de înaltă calitate.
Cât despre sprijinirea multithreading și sincronizarea unei liste de obiecte notificate?
Pentru evitarea blocajului, nu poți da o notificare prin ciocnirea unei astfel de liste ...
1) Fiecare obiect notificat are un număr de referință, care, atunci când este adăugat la listă, crește și când acesta este șters;
2) Lucrul cu lista este controlat de un primitiv de sincronizare;
3) Dacă doriți să copiați lista de notificare de Locke, în timp ce creșterea toate contează obiectele de referință (cel mai convenabil de a folosi autopointerov listă de tip ATL :: CComPtr), îndepărtați de blocare și notifică ascultătorii de pe lista de copii, iar apoi se reduce numărătorile de referință.
judecând după exemplul dvs. nu vedeți diferența dintre ascultători și callback-urile? Sau este același lucru? arătați acest moment sau eșantion pentru diferențe vă rugăm să schițați!
Yarik: Principala diferență între ascultător și apelul de apel este că apelul de apel poate fi unul (sau nici unul, scriu în Delphi, pentru că nu există). ascultător'Pot fi cât de mult doriți. Adevărat, există o avertizare. Listenery dacă mulți dintre ei nu pot să știu despre unul pe altul. Iar în apel invers eveniment poate smastryachit apel invers lanț (ca orice WinAPI, cum ar fi SetWindowsHookEx, sau SetCliboardViewer) ,, în timp ce acesta va „ști“ despre mai devreme ustenovlennom apel invers (anterior) și să fie în măsură să aducă la „partea de sus“ a ierarhiei atârnat ultimul apel invers înregistrat. Cât despre mine, asa ca ideea de apel invers mai „nativ“ decât ascultător. Deși, în cazul în care numai pentru că eu pot controla în mod clar: Vreau să fiu numit ultimul, în primul rând, sau în funcție de condițiile nu cauzează callback ulterioare ( „mananca“ un eveniment). În cazul ascultătorului de a face așa ceva nu poate fi. Dar evenimentul de logare într-un model de ascultător este mult mai simplu: nu există variabile temporare, probleme cu modelele numesc stdcall, cdecl, etc - pe scurt, skukota.