Materiały do laboratorium programowania obiektowego 2 (C#)

Zadania realizowane w ramach laboratorium programowania obiektowego 2 (C#):

Kulki i przeszkody - motor symulacji i gier z przykładem zastosowania

BBTan, Bricks breaker, Arkanoid, bilardy itp.
kulki/piłki poruszają się ruchem prostoliniowym i odbijają od przeszkód
fizyka odbić
akcja i wizualizacja w czasie rzeczywistym
podpowiedzi obiektowe
- motor gry/symulacji i wizualizacja to dwa różne światy
- stan gry to stan kulek i przeszkód + czas najbliższego zdarzenia zmieniającego stan
- stan kulki definiowany przez czas startu, położenie startowe i kierunek - nie zmienia się "co klatkę" (pojęcie klatki nie ma sensu w motorze)
- ściany, przeszkody, nagrody - hierarchia
- przeszkody odpowiedzialne za określenie punktu i kierunku odbicia
- model fizyczny bez interfejsu graficznego
- wizualizacja aktualnego stanu gry na zewnątrz motoru gry
harmonogram
- do 2025.05.05 - odbicie od odcinka (kierunek)
- do 2025.05.05 - odbicie od łuku
- do 2025.05.12 - przeszkody (kwadraty, koła, trójkąty)
  - zdarzenia odbić, znikanie przeszkód
  - licznik odbić
- do 2025.05.12 - etapy
  - zapamiętanie miejsca wylotu ostatniej kulki
  - dodatkowe kulki
  - startowanie kolejnych etapów

Eksperyment ze słownikiem i dobrym/złym GetHashCode()

Należy stworzyć własną strukturę/klasę, która posłuży jako typ klucza dla słownika (Dictionary). Prosta funkcja testująca sprawdzi działanie dodawania elementów do słownika i pobierania włożonych wcześniej wartości oraz zmierzy czas działania (wystarczy różnica pobieranych DateTime.Now). Do słownika należy wrzucić i pobierać odpowiednio dużo wartości, by otrzymać miarodajne czasy wykonania.

Efektem eksperymentu powinna być świadomość kiedy i dlaczego działa to szybko a kiedy i dlaczego wolno, dlaczego bez GetHashCode dla klas jest wyjątek, a dla struktur nie itd. Do rozliczenia potrzebny jest kod eksperymentu i krótki opis wniosków (można go wstawić jako komentarz do pliku z kodem).

W skrócie, do zrobienia jest:

typy wartościowy i referencyjny (struct i class) dla obiektów-kluczy słownika,
niepoprawna definicja GetHashCode() (np. stała wartość - najgorsze co może być) i poprawna (dobrze rozróżniająca),
ogólna metoda testująca sparametryzowana typem klucza,
program główny sprawdzający po kolei 6 wariantów (struktura/klasa i zły/dobry/brak GetHashCode),
wnioski.

Uwaga! GetHashCode() nadpisujemy zwykle w parze z Equals() - ten sam kod haszujący nie wystarcza by dwa klucze uznać za jednakowe - ostatecznie decyduje właśnie Equals(), która domyślnie, w przypadku typów referencyjnych porównuje referencje właśnie, a w przypadku typów wartościowych porówna wnętrza (dla struktur pole po polu).

Problem B z finałów konkursu ACM 2009

Klasy:
- Zadanie
  - Układ
  - kolekcja testów
  - przeprowadzanie testów, weryfikacja wyników, określenie decyzji
- Układ
  - kolekcja bramek z połączeniami
  - kolekcja wejść układu
  - kolekcja wyjść
  - możliwość uszkadzania bramek
  - przeprowadzanie symulacji
- Bramka i potomne: And, Or, Xor, Not, Wejście
  - argumentowość bramki (liczba wejść)
  - funkcjonalności poszczególnych bramek
  - wejście układu może być realizowane jako potomna klasy Bramka (0 wejść, wyjście ustawiane na sztywno)
  - możliwość uszkodzenia każdej bramki (zaimplementowana na poziomie abstrakcyjnej klasy bazowej, albo w klasie BramkaWUkładzie)
- BramkaWUkładzie
  - Bramka
  - połączenia wejść bramki
  - funkcjonowanie bramki w układzie
  - ewentualne buforowanie wyjścia i resetowanie go przed zmianą wejść
- Połączenie to BramkaWUkładzie (albo wejście układu, które też można reprezentować jako BramkaWUkładzie; 0 wejść, 0 połączeń), więc niepotrzebna osobna klasa
- Test - reprezentacja pojedynczej obserwacji/testu, nie funkcjonalność wykonywania testów
  - wejścia dla układu
  - wyjścia z układu
  - tylko dla porównywania z tym co wychodzi z układu - kompetencja klasy Zadanie
  - lepiej jako struktura a nie klasa

Obiektowość to m.in. rozdział funkcjonalności pomiędzy poszczególne klasy, nawet wczytywanie danych powinno być odpowiednio rozłożone:

Metoda Wczytaj() w co najmniej 3 klasach (Zadanie, Układ, Test)

wczytanie zadania to wczytanie układu, liczby testów i poszczególnych testów:

class Zadanie {
  Układ układ;
  Test[] testy;
public:
  ...
  void Wczytaj(TextReader tr)
  {
	układ = new Układ();
	układ.Wczytaj(tr);
	int ileT = int.Parse(tr.ReadLine());
	testy = new Test[ileT];
	foreach (Test t in testy)
	  t.Wczytaj(tr, układ.IleWe(), układ.IleWy());
  }
};

Sposób wyznaczania wyjść i reprezentacja układu (algorytmy + struktury danych = programy)
- wersja brzydsza (mało obiektowa) mapowanie wejść na wyjścia, sortowanie topologiczne
- wersja porządna, obiektowa rekurencyjne wyznaczanie tego co potrzebne z kontrolą, by nie liczyć wielokrotnie tego samego
rozwiązywanie zadania poprzez zastępowanie kolejnych bramek przez uszkodzone i testowanie układu
atrybuty oznaczające bramki i wykorzystane przy tworzeniu bramek (bez zmian, gdy nowy typ bramki)

Problem F z finałów konkursu ACM dla Europy Centralnej 2001

cysterny dowolnego kształtu - również kule, cylindry, stożki - klasa bazowa z metodami abstrakcyjnymi + różne klasy potomne
wizualizacja w programie okienkowym - minimum 2D, najlepiej 3D
(nieco później, gdy o danych meta powiem na wykładzie) dane meta dla automatycznego rozpoznawania dostępnych kształtów

Ocena wg sumy punktów:

Kulki i przeszkody - 6/10 pkt. (4 pkt. za wersję okienkową)

GetHashCode() - 4 pkt.

Bramki (B-2009) lub Cysterny (F-2001) - 10 pkt.

Dodatkowe punkty za rozwiązania wykraczające poza ww. wymagania (np. atrakcyjny interfejs graficzny)

≥3 jeśli suma ≥ 12 pkt.

≥3,5 jeśli suma ≥ 14 pkt.

≥4 jeśli suma ≥ 16 pkt.

≥4,5 jeśli suma ≥ 18 pkt.

=5 jeśli suma ≥ 20 pkt.