Liskov Substitutieprincipe: Zorgen voor betrouwbare klasse-hiërarchieën

In objectgerichte programmering, bouwsystemen die zowel robuust als aanpasbaar zijn, is de permanente uitdaging. Onder de fundamentele principes die ontwikkelaars richting dat doel leiden is het Liskov Substitutie Principe (LSP). Ontworpen door Barbara Liskov in 1987, LSP is de derde pijler van de vijf SOLID principes voor software-ontwerp, en het richt zich op een kritische vraag: wanneer u een subklasse die erft van een ouderklasse, kunt u veilig elk geval van de ouder vervangen door een instantie van het kind zonder het programma te breken? Het principe is een definitieve . . . . . . maar alleen als de subklasse respecteert het contract dat door de ouder is gedefinieerd. Dit artikel onderzoekt de Liskov Substitutie Principe in detail, het verstrekken van duidelijke definities, praktische voorbeelden, en strategieën om ervoor te zorgen dat uw klasse hiërarchieën betrouwbaar en flexibel blijven.

Wat is het Liskov Substitutie Principe?

Het Liskov Substitutie Principe stelt dat objecten van een superklasse vervangbaar moeten zijn met objecten van zijn subklassen zonder de juistheid van het programma te beïnvloeden. Met andere woorden, als een functie of methode is ontworpen om te werken met een basistype, moet het ook werken met een afgeleid type zonder dat wijziging of het produceren van onverwachte bijwerkingen vereist. Barbara Liskov eerst verwoordde dit idee in haar 1987 keynote adres op de Conferentie over Object-georiënteerde Programmering Systemen, Talen en Toepassingen (OOPPLA), en het is sindsdien een hoeksteen van object-georiënteerd ontwerp geworden.

LSP is fundamenteel over gedrag subtyping. Het is niet genoeg dat een subklasse dezelfde methode handtekeningen als zijn ouder heeft (syntactische conformantie); de subklasse moet ook de intenties en beperkingen van de ouderklasse respecteren. Als een subklasse verandert het fundamentele gedrag van een ouder methode . . bijvoorbeeld, door het gooien van een uitzondering de ouder nooit gooit, het teruggeven van een waarde die de ouder contract schendt, of het vereisen van strengere voorwaarden . Dan is de vervanging niet veilig, en het ontwerp schendt LSP.

Formele definitie en achtergrond

Barbara Liskov... de oorspronkelijke formele definitie is als volgt:

Deze definitie benadrukt dat een subtype (S) moet worden vervangen door zijn supertype (T) in elk programma (P) dat wordt geschreven in termen van T. Het programma . Onwaarneembare gedrag moet worden bewaard. Dit concept is nauw gerelateerd aan de Design by Contract (DbC) methodologie, pioniers van Bertrand Meyer, waar elke methode expliciete voorwaarden heeft (wat moet waar zijn voor de methode loopt) en postvoorwaarden (wat moet waar zijn na). Onder LSP, subklassen kunnen alleen verzwakken voorwaarden en versterken postvoorwaarden; ze kunnen het tegenovergestelde niet doen zonder te breken .

Zie voor meer informatie het originele Liskov en vleugelpapier dat het concept formaliseerde. Daarnaast geeft het Wikipedia artikel over LSP een goed overzicht.

Waarom is LSP belangrijk?

Het aanhangen van LSP brengt verschillende kritische voordelen met zich mee voor objectgeoriënteerde systemen:

• Betrouwbaarheid en correctheid: Code die een basistype gebruikt kan erop vertrouwen dat elke subklasse zich zal gedragen volgens het basistype. Dit voorkomt subtiele bugs die optreden wanneer een subklasse onverwacht gedrag introduceert.
• Polymorfisme: Polymorfisme is het vermogen om objecten van verschillende klassen te behandelen via een gemeenschappelijke interface. Zonder LSP wordt polymorfisme gevaarlijk omdat vervanging van een subklasse onjuiste resultaten kan opleveren. LSP zorgt ervoor dat polymorfe code werkt zoals bedoeld.
• Behoud en duurzaamheid: Wanneer LSP-schendingen worden vermeden, is het toevoegen van nieuwe subklassen niet nodig bestaande code te wijzigen die afhankelijk is van het basistype. Dit sluit aan bij het Open/Closed Principle (OCP) . software-entiteiten moeten open zijn voor uitbreiding maar gesloten voor wijziging.
• Testabiliteit: Eenheidstests die tegen een basisklasse zijn geschreven, kunnen worden hergebruikt om subklassen te valideren. Als een subklasse LSP schendt, zullen deze tests mislukken, waardoor de inconsistentie vroeg wordt onthuld.

LSP is niet alleen een academisch concept; het heeft directe praktische implicaties. Bijvoorbeeld, in een betalingsverwerkingssysteem, als je een basis klasse met een methode hebt, verwacht je dat alle subklassen (bijv. , ) betalingen zonder fouten of bijwerkingen verwerken die de basisklasse niet verwacht. Schendingen kunnen hier leiden tot verlies van inkomsten of beschadigde gegevens.

Gemeenschappelijke inbreuken op het Substitutiebeginsel van Liskov

Herkennen LSP overtredingen is de eerste stap naar het bevestigen van hen. Hier zijn een aantal typische patronen die het principe breken:

Versterking van de voorwaarden

Als een basisklasse methode een integer parameter verwacht, zal het toevoegen van een voorwaarde in de subklasse dat het gehele getal positief moet zijn (terwijl de basisklasse een geheel getal accepteert) de voorwaarde versterken. Klanten die een negatief getal aan de basisklasse hebben doorgegeven, zouden nu falen met de subklasse. Voorbeeld:

// Base class
class UserService {
 public void assignRole(int userId) { ... }
}
// Subclass violation
class AdminService extends UserService {
 @Override
 public void assignRole(int userId) {
 if (userId <= 0) throw new IllegalArgumentException("Invalid ID");
 ...
 }
}

Verzwakke postvoorwaarden

Als de basisklasse een bepaalde rendementswaarde of neveneffect garandeert, dan is een subklasse die de garantie vermindert in strijd met LSP. Zo kan een basisklassemethode altijd een niet-null string teruggeven; een subklasse die teruggeeft, verzwakt in sommige gevallen de postconditie.

Nieuwe uitzonderingen gooien

Subklassen mogen geen uitzonderingen maken die de basisklasse niet gooit (tenzij die uitzonderingen subklassen van uitzonderingen zijn die reeds zijn toegestaan). Als klanten van de basisklasse alleen vangen , en een subklasse gooit een , zal de vervanging onverwachte crashs veroorzaken.

Verwijderen of overrijden van methoden die moeten worden geërfd

Als een subklasse een methode overschrijft om niets te doen (leeg lichaam) of een te gooien, dan is dat een duidelijke overtreding. De subklasse gedraagt zich niet zoals de basisklasse bedoeld.

Klassiek voorbeeld: Rechthoek, Vierkant, en de Area Trap

Het meest geciteerde voorbeeld van LSP overtreding gaat geometrische vormen. Veel leerboeken beginnen met een klasse die en methoden heeft, en dan een subklasse aanmaken die deze overschrijft om breedte == hoogte te handhaven. Hier is het probleem:

// Base class
class Rectangle {
 protected int width, height;
 public void setWidth(int w) { width = w; }
 public void setHeight(int h) { height = h; }
 public int getArea() { return width * height; }
}

// Subclass violation
class Square extends Rectangle {
 @Override
 public void setWidth(int w) {
 width = height = w;
 }
 @Override
 public void setHeight(int h) {
 width = height = h;
 }
}

Beschouw nu een functie die werkt met een :

void resize(Rectangle r) {
 r.setWidth(5);
 r.setHeight(10);
 assert r.getArea() == 50; // Expect 50
}

Wanneer een ] voorbij is, stelt de methode de breedte in op 5 en vervolgens de hoogte op 10 .De vierkanten staan overbelast zet ook de breedte op 10, zodat het vierkant eindigt met breedte=10, hoogte=10, oppervlakte=100. De bewering mislukt. De is niet substitueerbaar voor omdat het de postconditie verandert: na en , is een rechthoekoppervlak 50, maar een vierkantsoppervlak is 100.

De fix: Vermijd erven ] van . Ontwerp in plaats daarvan een abstracte klasse met een gemeenschappelijke ] methode, en laat beide [ en uitvoeren onafhankelijk. Gebruik ook compositie: een vierkant kan een rechthoek zijn met gelijke zijden, maar het blootleggen van sets die de invariant breken is het echte probleem. Het principe wordt vaak samengevat als Dont breken van het contract.

abstract class PaymentGateway {
 public abstract void charge(double amount);
 public void refund(double amount) { /* default implementation */ }
}