Observator - un observator (modele de design), sferă

Pentru a satisface cerințele noi ale clienților, vedem avantajele unei arhitecturi bazate pe interfețe. Pentru a adăuga abilitatea de a vă abona la entitățile juridice, este suficient doar să creați clasa companiei. Singura diferență față de primul exemplu este aceea că implementează și interfața Subsciber.







Nu este nevoie să schimbăm clasa Publisher. Prin faptul că utilizează abonatul abstractizat.

Observator - un observator (modele de design), sferă

Observator - un observator (modele de design), sferă

Ieșirea de pe ecran nu diferă de primul exemplu. Sper că nu are nici un rost să explicăm faptul că un astfel de cod este mai precis și mai ușor de întreținut.

Acum hai să vorbim despre teoria acestui șablon.

Observator - un observator (modele de design), sferă

Acordați atenție schemei. Clasele care sunt subscrise se numesc SUBJECTS, iar cei care semnează sunt numiți OBSERVERS. În exemplul nostru, subiectul era interfața abonabilă, iar observatorii au fost interfața abonatului. În consecință, implementarea lor a fost ConcreteSubject și ConcreteObserver

Schema de subiecte poate fi o interfață sau o clasă. Opțiunea atunci când este o interfață este mai flexibilă, cel puțin în Java este. Motivul pentru aceasta este că Java nu permite moștenire multiplă. Dacă clasa dvs. de subiect este deja descendentul unei persoane, atunci aceasta vă impune anumite restricții. Nu există astfel de limitări dacă lucrați cu interfața.

Observatorul poate fi, de asemenea, o clasă sau o interfață, cu aceleași consecințe.

Nu este necesar să urmați schema UML foarte precis. Vrem să obținem avantajele sale și să nu copiem schema în cod. Nu am lăsat o referință la subiect în anumite implementări ale observatorului, așa cum se face în diagrama. Vedeți linia punctată de la ConcreteObserver. Și nu a creat o metodă get / setState în ConcreteSubject.

Rețineți că subiectul nu trebuie să știe nimic despre punerea în aplicare a observatorilor.

Modelul de observator definește o relație una-la-multe între obiecte.

Un subiect este numeroși observatori.

Astfel, atunci când se schimbă o stare a unui obiect, apare notificarea automată și actualizarea tuturor obiectelor dependente.







Obiectele dependente sunt observatori.

  1. Singurul lucru pe care un subiect îl știe despre observator este că implementează interfața Observer. Acest lucru ne permite să adăugăm noi tipuri de observatori fără a modifica subiectul.
  2. Observatorii noi vă pot abona și dezabona de la primirea de actualizări în orice moment.
  3. Subiectul și observatorul pot fi reutilizate.
  4. Schimbarea nu afectează cealaltă.

În plus, cele de mai sus se datorează faptului că activitatea codului nu trebuie să depindă de ordinea de notificare a observatorilor.

În Java, există un suport încorporat pentru un model dat

Această clasă este java.util.Observable, este extinsă de subiecți. Am vorbit deja despre limitările care ne moștenesc în implementare prin intermediul clasei. Totuși există java.util.Observer, aceasta este interfața pentru observatori.

Să schimbăm ultimul exemplu pentru a folosi clasa și interfața dată.

Primul lucru pe care îl facem este să ștergem interfețele noastre.

Observator - un observator (modele de design), sferă

Observator - un observator (modele de design), sferă

Clasele Companiei și Persoanei implementează acum interfața Observer. Metoda de actualizare cu al doilea parametru primește o referință la obiectul jurnal.

Observator - un observator (modele de design), sferă

Clasa editor nu mai este responsabilă pentru abonarea și dezabonarea. Toate aceste metode sunt în strămoșii săi. Aceasta este o veste bună, pentru că nu avem nevoie să le punem în aplicare acum. Mai mult, aceste metode sunt sincronizate. Pentru ca totul să funcționeze, trebuie să vă amintiți despre metoda setChanged, care comută starea clasei în modul "schimbat". Dacă acest lucru nu se face, atunci observatorii nu vor primi actualizări.

Observator - un observator (modele de design), sferă

Rezultatul pe ecran nu diferă de exemplele anterioare.

În JDK există mai multe clase și interfețe similare. De exemplu, clasa java.beans.PropertyChangeSupport și interfața java.beans.PropertyChangeListener

Dacă nu fi leneș, căutați-vă singur.

Un alt tip de observator

Dacă editorii noștri au produs și ziare, atunci am putea pune în aplicare șablonul puțin diferit. Pentru a oferi mai multă flexibilitate clasei noastre. Observatorii pot obține un ziar sau o revistă. Pur și simplu, trebuie să facă o cerere prin intermediul getter-ului corespunzător pentru acest lucru.

Observator - un observator (modele de design), sferă

Observator - un observator (modele de design), sferă

De exemplu, o persoană scrie numai reviste, iar compania doar ziare. Acest lucru poate fi realizat fără a utiliza implementarea java a acestui șablon. De exemplu, oferind fiecărui observator o legătură cu editorul. Nu vă voi da codul complet, încercați să-l implementați singur.

Citește cărți, pa!







Articole similare

Trimiteți-le prietenilor: