2. Objectegoriënteerd werken en de SOLID-principes

Question 1

Wat zijn de SOLID-principes?

Answer 1

De SOLID-principes zijn een poging om een aantal basisprincipes voor goed objectgeoriënteerd ontwerp samen te brengen in een letterwoord dat in het geheugen blijft hangen.

Question 2

Wat zijn de kenmerken van een object?

Answer 2

Een object heeft een:
+ identiteit (uniek).
+ toestand (attributen).
+ gedrag (methodes).

Question 3

Wat is het doel van object-georiënteerd programmeren?

Answer 3

Object-oriëntering is ontstaan uit een nood aan onderhoudsvriendelijker en gemakkelijker te hergebruiken software.

Question 4

Wat zijn de basisideeën van object-georiënteerd programmeren?

Answer 4

+ modulariteit
+ encapsulering
+ overerving
+ polymorfisme

Question 5

Wat is modulariteit?

Answer 5

Ieder object is als het ware een bouwsteen. Een stuk software wordt opgebouwd uit die bouwstenen.

Question 6

Wat zijn de voordelen van modulariteit?

Answer 6

Goed passende bouwstenen geven een stuk software een overzichtelijke structuur.
Goede bouwstenen zijn uitwisselbaar.
Die twee zaken maken software gemakkelijker te begrijpen en te onderhouden.

Question 7

Wat is encapsulering?

Answer 7

Een goed object heeft een zichtbaar en verborgen deel.

Question 8

Hoe wordt het zichtbare deel van een object genoemd?

Answer 8

interface

Question 9

Wat is overerving?

Answer 9

Het is mogelijk een object af te leiden van een ander object.
Dat wil zeggen dat het afgeleide object de functionaliteit van het andere object overneemt, uitbreidt, of specialiseert.

Question 10

Wat is polymorfisme?

Answer 10

Objecten met en gelijkaardige interface kunnen elkaars plaats innemen.
Hierdoor hoeft een object dat een functionaliteit nodig heeft van een ander object niet te weten welk concreet object dat is, zolang de functionaliteit er maar is.

Question 11

Wat is het voordeel van polymorfisme?

Answer 11

Als programmeur moeten we niet vooraf zeggen welke concrete objecten welke taken zullen uitvoeren (early binding). We kunnen die keuze uitstellen tot het allerlaatste moment, namelijk de uitvoering van het programma (late binding).

Question 12

Waarvoor staat het SOLID?

Answer 12

SOLID staat voor vijf principes:
\+ Single purpose
\+ Open/Closed
\+ Liskov substitution
\+ Interface segregation
\+ Dependency inversion

Question 13

Wat is het single purpose principle?

Answer 13

Elke klasse heeft 1 duidelijke verantwoordelijkheid.

Question 14

Wat is het voordeel van het single purpose principle?

Answer 14

Als dit principe gevolgd wordt is het gemakkelijker om te begrijpen waar een klasse voor dient dan als een klasse die veel vage verantwoordelijkheden heeft.

Question 15

Wat zijn aanwezingen dat een klasse het Single Purpose Principle volgt?

Answer 15

+ De klasse heeft een beperkte omvang.
+ De naam van de klasse maakt het doel duidelijk.
+ De klassen zijn gemakkelijk te ordenen in groepen.

Question 16

Wat zijn aanwijzingen dat een klasse het Single Purpose Principle niet volgt?

Answer 16

De klasse is:
+ erg groot.
+ zonder documentatie onbegrijpbaar.
+ maar voor 1 specifieke toepassing bruikbaar.

Question 17

Wat is het Open/Closed-principe?

Answer 17

Een goede klasse is zowel ‘open for extension’ en ‘closed for modification. Ze kan uitgebreid worden, maar haar gedrag kan niet gewijzigd worden.

Question 18

Waarom mag een klasse niet wijzigbaar zijn?

Answer 18

Een klasse wordt dikwijls op verschillende plaatsen gebruikt.
Het zou kunnen dat als je een klasse wijzigt op een plaats, dat die wijziging er voor zorgt dat de klasse niet meer goed werkt op de andere plaatsen.

Question 19

Hoe wordt het ‘Open/Closed-principe’ toegepast?

Answer 19

+ Functionaliteit wordt toegevoegd met nieuwe klassen, niet door het veranderen van bestaande klassen.
+ Er wordt overerving gebruikt.
+ Er worden interfaces gebruikt.

Question 20

Wat is het ‘Liskov substitutieprincipe’?

Answer 20

Een object moet altijd kunnen vervangen worden door een meer gespecialiseerd object, zonder dat het invloed heeft op de bestaande gebruikers van het object.
Als klasse A afgeleid afgeleid is van klasse B, dan kun je objecten van A overal gebruiken waar objecten van B bruikbaar zijn.

Question 21

Geef een voorbeeld van een geschonden ‘Liskov substitieprincipe’?

Answer 21

In Java heeft klasse String een methode length(). Het ‘contract’ van klasse String met zijn gebruikers is dat lenght() het aantal tekens in de string geeft. Je maakt nu een klasse MyString, afgeleid van String, met een override van length() die altijd -1 teruggeeft. MyString houdt zich dus niet aan het ‘contract’ van String, ook al kun je in principe in een programma een MyString gebruiken overal waar er een String staat.

Question 22

Wat is het ‘interface segregation’ principe?

Answer 22

Een object mag niet afhankelijk zijn van methodes die het niet gebruikt.
Anders geformuleerd: een object mag enkel de methodes hebben die het echt nodig heeft.

Question 23

Wat zijn de gevolgen als je het ‘interface seggregation’ principe niet volgt?

Answer 23

Dan krijg je objecten met erg veel methodes. Die moeten allemaal correct werken, ook al gebruik je ze niet, want het zou kunnen dat jij of iemand anders die ooit toch eens zult gebruiken. Dergelijke objecten zijn dus lastiger te onderhouden dan objecten die het principe wel volgen.

Question 24

Wat is het ‘dependency inversion’ principe?

Answer 24

High-level modules mogen niet afhankelijk zijn van low-level modules, maar moeten afhankelijk zijn van abstracties.
Abstracties mogen niet van details afhankelijk zijn. Details moeten afhankelijk zijn van abstracties.

Question 25

Waarom is het ‘dependency inversion’ principe belangrijk?

Answer 25

Als de high-level modules afhankelijk zijn van low-level modules dan wil dat zeggen dat je die low-level modules niet zomaar kunt veranderen. Dat maakt de software moeilijker te onderhouden, want een verandering in een low-level module (een detail) kan dan de werking van de high-level modules verstoren.

Question 26

Met welk principe is het ‘dependency inversion’ principe verwant?

Answer 26

Het principe van lage koppeling; een high-level module die van low-level modules afhankelijk is heeft een hoge koppeling.