Phm polimorfism, încapsulare și solidă

Am decis să-mi scriu o scurtă amintire pentru mine și pentru ceilalți, iar apoi în vasta Ineta mi-a plăcut să pictez zamadreno.

Polimorfism în PHP

Limba PHP susține polimorfismul în sensul că vă permite să utilizați instanțe ale subclasei în locul instanțelor clasei părinte. Faptul este că în fiecare clasă poate exista o singură metodă cu un nume specific. exemplu:







// Completați matricea publicării cu obiecte derivate din publicație
$ publicații [] = Știri noi ();
$ publicații [] = anunț nou ();

foreach (publicații $ ca publicație $) dacă (publicație $ publicație de publicare) $ publicație-> do_print (); // putem tipări în siguranță datele pe care le imprimați
>
altceva // excepție sau tratarea erorilor
>
>

Principalul lucru aici este ultima parte. Aceasta este esența polimorfismului. Utilizăm același cod pentru obiecte din diferite clase.

Un exemplu în practică: utilizatorul dorește să urmărească cele mai recente actualizări ale publicațiilor și nu contează dacă sunt articole sau știri sau ceva de genul.

Încapsulare în PHP

Encapsularea poate fi comparată cu performanța unei mașini din punctul de vedere al unui șofer tipic. Mulți șoferi nu înțeleg detaliile aranjamentului intern al mașinii, dar în același timp o controlează exact așa cum a fost intenționat. Să nu știe cum este aranjat motorul, frâna sau direcția, - există o interfață specială care automatizează și simplifică aceste operații complexe. Acest lucru se aplică și la încapsulare și la OOP - multe detalii ale "dispozitivului intern" sunt ascunse de utilizator, permițându-i să se concentreze pe rezolvarea problemelor specifice. În PLO, această capacitate este oferită de clase, obiecte și diverse mijloace de exprimare a relațiilor ierarhice între ele.







În sensul software al cuvântului, incapsularea este ascunderea variabilelor din clasă de la utilizator. Ie Toate variabilele (proprietățile) clasei pe care o faci private, iar metodele sunt publice. Ie puteți interacționa cu proprietățile clasei prin metode.
Frumusețea acestei abordări este că în metodele pe care le puteți introduce codul pentru a verifica eventualele erori și apoi nu vă gândiți la ele atunci când este apelată metoda.

În ceea ce privește SOLID

Vreau să clarific principiile substituției lui Liskov și inversarea dependenței. este teoretic dificil să înțelegi diferența dintre ele, dar voi încerca.

publicație clasă abstractă <
funcția finală protejată getId ()id;>
>

clasa Știri extinde Funcția publică de publicare printId () eco 'News ID:'. $ this-> getId ();
>
>
clasa articol extinde Funcția de publicare publica printId () echo 'ID articol:'. $ this-> getId ();
>
>

Înlocuirea lui Liskov prevede:

„Funcțiile care utilizează tipul de bază, ar trebui să poată utiliza subtipul de tipul de bază, nu se știe despre ea“ - aceasta înseamnă că, dacă o numim o anumită metodă de Claes, atunci această clasă trebuie să fie substituit cu (polimorfism):

„Subclase nu poate înlocui comportamentul subtipurile de clasă de bază ar trebui să completeze tipuri de bază ..“ - ceea ce înseamnă că trebuie să extindem clasa de baza (folosind Extend), dar suprascrie metodele clasei de bază nu poate (incapsulare + asa ca am scris o finală, vezi mai sus ..).

Stările de inversare a dependenței:

„Dependențele existente în cadrul sistemului se bazează pe abstracții“ - înseamnă că clasa publicării trebuie să fie abstracte sau interfață, și este apoi necesar să se transfere în funcție de (polimorfism. - a se vedea mai sus printPublicationId apeluri).

„Modul de nivel superior este independent de nivel inferior module abstractii nu ar trebui să depindă de detaliile Detalii ar trebui să depind de abstracții ..“ - înseamnă că moștenesc din clasa abstractă (sau interfața) este posibil, și să moștenească clasa abstractă de obicei nu se poate (în caz contrar, puteți ajunge în moștenire completă a fundului).







Trimiteți-le prietenilor: