Wat is het Liskov-substitutieprincipe en hoe wordt het toegepast in programmeren?

Het substitieprincipe van Barbara Liskov (LSP) stelt dat in een programma, objecten van afgeleide klassen objecten van de basisklassen moeten kunnen vervangen zonder de correctheid van het programma te beïnvloeden.

Toepassing in Android-ontwikkeling:

1. Klassehiërarchieën: Bij het ontwerpen van klassehiërarchieën (bijvoorbeeld die erven van View, Fragment, Activity) garandeert LSP dat het gebruik van een instantie van een subklasse in plaats van de superklasse niet zal leiden tot onverwacht gedrag.

2. Interfaces: Als een klasse een interface implementeert, moet deze zodanig ontworpen zijn dat deze overal gebruikt kan worden waar een interface-type wordt verwacht, zonder de verwachtingen van de gebruiker te schenden.

   // Onjuist (schendt LSP)
   // De Printer-interface verwacht dat print() altijd iets print
   interface Printer {
       fun print(document: String)
   }
   
   class BasicPrinter : Printer {
       override fun print(document: String) {
           println("Afdrukken: $document")
       }
   }
   
   class BrokenPrinter : Printer {
       override fun print(document: String) {
           // Soms print het niets, schendt het contract van de interface
           if (Math.random() > 0.5) {
               // Niets doen
           } else {
               println("Afdrukken: $document")
           }
       }
   }
   
   // Correct (voldoet aan LSP)
   class SimplePrinter : Printer {
       override fun print(document: String) {
           println("Afdrukken: $document")
       }
   }
   
   class MockPrinter : Printer {
       override fun print(document: String) {
           // Voert altijd de actie uit, volgens het contract (ook al imiteert het printen)
           println("Mock printen: $document")
           // Kan loggen of andere verwachte acties uitvoeren
       }
   }
   

3. Testen: Het naleven van LSP vereenvoudigt testen, omdat mocks of stubs (die subtypen zijn) gebruikt kunnen worden in plaats van echte implementaties zonder de testlogica te wijzigen.

4. Contracten: LSP benadrukt het belang van het naleven van methodencontracten — alle verwachte voorwaarden vóór de aanroep (precondities), na de aanroep (postcondities) en invarianten (toestand van het object). Subklassen mogen de precondities niet verzwakken of de postcondities van de basisklasse versterken.

   Voorwaarde	Basisklasse (Supertype)	Subklasse (Subtype)
   Preconditie	Kan verzwakt worden	Moet hetzelfde of verzwakt zijn
   Postconditie	Kan versterkt worden	Moet hetzelfde of versterkt zijn
   Invariant	Moet worden nageleefd	Moet hetzelfde of strenger worden nageleefd
   Uitzonderingen	Kan X werpen	Kan X of een subtype van X werpen