[OOP] modelleer-vraagstuk(je)

[Verwijderd]

Hallo,

Ik heb een opdracht voor school om een racespel te schrijven.
In eerste instantie dienen we alleen de engine te schrijven en is er dus geen sprake van enige grafische uitvoer.

Ik had zelf het volgende in gedachten:

Klassen:
auto, coureur, racebaan, monteurs, eigenaren, pitstop, weer, band, motor en race.

Wellicht dat er nog wat klassen bijkomen, maar de eerste aanzet is er in ieder geval

Je moet je voorstellen dat de eigenschappen van de banden e.d. direct invloed hebben op de uitslag van de wedstrijd. Dit kan wellicht deels overruled worden indien het bijvoorbeeld regent. Zo zijn er natuurlijk tig voorbeelden te verzinnen en het is dus de bedoeling dat we ons eigen algoritme verzinnen om te bepalen wie de race wint.

Ik beschouwalgoritme dus ook als een eigen klasse, waarin alle gegevens samen komen om uiteindelijk de uitslag te bepalen.

Mijn vraag is: Hoe richt ik dit fatsoenlijk in?

Pseudocode:

.... voorbereidend werk ....
auto1 = new Auto(stoereBandObject, minderStoereMotorObject, etc);
auto2 = new Auto(minderStoerBandObject, StoerMotorObject, etc);

baan = new Racebaan(aantalBochten, pitStopObject);

race = new Race();
race.addAuto(auto1);
race.addAuto(auto2);
race.addBaan(baan);

race.goVerstappen(); // hier gaat ie dus racen...

race.getUitslag();

Ik heb zelf het idee dat in de klasse Race, klasse Algoritme dient te komen.
Algoritme gebruikt echter gegevens uit praktisch alle andere klassen.

Ik kan niet helemaal overzien wat algoritme nu voor klasse dient te worden.

Wie wil er op schieten?

[Tux]

Ik heb niet zoveel verstand hiervan, maar is het niet een idee dat je voor elke coureur een getal hebt en voor elke positieve eigenschap een aantal punten erbij doet en voor een negatieve eigenschap (regen) een aantal punten wegdoet. De coureur met het hoogste getal is dan in die situatie het sterkst.

[Verwijderd]

Tux schreef op 12 October 2003 @ 12:42:
Ik heb niet zoveel verstand hiervan, maar is het niet een idee dat je voor elke coureur een getal hebt en voor elke positieve eigenschap een aantal punten erbij doet en voor een negatieve eigenschap (regen) een aantal punten wegdoet. De coureur met het hoogste getal is dan in die situatie het sterkst.

Uiteraard, uiteindelijk zal ik een soortement van puntensysteem schrijven wat uiteindelijk de uitslag bepaald, maar dat is niet het doel van mijn vraag. Algoritme dient gegevens te hebben van alle andere objecten om z'n uitslag te bepalen.
Ik kan niet helemaal overzien hoe dit opgelost dient te worden. Kan ik bv. een interface maken met static objecten (als dat al kan) om dan in klasse Algoritme een getPuntenAantal te doen. Misschien is dit wel een hele vieze oplossing, ik weet het niet, vandaar mijn vraag....

[Domokoen]

Ik zie niet in waarom je algoritmen als een 'eigen klasse' zou moeten beschouwen? Het idee is toch meestal dat algoritmes (methods) óp klassen werken?
Je bent hier zelf eigenlijk ook al achter want je merkt zelf al op dat Algoritme gegevens uit alle andere klassen gebruikt. Deze kan je dus veel beter splitsen in methods die operaties zijn op klassen.

Ik persoonlijk denk dat het handiger is om .goVerstappen() te doen als iets van
while(!everybodyfinished) {
auto1.rij()
auto2.rij()
enz.
}

Dus veel meer een simulatie.

[Verwijderd]

Mr.Chinchilla schreef op 12 October 2003 @ 12:52:
Ik zie niet in waarom je algoritmen als een 'eigen klasse' zou moeten beschouwen? Het idee is toch meestal dat algoritmes (methods) óp klassen werken?
Je bent hier zelf eigenlijk ook al achter want je merkt zelf al op dat Algoritme gegevens uit alle andere klassen gebruikt. Deze kan je dus veel beter splitsen in methods die operaties zijn op klassen.

Ik persoonlijk denk dat het handiger is om .goVerstappen() te doen als iets van
while(!everybodyfinished) {
auto1.rij()
auto2.rij()
enz.
}

Dus veel meer een simulatie.

Hmmm, ik denk dat je hier inderdaad wel gelijk in hebt, maar blijf ik dan niet met hetzelfde probleem zitten? auto1 of auto2 weet in principe niets van bijvoorbeeld het weer of de kwaliteit van het wegdek. Ik heb dus behoefte aan een gegevensvat die door het hele programma heen te gebruiken en te beinvloeden is. Mijn gevoel zegt me alleen dat dit neigt naar een dirty model en dat dit eigenlijk niet de bedoeling is, maar misschien zit ik er wel naast.

[gorgi_19]

Op een of andere manier krijg ik het vermoeden dat je op zoek bent naar het Observer Design Pattern.

Verder bestaat er van een hoop zaken maar 1 staat, bijvoorbeeld 1 weeromstandigheid, 1 baan. Dit moet te forceren zijn met een Singleton.

[ Voor 42% gewijzigd door gorgi_19 op 12-10-2003 13:03 ]

[Verwijderd]

gorgi_19 schreef op 12 October 2003 @ 13:00:
Op een of andere manier krijg ik het vermoeden dat je op zoek bent naar het Observer Design Pattern.

Verder bestaat er van een hoop zaken maar 1 staat, bijvoorbeeld 1 weeromstandigheid, 1 baan. Dit moet te forceren zijn met een Singleton.

Euh, ik heb even gezocht naar het Observer Design Pattern en ik heb het idee dat dit wellicht een passende oplossing zou kunnen zijn. Zoals ik het begrijp maak je een interface observer die het 1 en ander bijhoud. Ik kan me alleen nog niet zo heel erg goed voorstellen hoe ik dit in dit concrete voorbeeld verwerk.

Dienen alle klassen deze interface te implementeren?

[gorgi_19]

Verwijderd schreef op 12 October 2003 @ 13:21:
[...]


Euh, ik heb even gezocht naar het Observer Design Pattern en ik heb het idee dat dit wellicht een passende oplossing zou kunnen zijn. Zoals ik het begrijp maak je een interface observer die het 1 en ander bijhoud. Ik kan me alleen nog niet zo heel erg goed voorstellen hoe ik dit in dit concrete voorbeeld verwerk.

Dienen alle klassen deze interface te implementeren?

Nope, alleen de klassen die op de hoogte gehouden moeten worden. Een baan zal het een worst wezen dat de race gestart is. Ook de weerscondities niet.

Echter, een verandering van de weerscondities heeft wel invloed op alle auto's. Deze gaan dan volges een ander algoritme / patroon (wat evt. te bepalen is door middel van een Strategy Pattern) rijden.

[ Voor 14% gewijzigd door gorgi_19 op 12-10-2003 13:35 ]

[Verwijderd]

gorgi_19 schreef op 12 oktober 2003 @ 13:27:
[...]

Nope, alleen de klassen die op de hoogte gehouden moeten worden. Een baan zal het een worst wezen dat de race gestart is. Ook de weerscondities niet.

Echter, een verandering van de weerscondities heeft wel invloed op alle auto's. Deze gaan dan volges een ander algoritme / patroon (wat evt. te bepalen is door middel van een Strategy Pattern) rijden.

Ehhhh, misschien dat we het weer eerst maar even schrappen dan Het belangrijkste is dat we de opdracht ook nog afkrijgen binnen de daarvoor gestelde termijn...

[gorgi_19]

Verwijderd schreef op 12 October 2003 @ 13:51:
[...]


Ehhhh, misschien dat we het weer eerst maar even schrappen dan Het belangrijkste is dat we de opdracht ook nog afkrijgen binnen de daarvoor gestelde termijn...

Visual Basic .NET:

Public Class Car

    Private __weatherInfluence As IWeatherInfluence
    Private __maximumSpeed As Double

    Public Sub SetDryWeather()

        Me.__weatherInfluence = New DryWeatherInfluence

    End Sub

    Public Sub SetRainyWeather()

        Me.__weatherInfluence = New RainyWeatherInfluence

    End Sub

    Public ReadOnly Property MaximumSpeed() As Double
        Get
            Return Me.__maximumSpeed * Me.GetWeatherInfluence.MaximumSpeedPercent
        End Get
    End Property

    Private ReadOnly Property GetWeatherInfluence() As IWeatherInfluence
        Get
            If Me.__weatherInfluence Is Nothing Then

                Throw New Exception("Car::GetWeatherInfluence::WeatherInfluence not set")

            End If
            Return Me.__weatherInfluence
        End Get
    End Property

End Class

Ik denk dat je het moeilijker voorstelt dan het is.

[ Voor 4% gewijzigd door gorgi_19 op 12-10-2003 14:05 ]

[Verwijderd]

gorgi_19 schreef op 12 October 2003 @ 14:03:
[...]

Visual Basic .NET:

Public Class Car

    Private __weatherInfluence As IWeatherInfluence
    Private __maximumSpeed As Double

    Public Sub SetDryWeather()

        Me.__weatherInfluence = New DryWeatherInfluence

    End Sub

    Public Sub SetRainyWeather()

        Me.__weatherInfluence = New RainyWeatherInfluence

    End Sub

    Public ReadOnly Property MaximumSpeed() As Double
        Get
            Return Me.__maximumSpeed * Me.GetWeatherInfluence.MaximumSpeedPercent
        End Get
    End Property

    Private ReadOnly Property GetWeatherInfluence() As IWeatherInfluence
        Get
            If Me.__weatherInfluence Is Nothing Then

                Throw New Exception("Car::GetWeatherInfluence::WeatherInfluence not set")

            End If
            Return Me.__weatherInfluence
        End Get
    End Property

End Class

Ik denk dat je het moeilijker voorstelt dan het is.

Oh ongetwijfeld, maar op het moment dat ik allerlei designpatterns door moet worstelen en eerst de precieze werking dien te doorgronden en voor mij geldt dat het verhaal van de klok en de klepel helaas nog wel eens van toepassing is schuif ik dit soort dingen maar naar voren toe, want uit ervaring weet ik dat kennisverbreding niet beloond wordt en een werkende applicatie wel.

[gorgi_19]

Wat denk je dat het doel is van Design Patterns? Het leven van een programmeur moeilijker maken?

[Verwijderd]

gorgi_19 schreef op 12 October 2003 @ 14:30:
Wat denk je dat het doel is van Design Patterns? Het leven van een programmeur moeilijker maken?

he he he, nee, maar het vereist wel een stukje verdieping in de materie wat in eerste instantie tijd kost. Uiteindelijk levert dit een hoop tijdwinst op, maar ik heb op dit moment helaas geen tijd voor het verdiepen in de materie....

[Verwijderd]

Nu we toch bezig zijn over design patterns, iemand een site of een goed boek waar de belangrijkste design patterns uit de doeken gedaan worden? (ja ik weet er staat een mooi lijstje van boeken in de faq, maar daarmee weet ik nog niet welk boek zeker de moeite is!)

Op google vind ik niet veel ervan (meestal een kort voorbeeldje, en daar blijft het dan bij), en ik wil mij er al lang in verdiepen!

[ Voor 18% gewijzigd door Verwijderd op 12-10-2003 16:30 ]

[gorgi_19]

Verwijderd schreef op 12 oktober 2003 @ 16:18:
Nu we toch bezig zijn over design patterns, iemand een site of een goed boek waar de belangrijkste design patterns uit de doeken gedaan worden? (ja ik weet er staat een mooi lijstje van boeken in de faq, maar daarmee weet ik nog niet welk boek zeker de moeite is!)

Op google vind ik niet veel ervan (meestal een kort voorbeeldje, en daar blijft het dan bij), en ik wil mij er al lang in verdiepen!

Het GoF-boek..
Design Patterns: Elements of Reusuable Object Oriented Software, van Gamma et al.

[whoami]

Dit dus, ook in het Nederlands te verkrijgen trouwens.
Ik denk dat je dit boek zowat de 'standaard' mag noemen op gebied van design patterns. Code voorbeelden in C++ en Smalltalk en OMT diagrammen.

[madwizard]

Hier staat nog wel een goede:
http://www.patterndepot.com/put/8/JavaPatterns.htm

[Verwijderd]

Thanks whoami, heb het boek gelijk besteld (60 euro bij www.hcw.be)

Thanks madwizard, ben momenteel van pagina 10 tot 25 aan het printen (eerste pattern)

[farlane]

Mr.Chinchilla schreef op 12 October 2003 @ 12:52:
Ik zie niet in waarom je algoritmen als een 'eigen klasse' zou moeten beschouwen? Het idee is toch meestal dat algoritmes (methods) óp klassen werken?

Het is op zich goed mogelijk om een object te hebben die in het probleemdomein eigenlijk nix voorstelt, maar in je design wel.

Bij een race zou je kunnen denken aan een object dat de invloed van het weer op de race voorstelt. ( WeatherAlgorithm ?)

Het bijeenrapen van objecten adhv functionaliteit is een van de vereisten om een goed OO ontwerp te krijgen.

Stel je maar eens voor dat je de invloed van dat weer in bijvoorbeeld het RaceCar object stopt( omdat die iig toegang heeft tot alle elementen van die auto )

Welke andere 'algorithmes' zou je er dan nog meer in stoppen? Zo ongeveer elk ander object dat invloed heeft op de auto zou je dan in het auto object kunnen stoppen. Dat resulteert in een object dat veel te veel verantwoordelijkheden heeft. Maw, er is weinig 'cohesie' meer.