sciencetalk

Hallo,

Na jullie hulp in het vorige topic - waarvoor dank - , ben ik op een nieuw probleem gestoten. Ik vraag me af hoe ik volgend probleem netjes zou kunnen oplossen:

Ik heb een klasse A, een klasse B, en een klasse C die erft van B. In klasse A (een soort hoofdprogramma), maak ik een nieuw object C aan.

In klasse C zou ik een functie willen gebruiken van klasse A, die niet static is. Hoe los ik dit op?

A.functienaam() is geen optie, omdat de functie niet static is en ook niet kan gemaakt worden.

A mijnklasseA = new A() is ook geen optie, want dan kom ik uiteraard in een oneidige loop terecht, gezien die nieuwe A weer een C maakt en zo maar verder.

Nu had ik bedacht om in de klasse A, waar ik dat object C aanmaak, dat te doen door

C mijnklasseC = new C(this)

maar ik twijfel of dat is 'zoals het hoort'.

Alvast bedankt!

In physics I trust schreef:C mijnklasseC = new C(this)

maar ik twijfel of dat is 'zoals het hoort'.

Dat gaat, maar als je dit moet doen, dan heb je gewoon een architectuurfout gemaakt. Dit is trouwens dé alarmbel voor een architectuurfout.

Zie het zo: ofwel heeft Jan een knikker, ofwel heeft een knikker Jan. Maar ze kunnen NOOIT allebei het geval zijn.

Het geval waar je dit soms tegenkomt, is bij bijvoorbeeld een Duif met een Oog en Pootjes. Als het Oog brood ziet, dan moeten de Duif er naar toe lopen. Maar functies in Oog mogen enkel te maken hebben met Oog, dus moet de functie zien() zitten in de klasse van Duif. Die kan dan op zijn beurt oog.dichtsteDingDatErUitZietAlsBrood() aanroepen en pootjes.loopNaarDatDing(brood).

Circulaire constructies kunnen trouwens ook voor veel problemen zorgen, zoals bij serialization, threading, ... probeer ze daarom zo veel mogelijk te vermijden.

Dank je, dit soort bedenkingen was ik me ook aan het maken.

Wat ik in elkaar aan het boksen ben, is een tetris-spelletje, banaal, ik weet het, maar blijkbaar is het toch een goede oefening.

Die klasse A is dan mijn hoofdprogramma. Die erft zelf over van GameEngine, een soort 'bibliotheekklasse' die functies bevat zoals controleer of er op een bepaalde coördinaat reeds een blok aanwezig is.

De klasse B is de klasse Blok. Klasse C is dan een bepaald type Blok, bijvoorbeeld een L-vormige blok.

In de klasse C heb ik een boolean dropped die nagaat of de betreffende blok reeds zover is gezakt als hij kan. Om dat te bepalen, wordt gebruikt gemaakt van de functie die ik hierboven vernoemde: diegene die nagaat of er een blok aanwezig is op een bepaalde coördinaat. Heb ik het dan slecht ineen gestoken?

Of hoe kan ik op een nette manier aan die functie geraken?

Is het dan een goed idee om een object GameEngine aan te maken in C?

Ofwel geef je aan de functie dropped() de spelsituatie mee als input? Ofwel ga je er van uit dat er maar 1 wereld is (zo doe ik het meestal) en maak je de methode die de informatie over de wereld opvraagt static. Dat heeft als nadeel dat je maar moeilijk kunt veranderen naar meerdere werelden in parallel.

Nu, mij lijkt het dat de functie dropped() niet in de klasse van de blok thuishoort. Zoals eerder gezegd, als je voor een methode meer nodig hebt dan het object zelf of zijn fields, dan staat hij waarschijnlijk verkeerd.

Gezien de situatie door A wordt bepaald, zal ik die inderdaad moeten meegeven als input dan. En dropped() niet in Blok zetten lijkt mij dan vreemd: gezakt tot op de grond of niet, lijkt me toch een eigenschap van Blok?

Het is een eigenschap van een blok, maar het lijkt me niet aan blok om dit zelf te gaan bepalen.

Voor mij is een tetris blok een passief ding; hij houdt wel bij of hij 'dropped' is of niet, maar iemand anders moet hem dat vertellen. Hij moet dat zelf niet gaan uitzoeken, anders ga je het spelverloop verdelen over veschillende locaties in je code.

Oké, ik zie in wat jullie bedoelen.

Ik heb het wat zitten herbekijken en 317070's laatste suggestie opgevolgd.

En over het al dan niet thuishoren van dropped(): ik vind het niet onmogelijk om dat er wel te zetten: rotate() is ook een functie die ik in blok heb staan, net omdat die in se eigenschappen van blok zelf beïnvloedt.

Bedankt voor jullie tips in ieder geval.