OOP2

import java.util.HashSet;

import java.util.Random;

/**

 * The program starts here.

 * @author Maarten Vangeneugden - 1438256

 */

public class Main {

	public static void main(String[] args) {

		// Starting controllers and linking them together

		RoomController roc = new RoomController();

		ReservationController rc = new ReservationController(roc);

		WalkController wc = new WalkController(rc);

		addTestRooms(roc);

		addTestWalks(wc);

		MainWindow mainWindow = new MainWindow(rc, roc);

	/**

	 * Generates a series of Rooms to test the program.

	 * This method is mostly for debugging purposes.

	 * It features a set of constants in the front of the method, which you can

	 * edit to your heart's content. =)

	 * @param roc The Room Controller to which the Rooms will be added.

	 * @pre roc mustn't be null.

	 * @throws NullPointerException if roc is a null pointer.

	 */

	public static void addTestRooms(RoomController roc) {

		// Constants; edit to suit your needs

		final int ROOM_COUNT = 10; // Amount of Rooms that will be generated

		final int MAX_BEDS = 20; // The maximum amount of Beds in 1 Room

		final String[] POSSIBLE_FACILITIES = {"Shower", "Curtains", "Airco", "Bath", "Minibar"};

		final String[] POSSIBLE_TYPES = {"Male", "Female", "Mixed"};

		Set<Room> testRooms = new HashSet<>();

		for(int i=0; i<ROOM_COUNT; i++) {

			Random random = new Random();

			int beds = random.nextInt(MAX_BEDS) + 1; // +1, because it's in range [0, MAX_BEDS[

			String type = POSSIBLE_TYPES[random.nextInt(POSSIBLE_TYPES.length)];

			Set<String> facilities = new HashSet<>();

			for(String possibleFacility: POSSIBLE_FACILITIES) {

				if(random.nextBoolean()) {

					facilities.add(possibleFacility);

				}

			}

			testRooms.add(new Room(beds, type, facilities));

			// For debugging purposes, a human readable layout of the Rooms is

			// printed:

			System.out.println("ROOM");

			System.out.println("Beds: "+ beds);

			System.out.println("Type: "+ type);

			System.out.print("Facilities: ");

			for(String facility : facilities) {

				System.out.print(facility +", ");

			}

			System.out.println();

			System.out.println("-------------------------------");

		}

		roc.setRooms(testRooms);

	}

	public static void addTestWalks(WalkController wc) {

	}

}

 * Main window for the hostel program.

 * This class creates some sort of "main menu screen". It displays a concise set

 * of buttons, that allow the user to reach all parts of the program's GUI.

 * To be called as soon as the program is started (Essentially from the Main

 * class).

 * @author Maarten Vangeneugden - 1438256

 */

public class MainWindow {

	private ReservationController reservationController;

	private RoomController roomController;

	public MainWindow(ReservationController reservationController, RoomController roomController) {

		this.roomController = roomController;

		Window window = new Window("Main menu");

		window.createButton("New reservation", "", "addReservation", this);

		window.createButton("Search screen", "", "openSearchView", this);

	}

	public void openSearchView() {

		SearchView sv = new SearchView(this.reservationController, this.roomController);

	}

	public void addReservation() {

		Reservation reservation = new Reservation();

		ReservationView rv = new ReservationView(reservation, this.reservationController, this.roomController);

	}

}

import java.util.ArrayList;

import java.util.Date;

/**

 * Class for creating a screen that allows querying actions.

 * This program offers the ability to search in the program for Reservations,

 * Room status, etc.

 * This class creates a GUI for user interaction.

 * When matches are found, it will display them. In case of a unique match, that

 * match is immediately displayed.

 * @see ReservationView

 * @author Maarten Vangeneugden - 1438256

 */

public class SearchView {

	private ReservationController rc;

	private RoomController roc;

	private Window window;

	private JTextField groupNameField;

	private JTextField reservationIDField;

	private JTextField bedDateField;

	private JTextField breakfastDayField;

	public SearchView(ReservationController rc, RoomController roc) {

		this.rc = rc;

		this.roc = roc;

		this.window = new Window("Search screen");

		this.addFields();

	}

	private void addFields() {

		// TODO: Add fields to private members!

		this.groupNameField = this.window.createTextField("Search by group name");

		this.reservationIDField = this.window.createTextField("Search by reservation ID");

		this.window.createButton("Search reservation", "", "queryReservations", this);

		this.window.createLabel("Search reserved beds on given day:");

		this.bedDateField = this.window.createTextField(new Date().toGMTString());

		this.window.createButton("Get reserved beds", "", "queryBeds", this);

		this.window.createLabel("Find amount of breakfasts:");

		this.breakfastDayField = this.window.createTextField(new Date().toGMTString());

		this.window.createButton("Get breakfasts on given day", "", "queryBreakfasts", this);

	}

	public void queryReservations() {

		ArrayList<Reservation> foundReservations = new ArrayList<>();

		String nameQuery = this.groupNameField.getText();

		String IDQuery = this.reservationIDField.getText();

		for(Reservation activeReservation : this.rc.getReservations()) {

			if(activeReservation.getGroupName().contains(nameQuery) &&

				String.valueOf(activeReservation.getReservationID()).contains(IDQuery)) {

				foundReservations.add(activeReservation);

				}

		}

		// After collecting all results, offer the user the choice about which

		// one to take:

		String[] reservationNames = new String[foundReservations.size()];

		for(int i=0; i<foundReservations.size(); i++) {

			String text = foundReservations.get(i).getGroupName() +" ("+

				String.valueOf(foundReservations.get(i).getReservationID()) +")";

			reservationNames[i] = text;

		}

		int choice = this.window.choiceDialog("Multiple results were found. Specify which one you want to view:", reservationNames);

		if(choice == -1) { // No result found

			this.window.messageDialog("No reservations matched the given details.");

		}

		else {

			new ReservationView(foundReservations.get(choice), this.rc, this.roc);

		}

	}

	/**

	 * Search and display the reservation of Beds in Rooms.

	 * This method takes the given begin and end dates from the GUI, and lists

	 * for each Room, how many Beds are reserved, and by whom.

	 */

	public void queryBeds() {

		// The amount of reserved Beds is determined by the Reservations.

		// If a Reservation (partially) overlaps with the given time, then this

		// Bed is reserved in the given period.

		final Date date = new Date(this.bedDateField.getText());

		// endDate is required as it has to be strictly later than date.

		final Date endDate = new Date(date.getTime() + 1);

		String result = "";

		for(Room room: this.roc.getRooms()) {

			// XXX: The Java Object class provides a "hashcode()" method, to

			// retrieve an object's hashcode. I'm using that to identify the

			// different rooms.

			int usedBeds = room.getBeds().size() - room.getEmptyBeds(date, endDate).size();

			result = result + "Room "+ String.valueOf(room.hashCode()) +": "+ String.valueOf(usedBeds) +" reserved beds.\n";

		}

		this.window.messageDialog(result);

		/*for(Reservation reservation: this.rc.getReservations()) {

			if(!

				(reservation.getBeginDate().before(beginDate) && reservation.getEndDate().before(beginDate)) ||

				(reservation.getBeginDate().after(endDate) && reservation.getEndDate().after(endDate)))

			{ // This block is only reached if the valid options didn't match.

				String name = reservation.getGroupName();

				String beds = String.valueOf(reservation.getReservedBeds().size());

				String begin = reservation.getBeginDate().toGMTString();

				String end = reservation.getEndDate().toGMTString();

				result = result +

					name +" reserved "+ beds +" between "+ begin +" and "+ end +".\n";

			}

		}*/

	}

	/**

	 * Queries and displays breakfast reservations.

	 * After the user has entered a day in the corresponding field, this method

	 * can be called to search for breakfast reservations on that day.

	 * Breakfasts are ordered by Reservation, accompagnied by the amount of

	 * people in that Reservation.

	 * // TODO finish this javadoc

	 */

	public void queryBreakfasts() {

		Date date = new Date(this.breakfastDayField.getText());

		// Breakfast is only served at 9 o'clock, so set that time for easy

		// reference during querying:

		date.setHours(8);

		date.setMinutes(0);

		date.setSeconds(0);

		String response = "";

		for(Reservation reservation: this.rc.getReservations()) {

			if(reservation.getBreakfastDays().contains(date)) {

				String name = reservation.getGroupName();

				String amount = String.valueOf(reservation.getPeople());

				response = response +

					"Reservation "+ name +" ordered breakfast for "+ amount +" people.\n";

			}

			// else block is DEBUG CODE

		if(!response.isEmpty()) {

			this.window.messageDialog(response);

		}

		else {

			this.window.messageDialog("There are no breakfasts ordered for this day.");

		}

	}

}

## 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.

## SOLID

  RoomController

  _inline commenting_ waar nodig/gewenst.

### 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.

## 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 objectgeörienteerd programmeren) enorm diep

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.

------------------------------------------------------------ TODO

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

## 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.

### 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.

### 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.