Model obiektowy - mecz

Witam,
Witam,
Zaprojektujemy klasę do przeprowadzenia meczu piłkarskiego. (diagram klas).

Ale najpierw muszę przedstawić założenia.
Każda drużyna ma trenera, 25 pilkarzy (maxymalnie). Każdy piłkarz jest albo bramkarzem, obrońcą, pomocnikiem, napastnikiem (jedno z czterech).

Mamy rozegrać mecz, w sensie takim:
Trener musi ustalić strategię oraz sklad:
Są 3 możliwe strategie:
ofensywna (1-3-4-3) (bramkarz - obrońca - pomocnik - napastnik)
defensywna(1-4-5-1)
pośrednia (1-4-4-2)

I teraz każdy trener ma swoją ulubioną strategię (jakąś).
Są trzy możliwości wyboru strategii :

1. wybiera swoją ulubioną mimo wszystko
2. wybiera taką samą jak na poprzednim meczu jeśli poprzedni wynik był zwycięski (jeśli nie, to wybiera dowolnie losowo spośród tych czterech które mamy).
3. Jeśli mecz na wyjeździe losujemy pomiędzy defensywną a ulubioną, a jeśli u siebie pomiędzy ofensywną a pośrednią.
   Następnie wybór składu odbywa się zupełnie losowo - ale zachowując strategię - a jak się nie da to mecz oddajemy walkowerem. (wybór składu polega na wyborze 11 osób).

Chciałbym to wszystko zrobić za pomocą klas + polimorfizm + klasy abstrakcyjne.
Już teraz proszę o wskazówki, a potem napiszę swoją ideę.

Najpierw napisz swoją ideę a potem pomyślimy nad wskazówkami ;)

Ok, więc tak:
Będą klasy :
Trener (A), Drużyna, Piłkarz (A), Strategia(A)
Literą A oznaczam abstrakcyjne.

Klasy które dziedziczą po abstrakyjnych:
Po Trenerze :
Konsekwentny (stosuje zawsze ulubioną), warunkowy (zależy gdzie gramy mecz), wynikowy (jaki był poprzedni wynik?)
Po Piłkarzu:
Bramkarz, Obrońca, Pomocnik, Napastnik.
Po Strategii:
Defensywna, Ofensywna, Pośrednia.

Potem pojawi się klasa mecz, ale najpierw musimy okiełznać to. Na tym etapie stop - Co sądzisz?

Póki co wygląda ok.

Jeszcze w jakiś sposób będę musiał wiedzieć czy będę grał na wyjeździe czy u siebie, ale o tym zaraz.
(Mamy daną klasę wynik - będę jej używał - ona jest dana z "nieba")

No więc:
W klasie Trener zamieszczam:

Strategia ulubiona.
abstract void ustalSkład (Drużyna d)
abstract void ustalStrategię (Drużyna d)

Teraz dziedziczące po niej będą implementowały te abstrakcyjne fcje - przekazuję przez parametr - bo te metody będą potrzebować informacji z druzyny - zaraz pokaże informacje zawarte w drużynie):

Drużyna (A): (zmieniam na abstrakcyjną, dziedziczyć po niej będzie - gość - gospodarz)

Piłkarz piłkarz[25]
Terner trener
Strategia strategia
Piłkarz skład [11]
Strategia ostatniaStrategia
Wynik ostatniWynik

No niestety, ale klasa Piłkarz będzie pusta (pochodne chyba również). Tak samo ze strategią.
Teraz zatrzymuję się. Coś poprawiać ?

A czym się różni klasa gość od gospodarz? Bo moim zdaniem to dziwny podział. Drużyna to drużyna. Powinna być jakaś klasa Mecz która agreguje w sobie drużyny i określa która jest gospodarzem a która gościem raczej.
Jeśli chodzi o sam projekt to moja rada jest taka żebyś spróbował to wysokopoziomowo zaimplementować, tzn coś jak opisywałem tutaj:
http://4programmers.net/Forum/Edukacja/232547-samonauka-co_dalej?p=1028009#id1028009
w ten sposób najłatwiej robi się takie projekty.

Ok, to faktycznie chyba najlepszy pomysł. Zacznę od tego, żeby napisać metody wybierania strategii:
Dla klasy konsekwentny:

void ustalStrategię (Drużyna d){
     d.strategia = ulubiona //trener drużynie ustawia swoją ulubioną strategię
}

Dla klasy warunkowy

void ustalStrategię (Drużyna d){
     if(drużyna d gra na wyjeździe){
        zwróć losowo strategię (jedna z dwóch - określiłem jaką)
     }
     else{
         (analogicznie)

    }
}

I teraz dzięki temu podejściu faktycznie mamy problem. Rozwiążmy go :) !
Chcemy OBIEKTOWO umieć określić czy jesteśmy gościem czy gospodarzem, a następnie wylosować odpowiednią strategię.

Czemu wszystko musi być sprowadzone do obiektowości? Przecież to czy drużyna jest gospodarzem/gościem można określić przez zwykłą wartość logiczną. Ale jeżeli tak bardzo się upierasz przy zachowaniu wszystkiego obiektowo, to możesz wykorzystać do tego wzorzec... strategia... ewentualnie stan ;]

@mir jak musisz to możesz zrobić dodatkowe klasy określające rolę -> Gospodarz i Gość i które implementują ten sam interfejs co Drużyna. Niech taka Rola przechowuje pole którym jest Drużyna i niech deleguje wywołania metod do Drużyny, ewentualnie modyfikując zachowanie. To się nazywa Dekorator :)

mir napisał(a):

Klasy które dziedziczą po abstrakyjnych:
Po Trenerze :
Konsekwentny (stosuje zawsze ulubioną), warunkowy (zależy gdzie gramy mecz), wynikowy (jaki był poprzedni wynik?)
Po Piłkarzu:
Bramkarz, Obrońca, Pomocnik, Napastnik.

No i po co tyle tych klas? Czym się różni trener "konsekwentny" od "wynikowego" albo Obrońca od Napastnika pod względem swojego interfejsu? Będą mieli jakieś inne metody albo pola?

mir napisał(a):

No niestety, ale klasa Piłkarz będzie pusta (pochodne chyba również). Tak samo ze strategią.
Teraz zatrzymuję się. Coś poprawiać ?

No właśnie - puste klasy, więc po co w ogóle one?
Akurat strategie nie powinny być puste, bo to w nich powinny siedzieć algorytmy implementujące wybór zawodników do meczu.

Klasa Drużyna też jest dziwna. Czym niby jest skład, czy zawsze będzie taki sam? Bo jeśli nie, to nie powinno tam być takiego pola.

mir napisał(a):

Chcemy OBIEKTOWO umieć określić czy jesteśmy gościem czy gospodarzem, a następnie wylosować odpowiednią strategię.

Dlaczego niby obiektowo? Nowe klasy wyodrębnia się ze względu na nowe zachowania, a nie inne cechy.

Tutaj jest tyle tej "obiektowości", że aż stała się parodią.

Przeoczyłem te "puste klasy". Założyłem że te obiekty będą się różnić zachowaniem, tzn Napastnik gra inaczej niż Obrońca na przykład. Ta samo Strategia pusta być nie może ;]

Shalom napisał(a):

Przeoczyłem te "puste klasy". Założyłem że te obiekty będą się różnić zachowaniem, tzn Napastnik gra inaczej niż Obrońca na przykład.

Nawet jeśli, to użyłbym jednej klasy Piłkarz z polem typu enum (Bramkarz, Napastnik, itd.) a same zasady jego zachowania na boisku (czyli de facto jakieś algorytmy grania albo przynajmniej cechy piłkarza) delegował do innych klas. Nie lubię mieszania algorytmów z danymi, których one nie potrzebują, a raczej nazwisko nie ma wpływu na celność strzału.

@somekind a to już zależy jak ta gra ma wyglądać. Nikt tu nic o nazwiskach nie mówił :P Ja założyłem że to klasa Bramkarz na przykład jest klasą która przechowuje algorytm wg którego gra taki typ zawodnika.

Jak to zwykle bywa w programowaniu jedna rzecz można wykonać dobrze na kilka sposobów więc polecam Ci zrobić to tak jak w danej chwili uważasz że będzie najlepiej a jeśli w trakcie projektu okaże się że trzeba coś zmienić to pozwoli Ci to na zapoznanie się z tematem refaktoryzacji z którym i tak w pracy zetkniesz się nie raz.