de Sihui Huang

Modele de proiectare: comandă și concierge în viață și rubin

Definiția modelului de comandă este una stresantă de privit. Definiția formală este că:

• încapsulează o cerere ca obiect
• permițându-vă astfel să parametrizați alte obiecte cu solicitări diferite, solicitări de coadă sau jurnal și să susțineți operațiuni care nu pot fi anulate.

Să uităm de asta pentru o secundă și să facem o excursie în Hawaii.

Și trăiește într-un hotel de lux.

Am petrecut ziua pe plajă, am făcut scufundări și am făcut câteva vizite. Este timpul să ne întoarcem la hotel pentru a ne răci, a mânca și pentru a planifica ziua următoare.

După ce ne-am întors la hotel, vrem să:

1. Obțineți room service pentru cină
2. Obțineți servicii de spălătorie pentru că nu am adus haine suplimentare
3. Obțineți un ghid de călătorie pentru Kauai, insula spre care mergem mâine

Verificăm meniul de servicii al hotelului și găsim trei articole de servicii care corespund nevoilor noastre.

Apelăm apoi la recepție pentru a face aceste trei cereri. Un concierge ne preia apelul, ne notează lista de solicitări și acționează asupra fiecărei cereri de servicii, conform instrucțiunilor din meniul de servicii.

Apoi, fiecare membru al personalului execută în funcție de fiecare cerere specifică:

1. Bucătarul din bucătărie începe să gătească
2. Departamentul de curățenie trimite un personal în camera noastră pentru a ne ridica hainele
3. Personalul din hol prinde un ghid de călătorie și îl livrează în camera noastră

Să recapitulăm ce tocmai s-a întâmplat.

A. Am selectat serviciile dorite din meniu și le-am trimis la un concierge.

b. Concierge a notat aceste cereri de servicii ca o listă.

c. După ce am închis, instruiți de meniul de servicii, concierge ne-a trimis cererile către departamentele corespunzătoare.

d. Fiecare departament a executat la cererea dată.

Să vedem acțiunile din Ruby.

1. Am trimis aceste trei cereri conciergei:

2. Aceste cereri au intrat într-o listă de care concierge ține evidența:

Să vedem că în acțiune (consolă):

După cum putem vedea, după we a depus trei cereri, aceste solicitări au fost într-un request_list având grijă de concierge.

3. Instruit de meniul de servicii, concierge a trimis solicitările noastre către departamentele corespunzătoare.

Codul de mai sus ar trebui să funcționeze bine.

Cu excepția unui singur lucru …

Aceasta miroase rău.

Mai exact, partea în care avem cazurile de comutare:

De ce această parte miroase urât?

1. Dacă hotelul oferă douăzeci de servicii, în loc de trei, metoda va fi foarte lungă.
2. Vrem să oferim servicii noi sau să eliminăm un serviciu existent. Cu toate acestea, de fiecare dată trebuie să deschidem Concierge clasa și redefinirea act_on_requestsmetodă.

Tmetoda știe prea multe și necesită schimbări frecvente. A avea împreună aceste două combinații este aproape întotdeauna un lucru rău.

De ce?

O metodă care necesită modificări frecvente este o metodă pe care trebuie să o actualizați des. De fiecare dată când actualizați o bucată de cod este o oportunitate de a introduce noi erori în sistem.

Când metoda cunoaște, de asemenea, o tonă – și este lungă – șansele de a o încurca la actualizare cresc semnificativ. Acesta este raționamentul din spate un principiu de proiectare despre care am vorbit mai devreme – încapsulează ce variază.

E timpul să refacem!

Trebuie să existe o modalitate mai bună decât aceasta:

Aruncă o privire mai atentă și gândește-te.

Să reformulăm ce face codul în engleză. Parcurgem cererile din lista de solicitări. Pentru fiecare solicitare, în funcție de tipul de serviciu, oferim datele aferente departamentului corespunzător și executăm solicitarea. În esență, parcurgem solicitările și le executăm în mod corespunzător.

Dar dacă fiecare cerere ar ști să se execute singură?

Atunci metoda poate fi la fel de simplă ca:

În loc să lase act_on_requests metoda decide modul în care trebuie gestionată fiecare solicitare, distribuim responsabilitatea și cunoștințele înapoi fiecărei solicitări și lăsăm-o să decidă cum trebuie tratată singură.

Acestea fiind spuse, solicitările noastre ar putea arăta astfel:

Și actualizat Concierge va arata ca:

Cu codurile actualizate, iată cum noi, clienții hotelului, trimitem cereri la concierge.

Este destul de ușor să creați un alt serviciu.

De exemplu, hotelul ne permite, de asemenea, să rezervăm SPA:

Serviciul nu acceptă numai execute (efectuarea unei rezervări la spa) dar și undo (anularea rezervării).

Să presupunem că hotelul oferă, de asemenea, un alt mod de a solicita servicii fără a fi nevoie să sunați la concierge – un panou care solicită servicii:

Putem doar apăsa butonul și serviciul cu o setare implicită va fi livrat în camera noastră.

Iată codul pentru ServicePanel:

Iată cum putem crea un panou de servicii:

?? Acum folosim modelul de comandă! ??

Să revedem definiția modelului de comandă. Aceasta:

• încapsulează o cerere ca obiect
• permițându-vă astfel să parametrizați alte obiecte cu solicitări diferite, solicitări de coadă sau jurnal și să susțineți operațiuni care nu pot fi anulate.

1. „încapsulează o cerere ca obiect”

Fiecare dintre clasele de servicii pe care le-am creat, RoomService, LaundryService, TripPlanningService, și SpaReservationService, este un exemplu de încapsulare a unei cereri ca obiect.

Recapitulare:

2. „permițându-vă astfel parametrizarea altor obiecte cu cereri diferite”

ServicePanel este un exemplu de parametrizare a unui obiect cu cereri diferite.

Recapitulare:

3. „cereri de coadă sau jurnal”

Cererile noastre au fost la coadă în timp ce concierge le prelua la telefon.

Recapitulare:

4. și să susțină operațiuni care nu pot fi anulate.

SpaReservationService suporturi undo.

Recapitulare:

Mulțumesc pentru lectură!

Nu uitați să vă abonați. : D

Acest lucru a fost publicat inițial pe blogul meu, Modele de proiectare în viață și Ruby.