Uwagi do klasówki z PO (z 15.XII.2003):

• Zmienne klasowe w Grze (lub globalne) reprezentujące kostki, graczy, stół, ....
  Komentarz: to bardzo ogranicza funkcjonalność, nie można mieć kilku egzemplarzy gry naraz, kłopotliwe i podatne na błędy staje się przeprowadzanie gry.
• [j<7] whileTrue: [...], karty jako Bag, ...
  Komentarz: nie ma sensu zaciemniać treść swoich programów, liczba 7 nic nie znaczy w zadaniu z klasówki (powinno być [j<=6] whileTrue: [...]), Bag sugeruje, że jedna kostka może wystąpić w kilku egzemplarzach (powinien być np. Set). To nie konkurs na najbardziej zaciemniony kod w Smalltalku :).
• Student dziedziczy po Dziecko, ...
  Komentarz: dziedziczenie wyraża relację bycia-czymś, powyższe dziedziczenie znaczy "każdy student jest dzieckiem" (wszystkie trzy rodzaje graczy powinny dziedziczyć po abstrakcyjnej klasie Gracz).
• Gra (Gracze, Kostki) dziedziczą po którejs z kolekcji
  Komentarz: typowy przykład pomylenia relacji mieć-coś z być-czymś. Naszym celem nie jest stworzenie kolejnej realizacji kolekcji, lecz użycie kolekcji do pamiętania graczy (kostek). Zamiast dziedziczyć implementację należało dodać zmienną egzemplarzową zawierającą kolekcję.
• Gracze pamiętani w Set czy nawet w SortedCollection
  Komentarz: pierwsze nie definiuje kolejności, drugie narzuca zupełnie absurdalną (w tym zadaniu).
• Używanie klas IndexedCollection, List
  Komentarz: pierwsza jest abstrakcyjna, druga niestandardowa.
• Pamiętanie w jednym graczu kostek innego
  Komentarz: obiekty mają chronić swoje dane (by móc nimi zarządzać). Jeśłi ktoś chce dowiedzieć się o stan gracza, to powinien go zapytać.
• Brak opisu metod (atrybutów)
  Komentarz: treść zadania jednoznacznie wymaga tego opisu.
• Pisanie w części projektowej implementacji metod zamiast ich opisu
  Komentarz: Opis metody ma mówić co metoda robi, a nie jak to robi.
• Pisanie implementacji dopełnienia zbioru wymaganych metod
  Komentarz: ?!?!?!?! .
• Opis atrybutu "kolekcja"
  Komentarz: to jeszcze nic nie mówi, trzeba powiedzieć jaka i co ma być zawartością (np. Set Graczy, czy zbiór Kostek).
• Brak akcesorów (prostych) w projekcie, choć są używane w implementacji
  Komentarz: decyzja że klasa dostarcza akcesorów do swoich atrybutów jest bardzo poważną decyzją projektową, bo obiekty mają chronić swoje dane. Dodanie prostych akcesorów umożliwiających dowolne manipulowanie wartościami zmiennych egzemplarzowych absolutnie nie jest standardowym rozwiązaniem! Robimy to tylko wtedy, gdy jest to konieczne.
• Drastyczne niepamiętanie składni
  Komentarz: wystarczy zajrzeć do notatek ... . Pisanie () zamiast [] to dużo poważniejszy błąd niż niepamiętanie składni, to brak zrozumienia pojęcia bloku.
• Pomijanie fragmentów implementacji
  Komentarz: treść zadania wyraźnie wymaga implementacji wszystkich niestandardowych metod. Co najwyżej można pominąć implementację prostych akcesorów (o nazwie takiej jak atrybut i treści ^atrybut lub atrybut := parametr), ale nawet je należy umieścić w projekcie.