Zoals gezegd zie je als je het scenario opent al direct de kamer met de Roomba en het thuisstation. Ook de muren hebben al een plaats op het scherm.
Hoe komt dit en wat kun je er zelf mee.
In simpele vorm heeft Greenfoot 2 soorten klassen, kijk in het klassendiagram of je dit ziet!
Subklassen (ook wel kinderen genoemd) van klasse World, in dit geval is dat Room.
Subklassen van klasse Actor, in dit geval Info, Kamer, Roomba, Thuis, Vuil en ook de Subklassen daarvan.
De Greenfoot omgeving is zo ontwikkeld dat er aan het begin altijd een instantie van de subklasse van World wordt gemaakt.
In java taal: de constructor van Room wordt aangeroepen, de constructor is de methode met dezelfde naam als de klasse.
Open de broncode van Room en zoek de costructor op, deze heet dus Room().
De methode aanroep super(1280, 768, 1,true); is een bijzondere.
Omdat deze in klasse Room staat (een subklasse van World) betekent dit dat de constructor van de superklasse (de ouder) wordt aangereoepen.
In dit geval kun je hiervoor ook lezen World(1280, 768, 1, true), zoek deze constructor op in de greenfoot API en vul in wat de waarden betekenen.
Zoals je zag waren er nog twee methoden die niet in de API stonden.
maakMuren() en plaatsRoomba()
Aan de Nederlandse naam die specifiek voor dit scenario is (Roomba) kon je ook al afleiden dat dit geen standaard methode van Greenfoot of van Java is.
Als je kijkt in de broncode van klasse Room zie je dat de beide methodes daar netjes in staan.
Alle code die in maakMuren() staat hadden we ook in de constructor kunnen plakken maar door dit in een aparte methode te zetten wordt de broncode overzichtelijker.
Bovendien kun je eenvoudig de methode maakMuren() aanpassen zonder met de overige code rekening te hoeven houden.
Je ziet hier het toepassen van twee belangrijke programmeerprincipes:
- Geef een methode één verantwoordelijkheid.
- Zorg dat je code overzichtelijk en begrijpelijk is.