OOP2

# Maarten Vangeneugden - 1438256

## GRASP

Om zoveel mogelijk tegemoet te komen aan de GRASP-richtlijnen, heb ik volgende

ontwerpkeuzes toegepast voor de verschillende richtlijnen.

### High cohesion & Low coupling

- Veel classes zijn totaal van elkaar losgekoppeld. Een goed voorbeeld hiervan

  is Bed; Bed weet niet over dat er Reservaties bestaan, zelfs niet in welke

  Room het 'staat'.

- Als er toch gekoppeld moet worden, dan blijft dit tot een minimum beperkt; Een

  Room weet wel welke Bedden het heeft, maar niet hoe deze gebruikt worden, een

  Reservation weet wel welke Bedden voor hem gereserveerd zijn, maar heeft geen

  weet van welke kamer dat deze staat.

- Uitzondering op deze regel vormen de Controller-classes; omwille van hun taken

  zijn deze vaak verplicht om van veel verschillende classes op de hoogte te

  zijn.

### Indirectie

- In plaats van functionaliteit toe te wijzen aan class X om met class Y te

  interageren, wordt er vaak gebruik gemaakt van een class Z, die deze

  verantwoordelijkheid op zich neemt.

- Dit wordt toegepast d.m.v. een MVC-structuur, waarin de \*Controller-classes

  als 'tussenpersoon' werken.

- Dit komt ook tegemoet aan de eigenschappen van Information Expertise.

### Creator

- Controllers staan ook in als zgn. Creators van de models die ze beheren. Ze

  voldoen dan ook aan de eigenschappen zoals

  [hier](https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Creator)

  opgesomd wordt.

# Veranderingen t.o.v. Challenge 1

- Verkrijgen van een vrije kamer is verplaatst van ReservationView naar

  RoomController.

- Toevoeging van veel documentatie, vooral in de vorm van Javadoc, maar ook

  _inline commenting_ waar nodig/gewenst.

- Toevoeging van een systeem om wandelingen te organiseren (1 testwandeling als

  voorbeeld incluis).

- Nieuw zoekvenster, speciaal gericht op het behandelen van wandelingen.

- Zoekvensters zijn nu haast volledig operationeel, en geven bruikbare

  antwoorden en data terug.

- Eerder gemaakte reservaties/wandelreservaties kunnen later aangepast en/of

  verwijderd worden.

- Prijsberekening op orde gesteld.

- Toevoeging van een automatische _room generator_ in Main, om snel en met

  willekeurige data het programma te testen.

- Toepassing van contractueel programmeren in vele methods; vaak wordt de method

  nog niet uitgevoerd als het contract niet 100% wordt nageleefd.

### Vereiste aanpassingen

De aanpassingen die ik heb moeten doorvoeren om wandelingen toe te voegen, zijn

grotendeels beperkt gebleven tot de plekken in de code die sowieso van meerdere

onderdelen van het programma op de hoogte zijn;

Zo is er niks veranderd aan Reservation of Room, maar WalkController en

ReservationController hebben elkaar nu wel als member.

Aan de GUI-kant was het slechts 1 knopje toevoegen in het hoofdmenu.

Ik heb het zo opgesteld dat een groepsnaam die overeenkomt met een

hostelreservering, wordt aanzien als een reservering van dezelfde persoon.

Als de namen niet overeen komen, dan zijn het verschillende groepen.

Deze conventie laat mij toe om het programma veel beter te laten voldoen aan

high cohesion/low coupling, zonder daarvoor veel voordelen voor hoeven in te

leveren.

Ik was origineel van plan om de zoekfunctionaliteit bij het bestaande

zoekvenster te plaatsen, maar ik vond dat dat nogal onduidelijk ging worden. Ik

heb dus voor wandelmanagement een apart zoekvenster gemaakt, te bereiken vanuit

het hoofdmenu.

Uiteindelijk ben ik blij van de beperkte aanpassingen in het eerste gedeelte van

de challenge. Ik heb slechts hier en daar een extra member moeten toevoegen, en

het geheel is nog steeds degelijk gesplitst.

# Algemene keuzes ter bevordering codekwaliteit

## Strings, integers, ... i.p.v. Enums/Eigen classes

In het programma zijn er sommige members die doen vermoeden dat ze beter als

Enums aangeduid kunnen worden; Het type van een kamer, faciliteiten, ...

In plaats van een speciale class hiervoor te maken, heb ik gekozen om deze

gewoon te behandelen als simpele Strings in lijsten.

Het voordeel aan deze werkwijze, is dat Strings in Java SE quasi universeel

voorkomen; data kunnen geconverteerd worden naar Strings (en vice versa), veel

gebruikte GUI-libraries (waaronder Swing, JavaFX, ...) gebruiken Strings voor

tekst voor te stellen in de GUI-widgets, ...

Daarnaast weet iedereen die ook maar een beetje geschoold is in Java, direct hoe

deze members behandeld kunnen worden. Had ik een class gemaakt die bv.

RoomFacilities heette, dan is die parate kennis over de taal zelf nutteloos.

Strings zijn ook voorzien van extreem veel methods, en zijn dus zeer flexibele

classes om te gebruiken. Het feit dat ze zo makkelijk doorheen het programma te

gebruiken zijn is dus een groot pluspunt.

Als dat nog niet genoeg is: Het gebruiken van de hulpmiddelen uit de _standard

library_ is niet enkel waarvoor libraries überhaupt bestaan, het beperkt ook

het benodigde aantal classes in de eigen software, waardoor het geheel

uiteindelijk veel overzichtelijker blijft, en bijgevolg, makkelijk uit te

breiden, te testen, te begrijpen, ...

Al deze voordelen graan grotendeels verloren als ik beslis om zelf

gespecialiseerde classes op te stellen.

Men kan misschien stellen dat "de voordelen die het schrijven van eigen

classes veel beter tegemoet komt aan de essentie van object-georiënteerd

programmeren, dan zich _beperken_ tot slechts een handvol generieke classes, die

misschien niet volledig aan de benodigdheden beantwoorden".

Toch laat ik mijn afweging overslaan in het voordeel van minder classes, en meer

uniformiteit. _Sometimes, less is more._ Meer classes betekent ook:

- Meer onderhoud

- Meer kans op bugs

- Groter programma

En al die problemen resulteren op lange termijn in:

- Slechtere uitbreidbaarheid

- Slechtere onderhoudbaarheid

- Slechtere schaalbaarheid

Zijn al die problemen de moeite van een (zogezegd) "beter object-georiënteerd

design" wel waard?

Veel mensen stellen juist dat OOP net voordelig is als men op zoek is naar

- Uitbreidbaarheid

- Onderhoudbaarheid

- Modulariteit

- Schaalbaarheid

Als de voordelen van het paradigma verdwijnen als ik dat "beter design" volg,

is dat design dan wel echt beter?

**Conclusie: Uniforme classes zijn volgens mij soms beter dan een stel

gespecialiseerde classes. Daarom dat ik mij soms behelp met Strings, intergers,

... i.p.v. zelf een oplossing te schrijven.**

### Null pointers

Het valt misschien op dat ik doorheen mijn programma in veel contracten eis dat

geen enkele parameter een zgn. *null pointer* is.

Het gebruik van null pointers staat garant voor een overvloed aan moeilijk te

vinden bugs die (door het design van object-georienteerd programmeren) enorm diep

kunnen doorpropageren.

Ik maak er een kerntaak van dat, als er aan mijn programma gewerkt wordt, de

programmeur zichzelf steeds kan garanderen dat **alle** data die hij

ontvangt, valide data is, tenzij dat expliciet anders wordt aangegeven.

Op deze manier valt er een hele last van de schouders van de programmeur; een

reeks fouten worden voorkomen, simpelweg door een strikt schema aan te houden.

Het controleren op null pointers wordt op 2 manieren gedaan:

- Gebruik van *methods* aanwezig in het gegeven type. Als de gegeven variabele

  een null pointer is, zal het programma direct crashen, en een

  NullPointerException geven.

- Expliciet testen of *var == null*. Wordt toegepast op parameters die direct

  als members opgeslagen dienen te worden.

Een uitzondering op het vermijden van null pointers vormen sommige methods die

slechts 1 object teruggeven. In deze gevallen kan het voorvallen dat het te

zoeken object niet gevonden wordt. Om de ontwikkelaar hiervan op de hoogte te

stellen, wordt dan soms een null teruggestuurd.

Dit wordt steeds expliciet vermeld.

Deze (contractuele) controle laat toe dat, mocht er een null pointer gebruikt

worden, het programma de programmeur hiervan direct op de hoogte stelt, en dit

op het laagst mogelijke niveau (namelijk de eerste method waar deze waarde

gebruikt wordt).

### Cloning

members 'private' maken (encapsuleren) is volledig nutteloos als men getters en

setters op deze members toepast; In Java worden references doorgegeven (m.u.v.

primitives), die de hele notie van encapsulatie voorbijgaan (bij sommige types).

Een voorbeeld hiervan is het privatiseren van een Set<T>-member: men kan daar

een 'getSet()'-method op plaatsen, en dan toch de inhoud van deze 'private'

aanpassen.

Ik heb geopteerd om, waar van toepassing, deze variabelen te 'clonen', om zo

exacte kopieën terug te geven.

Deze manier van werken brengt enkele voordelen teweeg:

- Zeer defensief programmeren; De ontwikkelaar kan geen members aanpassen als

  dat niet de bedoeling was

- Duidelijkheid code: getSet().clear() zal de member niet meer leegmaken. Om dat

  te doen, moet men gebruikmaken van de method die daarvoor bedoeld is:

  setSet(clearedSet)

### Inheritance

Overerving is een goed concept over het algemeen, maar **niet** in OOP.

De problemen omtrent impliciet gedrag en onnodige *state* zijn al te vaak

beschreven met OOP-inheritance.

Ik heb in mijn programma geen gebruik gemaakt van inheritance, exact omwille van

de problemen die het voortbrengt, zeker in termen van herbruikbaarheid en

robuustheid, wat toch zware vereisten waren voor deze opdracht.

Ik heb al mijn problemen makkelijk kunnen oplossen d.m.v. compositie.

### Benaming variabelen

Doorheen mijn programma maak ik heel veel gebruik van dezelfde benamingen.

Bijvoorbeeld: Een variabele van het type Reservation zal haast altijd

'reservation' heten, een Set van een bepaald type zal de naam van datzelfde type

dragen, in het meervoud, ...

Sommige programmeurs gebruiken liever afkortingen (bv. 'reservation' -->

'resv'), omdat dit sneller schrijft.

Naar mijn mening moet men bij deze werkwijze inleveren aan leesbaarheid, vooral

wanneer iemand die nog nooit met de code gewerkt heeft, dit programma moet

overnemen.

Daarnaast zorgt de consistentie van woordgebruik ervoor dat een andere

programmeur, doorheen het hele programma dezelfde context in zijn/haar gedachten

kan gebruiken.

Nu, ik maak hier soms een uitzondering op, omdat het soms zo lang wordt dat de

code in zijn geheel moeilijker leesbaar wordt.

Een voorbeeld van hoe dit uitmondt is Objective-C. Haast **alles** wordt voluit

genoteerd, waardoor van de eigenlijke essentie van het programma haast niks

overblijft.

De controllers heb ik daarom in sommige gevallen toch tot hun initialen

afgekort. Ik vond dat het verlies aan expressiviteit meer dan goed gemaakt werd

door het winnen aan leesbaarheid.

## Toepassing types/classes

Doorheen het programma heb ik getracht zoveel mogelijk gebruik te maken van

types/classes die

- Veelvoorkomend zijn in de Java STL (Zoals String, Set, List, ...)

- primitief zijn (ints, ...), omdat deze operatoren hebben en de code

  leesbaarder maken

Een goed voorbeeld hiervan zijn bv. de faciliteiten:

I.p.v. een aparte "Facility"-class te maken, heb ik de verschillende

faciliteiten voorgesteld door een simpele String. De voordelen van deze aanpak

zijn ook direct duidelijk:

- Betekenis is direct duidelijk; de faciliteit letterlijk in de code vernoemd

- Makkelijke interactie met GUI, die sowieso Strings vraagt voor bv. JLabel

- Uitbreidbaarheid wordt bekomen door simpelweg een nieuwe String te

  introduceren

## View en GUI

Werken met GUI's is vaak tijdrovend en veroorzaakt snel errors, zeker met bv.

anonieme methods, exceptions, ...

Alhoewel mijn programma grotendeels in een MVC-stijl is geschreven, maken de

view-classes (RegistrationView, SearchView, ...) achterliggend gebruik van een

zelfgemaakt framework om makkelijk vensters te maken.

Dit kleine framework is een persoonlijk hobbyproject dat ik JSugar noem.

Het biedt een heleboel voordelen, vergeleken met elk GUI-venster zelf opstellen:

- Vaak gebruikte GUI-widgets (zoals een label, textfield) worden aangemaakt en

  toegevoegd door slechts 1 method op te roepen

- JSugar maakt gebruik van reflectie om op een leesbare en uitbreidbare manier

  knoppen te activeren:

  public JButton createButton(String text, String action, String methodName, Object triggerObject)

  'methodName' is een simpele String, en 'triggerObject' is het object waar deze

  method moet worden opgeroepen.

- Automatische uitlijning van widgets middels de standaard FlowLayout

Voor meer informatie kunt u JSugar-readme.md raadplegen.

## java.util.Date

Doorheen het programma maak ik vaak gebruik van de Date-class uit de Java STL,

om de volgende redenen:

- Uitbreidbaarheid: Door overal eenzelfde type te gebruiken, is het gemakkelijk

  om nieuwe modules toe te voegen, zonder dat daarvoor abstractielagen etc.

  nodig zijn.

- Uniformiteit: Eenzelfde type uit de STL laat de ontwikkelaar toe om door het

  hele programma heen hetzelfde denkpatroon aan te houden; een

  Stringvoorstelling hier, een integer daar, ... veroorzaken problemen en bugs,

  die met deze class voorkomen worden.

De datavelden in de GUI komen altijd met de huidige datum op het veld genoteerd.

Geef data in in hetzelfde formaat, en de achtergrond doet de rest.

### Deprecation

Ik besef dat ik in java.util.Date veel gebruik maak van _deprecated methods_.

Nu, deze methods bieden mij wel de kans om snel en gemakkelijk met data om te

kunnen gaan.

Zeker het tijdsgebrek dat komt kijken bij de challenges zorgen ervoor dat ik

mijn niet de luxe kan veroorloven om een speciaal voor mij gemaakte dataclass te

maken.

### Ontbijtdata

Het moeilijkste om te implementeren waren de data voor ontbijt.

Er wordt voor de reservaties steeds een set bijgehouden van de data waarop

ontbijt besteld is.

Op zich is dit niet zo moeilijk. Het moeilijke hieraan, is de gebruiker van het

programma op een begrijpelijke manier deze data te laten invoeren.

Data worden ingevoerd via tekstvelden, omdat Swing geen zgn. "DatePicker" heeft.

Ontbijt wordt doorheen het programma geserveerd om 9 uur.

### GUI

Swing biedt geen widget die zich specialiseert in het weergeven van informatie

over een datum (een zgn. _calendar widget_).

In de opdracht stond dat we geen "visueel aantrekkelijke GUI" hoeven te

ontwerpen, maar wel een die "alle functionaliteit ondersteunt".

Wegens het tijdsgebrek en de tekortkoming van Swing, heb ik besloten om data

weer te geven in een simpel JTextField.

Het biedt de beste oplossing voor wat gevraagd wordt in deze opdracht, en wegens

de tijdslimiet tijdens de challenges zelf vormen ze een goede

"kortetermijnoplossing".

## Bedden

Ik heb voor bedden een aparte class aangemaakt, omdat deze een bepaalde state

bijhouden, nml. wanneer ze gereserveerd zijn.

## Reservation

Voor de reservaties heb ik besloten om enkel die data bij te houden die inherent

gerelateerd is aan die reservatie:

- Enkel gereserveerde bedden i.p.v. gereserveerde kamers. Qua uitbreidbaarheid

  heeft dit tot gevolg dat men gemakkelijk kan uitbreiden naar reservaties,

  gespreid over verschillende kamers.

## ReservationView / WalkView

Merk op hoe in ReservationView de data van de Reservation direct in de GUI wordt

geplaatst.

Dit staat toe om zeer gemakkelijk deze class te hergebruiken voor zowel het

**aanmaken** als het **updaten** van de reservatie.

Dezelfde werkwijze wordt toegepast ook WalkView.

## Opmerkingen

- Door het gebruik van de FlowLayout in de GUI, is het mogelijk dat sommige

  gedeelten van de GUI niet direct worden weergegeven, daar ze verborgen worden

  door de hoogte van het venster. Men kan deze tevoorschijn halen door zelf het

  venster in de hoogte te verstellen.