Patterns OOP cu exemple și descrierea

Am decis să scrie pe scurt despre modelele comune în viața noastră, și așa mai departe.

Registry (registru, intrările de jurnal)

Singleton Registry (Registrul singur) - a nu se confunda cu Singleton Registry (registru unic)

„Înregistrare“ este adesea un „singuratic“, dar nu ar trebui să fie întotdeauna în acest fel. De exemplu, putem începe în conturile mai multor reviste, unul angajați de la „A“ la „M“, celălalt de la „H“ la „Z“. Fiecare jurnal va fi „Registrul“, dar nu un „singuraticul“, deoarece jurnalele au 2.

Multiton (bazin de „single“) sau cu alte cuvinte Registrul Singleton (un singur registru) - nu trebuie confundat cu Registrul Singleton (Registrul singur)

De multe ori „registru“ este folosit doar pentru depozitare „singur.“ dar, pentru că model „registru“ nu este „model generativ“ și-ar dori să ia în considerare „registru“, în legătură cu un „singuratic“. De aceea a inventat modelul Multiton. care este în esență un „registru“ care conține mai multe „single“, fiecare dintre care are propriul „nume“, prin care puteți avea acces la ea.

Pe scurt. Acesta vă permite să creați obiecte din această clasă, dar numai în cazul de denumire a obiectului. Nu există exemple de viață, dar pe Internet naryl un exemplu:

Piscina Obiect (facilități de piscină)

De fapt, acest model este „Registru“, care stochează numai obiecte, nu siruri de caractere, tablouri, etc. tipuri de date.

Esența modelului este descris aproape complet dupa numele acestuia. Când aveți nevoie pentru a obține unele elemente, cum ar fi pachete de suc, nu trebuie să știe modul în care acestea sunt realizate într-o fabrică. Tu spui doar, „Dă-mi un pachet de suc de portocale“ si „fabrica“ revine la pachetul dorit. Cum? Toate acestea decide fabrica în sine, cum ar fi „copie“ un standard existent. Scopul principal al „fabrică“ este de a fi în măsură, dacă este necesar, pentru a schimba procesul de „aspect“ pachet de suc, iar majoritatea consumatorilor nu face nimic despre acest lucru era necesar să se raporteze că a cerut-o ca înainte. Ca o regulă, o fabrica este angajată în „fabricație“ este doar un fel de „produse“. Nu este recomandat „fabrica de suc“, înființat în vederea producției de anvelope auto. „Loner“ este adesea creată ca și în viață, modelul de „fabrica“.

Aș dori să se constate că metoda din fabrică este, de asemenea, un model, aceasta se numește metoda Factory (metoda din fabrică).

Deci, ne-am dat seama deja că „Fabrica“ - un automat, are deja totul pregătit, iar tu spui exact ceea ce ai nevoie. „Builder“ - o planta care produce aceste băuturi conține toate operațiunile complexe și pot asambla obiecte complexe de la simple (ambalaje, etichete, apă, arome etc.), în funcție de cerere.

Reamintind „fabrică“, ea servește, de asemenea, pentru a crea obiecte, dar cu o abordare ușor diferită. Imaginați-vă la bar, bei bere, și vă este, terminat o, tu vorbești barmanului - fă-mă un altul ca el. Barmanul, la rândul său, se uită la o bere pe care le bea și face o copie, așa cum ați cerut. În PHP implementează deja un astfel de model, este numit o clonă.

Inițializarea leneș (inițializarea întârziată)

injecție Dependență (Dependency Injection)

injecție permite Dependență să transfere o parte din responsabilitatea pentru a putea funcționa la alte obiecte. De exemplu, dacă avem nevoie de a angaja personal nou, nu putem crea un departament de resurse umane, și să introducă dependența de recrutare a companiei, care a activa prima cerere „avem nevoie de un om“ va fie el însuși funcționa ca un departament de resurse umane, sau găsi o altă societate (folosind „serviciul de localizare“), care furnizează aceste servicii.
„Introducerea de dependență“ face posibilă trecerea și piese interschimbabile, fără pierderea funcționalității de ansamblu.

Acum, imaginați-vă că noi nu vrem suc de mere, vrem portocale.

După cum puteți vedea, a trebuit să se schimbe, nu numai sub formă de suc, dar, de asemenea, pentru a verifica tipul de suc nu este foarte convenabil. Mult mai bine pentru a utiliza principiul Dependență inversiune:

Dependență de inversare este uneori confundat cu injecție Dependență, dar nu trebuie confundate, deoarece Dependență inversiune este un principiu, nu un model.

Locator de serviciu (serviciu de localizare)

Dacă vorbim despre viața reală, este, probabil, un bun exemplu de serviciu Locator-sau poate php-extensie a DOP, astfel cum Astăzi vom lucra cu baza de date MySQL, și mâine putem lucra cu PostgreSQL. După cum știți, clasa noastră nu este important pentru care baza de date a trimite datele lor, este important ca el poate face acest lucru.

Spre deosebire de injectie Dependență Locator Serviciul

Dacă nu ați observat, eu vreau să explic. Dependență injecție ca urmare a randamentelor nu este un serviciu (care poate fi ceva undeva pentru a livra) și sunt utilizate datele obiectului.