Clean Code - The Liskov Substitution Principle

Het LSP heeft te maken met sub classes. Om het Liskov Substitution Principle correct toe te passen moeten alle sub classes vervangen kunnen worden door hun base class zonder dat de aanroepende code hier iets van merkt of aanpassingen hier voor hoeft te doen.

Een bekend voorbeeld dat vaak als voorbeeld wordt gebruikt om dit principe toe te lichten gaat over een rechthoek en een vierkant. De rechthoek is de base class en de vierkant de sub class. Omdat de vierkant de base class is, betekent dit dat hij o.a. de methodes SetWidth en SetHeight heeft overgenemen. Maar dit is overbodig voor een vierkant. Voor een vierkant hoeft alleen maar de size te worden opgegeven omdat natuurlijk alle kanten gelijk zijn. De oplossing voor dit stuk is om vierkant niet te laten erven van rechthoek. Het worden dus beide aparte classes, zodat geen trucks hoeven te worden uitgehaald om alles logisch te maken en werkend te krijgen. Hiermee voorkom je dus ook ruis in de code.

 Met de volgende checks kun je kijken of dat dit princie niet geschaad wordt.
- Als de base class iets doet, dan moet de sub class het ook doen. De sub class moet het dusdanig doen dat het niet de verwachtingen schendt van de caller. Een sub type doet meer dan de base type. Het kan nooit minder doen. Anders is het niet vervangbaar en schendt daarom het LSP;
- Als een sub class een methode erft die hij zelf niet gebruikt. De methode kent dan vaak een lege implementatie of gooit een exception.
- De sub class erft een methode en geeft er een andere betekenis aan.

De laatste twee punten zijn voorbeelden van een design smell die Refused Bequest heet.

Reacties

Populaire posts van deze blog

[SQL Server] varchar vs nvarchar

MS Sql 70-461: Chapter 5

[C#] Class serialiseren en deserialiseren