1 |
- Pas contractueel programmeren toe |
2 |
- Gebruik encapsulatie |
3 |
- Motiveer ontwerpkeuzes (o.a. GRASP, SOLID, ...) |
4 |
- Maak gebruik van ervaring opgedaan bij de oefeningen |
5 |
- Prioriteiten stellen |
6 |
- Algemeen ontwerp en klassendiagram moet gemaakt worden |
7 |
- Duidelijk maken van hoe het moet worden geimplementeerd >> implementeren |
8 |
|
9 |
===OPDRACHT=== |
10 |
Studietrajectplanner |
11 |
|
12 |
- Opleiding, opleidingsonderdelen en studenten beheren |
13 |
- Abstractielaag (bv. interface): Enkel doen als er ook een degelijke reden voor is (In deze opdracht was dit niet echt nodig (bv. AbstractOpleiding)) |
14 |
- Postcondities zijn niet vereist als dit triviaal is (Bv. "@post De class is geconstrueerd" bij de constructor); Afweging maken tussen trivialiteit en absoluut vereiste pre/postcondities |
15 |
- Inheritance is prut als het niet moet: |
16 |
- OO_Besturingssystemen extends Opleidingsonderdeel; DIT IS GEEN SPECIALISATIE, dit is "een opleidingsonderdeel", niet "een opleidingsonderdeel dat een gespecialiseerde versie van een gewoon opleidingsonderdeel is." |
17 |
|
18 |
- Studietraject samenstellen: Manueel + automatisch aanvullen |
19 |
- Minderheid heeft dit geimplementeerd. |
20 |
- Een gegeven werkwijze is om een klassediagram te schetsen en de verantwoordelijkheden te bepalen ALVORENS te beginnen met programmeren. |
21 |
|
22 |
- Sorteeralgoritme: Samengestelde studietraject tonen en mogelijkheid om opleidingsonderdelen in dit traject alfabetisch of chronologisch weer te geven. |
23 |
- Ook weinigen die dit hebben geimplementeerd. |
24 |
- Geen gebruik maken van ingebouwde sorteeralgoritmen. |
25 |
|
26 |
- GUI voor deze functionaliteit |
27 |
- Toepassing van MVC-architectuur |
28 |
- Dit is geen structuurbeschrijving van het volledige programma |
29 |
- Geen programmalogica in GUI-gedeelte! |
30 |
|
31 |
- Pas contractueel programmeren toe |
32 |
- Zelfs bij vrij eenvoudige en triviale code toepassen |
33 |
- Voor elke method toepassen |
34 |
- Dus ook voor getters en setters |
35 |
- Echt waar |
36 |
- Alle methods |
37 |
|
38 |
- Correct gedrag, uitbreidbaarheid en robuustheid vereist |
39 |
- Het verbergen van achterliggende implementatie komt encapsulatie ten goede. |
40 |
- Creeer gepaste exceptions; Door het zelf maken van exceptions is het mogelijk om een fout duidelijk aan te geven. |
41 |
- Het extenden van Exception en overriden van getMessage() is al voldoende. |
42 |
|
43 |
- Motivatie van de ontwerpkeuzes |
44 |
- De motivatie moet niet enkel de beschrijving van de classes te maken; Class description hoort in een commentaarblok in de code. |
45 |
- Het 'waarom' uitleggen |
46 |
- Schrijf het verslag tijdens het programmeren |
47 |
- Geef ontwerpkeuzes v. SOLID en GRASP aan en geef voorbeelden die dit duidelijk maken. |
48 |
Deze opdracht ging vooral om een afweging van keuzes te oefenen. (Niemand heeft het volledig afgekregen). |
49 |
De beste manier voor deze opdrachten is om eerst te duiden op wat waar moet komen (Beschrijving van implementatie), alvorens de eigenlijke implementatie te maken. |