Ogólnie, na co by się autor wątku w ostateczności nie zdecydował, polecałbym później zrobienie unikając koncepcji z programowania obiektowego i porównanie, który kod będzie bardziej zwięzły i zrozumiały. Wkładanie obiektowości w tym zastosowaniu jest bardzo na siłę i nie przyniesie nic dobrego.
Generalnie jestem za - napisz wersję w pełni proceduralną i pokaż nam jaka ona będzie łatwa. :)
Jednak prościej i czytelniej będzie zrobić do tego pojedyncze funkcje a nie klasy.
Nie wiem czy wiesz, ale klasy mogą zawierać funkcje. Co więcej, ideą istnienia klas jest zawieranie w sobie funkcji. (Coś takiego jak obiekt bez funkcji nie jest obiektem w OOP.)
Zaletą funkcji w oddzielnych klasach jest to, że można je umieścić w oddzielnych plikach co ma wpływ na przejrzystość i łatwość czytania kodu, a z drugiej strony można je umieścić w jednej kolekcji, co daje łatwość wywołania.
Ja ogólnie jestem zwolennikiem podejścia pragmatycznego - nie wiem, jak długie będą te funkcje i ile ich będzie, a sposobów organizacji może być wiele:
- wszystkie funkcje w jednej klasie;
- każda funkcja w oddzielnej klasie;
- pogrupowanie tematyczne (razem funkcje sprawdzające prawidłowość ruchu zgodnie z zasadami bierek, w drugiej klasie funkcje sprawdzające czy ruch zawiera się w planszy, w trzeciej np. roszada, w czwratej jeszcze coś innego).
Trudno powiedzieć, które rozwiązanie będzie lepsze zanim zacznie pisać się kod i zobaczy, co z niego wyjdzie. Jeśli ktoś twierdzi, że lepiej wie, co będzie lepsze zanim zacznie pisanie kodu, to lepiej niech wraca do swoich kredek i maluje te swoje UMLe dalej.
Proste rozwiązanie, które przychodzi mi do głowy to pojedyncza maska bitowa dla każdego z graczy. I wtedy np.: if (maska_ruszonych_figur[nr_gracza] & MASKA_DLA_ROSZADY_LEWEJ) == 0) { mozna-wykonac };
To jest naprawdę szczegół, generalnie i tak należy się zdecydować na jedno z dwóch podejść: albo w momencie próby wykonania roszady przez gracza sprawdzamy historię i stan planszy, albo po każdym ruchu zapisujemy w bieżącym stanie gry informację o tym, czy roszada jest możliwa.
Jeśli nie były ruszane to są. Jeśli były ruszane, to jest bez znaczenia, czy są na swoich polach.
Chodziło mi o roszadę z wieżą powstałą na skutek promocji piona, ale mniejsza z tym. Chciałem zarysować ogólną koncepcję, nie projektować wszystko z góry. Takie szczegóły jak dokładny podział na funkcje czy klasy wychodzą w trakcie tworzenia.
Tu znowu funkcja lepiej pokazuje intencje niż klasa.
Niewątpliwie.
Tylko ja mam wrażenie, że Ty kompletnie nie rozumiesz idei klas. Klasy nie zawierają instrukcji, to funkcje zawierają instrukcje. Klasy są sposobem modularyzacji oraz trzymania przy funkcji danych i zależności, których funkcja potrzebuje.