Principiul de substituție al Barbara Liskov

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită la 29 martie 2022; verificările necesită 4 modificări .

Principiul de substituție Liskov ( LSP ) în programarea orientată pe obiecte este o  definiție specifică a subtipului propusă de Barbara Liskov în 1987 la o conferință într-o conferință intitulată Data Abstraction and Hierarchy [1] .

Într-un articol ulterior [2] , Liskov și-a formulat pe scurt principiul după cum urmează:

Fie o proprietate care este adevărată pentru obiecte de un anumit tip . Atunci trebuie să fie valabil și pentru obiectele de tip unde este un subtip de tip .

Robert S. Martin a definit [3] acest principiu după cum urmează:

Funcțiile care folosesc un tip de bază trebuie să poată folosi subtipuri ale tipului de bază fără să știe.

Astfel, ideea lui Liskov de „subtip” definește noțiunea de substituție  - dacă S este un subtip de T, atunci obiectele de tip T dintr-un program pot fi înlocuite cu obiecte de tip S fără nicio modificare a proprietăților dezirabile ale programului ( de exemplu, corectitudinea ).

Acest principiu este cel mai important criteriu de evaluare a calității deciziilor luate la construirea ierarhiilor de moștenire. Poate fi formulat ca o regulă simplă: tipul S va fi un subtip al lui T dacă și numai dacă fiecărui obiect oS de tip S îi corespunde un obiect oT de tip T în așa fel încât pentru toate programele P implementate în termeni de T, comportamentul lui P nu se va schimba, dacă oT este înlocuit cu oS.

În termeni mai simpli, putem spune că comportamentul claselor care moștenesc nu ar trebui să intre în conflict cu comportamentul specificat de clasa de bază, adică comportamentul claselor care moștenesc ar trebui să fie așteptat pentru codul care utilizează variabila de tip de bază.

Sutter și Alexandrescu, în ghidul lor de utilizare a C++, folosesc, de asemenea, sintagma „o subclasă nu ar trebui să necesite de la apelant mai mult decât clasa de bază și nu ar trebui să ofere apelantului mai puțin decât clasa de bază” pentru a exprima acest principiu. Potrivit acestor autori, moștenirea publică în C++ poate fi folosită numai atunci când satisface principiul Liskov. Moștenirea privată, în opinia lor, poate fi utilizată pentru a accesa partea protejată a bazei și pentru a anula metodele virtuale . În orice alt caz, adică doar pentru reutilizarea codului de la bază, moștenirea nu poate fi folosită.

Motive: Utilizarea moștenirii publice pentru reutilizarea codului face ca lumea exterioară să considere clasa Derivată ca o variație a clasei de bază și poate exista cod care exploatează în mod explicit acest fapt. Acest lucru limitează foarte mult domeniul de aplicare al arhitectului de a menține și refactoriza în continuare clasa Derivată.

Proiectare contract

Principiul substituției Liskov este strâns legat de metodologia de programare a contractelor și duce la unele restricții asupra modului în care contractele pot interacționa cu moștenirea :

De asemenea, principiul LSP implică faptul că metodele subclaselor nu pot arunca alte excepții suplimentare decât cele care sunt ele însele subclase de excepții aruncate de metodele superclaselor. Vedeți covarianța și contravarianța și tipurile de date .

O funcție care folosește o ierarhie de clasă cu încălcarea principiului Liskov, pe lângă faptul că operează cu o referință la clasa de bază, este, de asemenea, forțată să cunoască despre subclasă. O astfel de funcție încalcă principiul deschis/închis , deoarece necesită modificare dacă apar noi clase derivate în sistem.

În acest context, principiul substituției poate fi reformulat astfel:

Funcțiile care folosesc referințe la clase de bază ar trebui să poată folosi obiecte ale claselor derivate fără să știe.

Principiul Barbara Liskov ne face să ne gândim la ce este o „declarație de tip” în ceea ce privește limbajul de programare orientat pe obiecte pe care îl folosim. Este suficient pentru noi să descriem interfața unui obiect folosind o clasă abstractă obișnuită cu o listă de metode, tipuri de parametri și o valoare returnată? Cum putem declara cerințele pentru valorile parametrilor și proprietăților metodei pe care le va avea valoarea returnată? Cum descriem excepțiile pe care o metodă le poate arunca în timpul rulării? Cum putem descrie schimbarea stării unui obiect în diferite etape ale ciclului său de viață?

Punându-ți aceste întrebări și găsind răspunsurile, poți proiecta un sistem care să satisfacă de fapt principiul substituției lui Barbara Liskov.

Vezi și

Note

  1. ↑ Liskov, Barbara Abstracția datelor și ierarhia (4 octombrie 1987). Preluat la 23 martie 2008. Arhivat din original la 30 iunie 2019.
  2. ↑ Liskov, Barbara ; Aripă, Jeanette . Subtiparea comportamentală folosind invarianți și constrângeri ( PS ) (iulie 1999). Consultat la 5 octombrie 2006. Arhivat din original la 30 august 2012.
  3. ↑ Martin, Robert Principiul substituției Liskov ( PS ). Consultat la 5 octombrie 2006. Arhivat din original la 30 august 2012.

Link -uri