Adres kursu na UPEL: https://upel.agh.edu.pl/course/view.php?id=7445 Każda grupa otrzyma osobne hasło
Symbolem ✔ oznaczono zadania planowane w 2024/2025
Map<Long, AdminUnit> adminUnitId = new HashMap<>();
nie dodajemy do AdminUnitList
jako atrybutów. Nie jesteśmy w stanie zapewnić spójności stanu takich atrybutów - kiedy np. tworzymy listę zawierającą wybrane jednostki. Mapy powinny być tworzone tylko na czas czytania wewnątrz funkcji read()
. Exception
bo:RuntimeException
…catch(SomeException e){ System.out.println("exception description"); }
ale
catch(SomeException e){ e.printStackTrace(); }
Ważniejszą informacją jest miejsce wystąpienia błędu, niż jego lakoniczny opis!
BoundingBox
zapewnia interfejs addPoint(), który implementuje pewną logikę. Nie wpisujemy tam wartości bezpośrednio, bo musielibyśmy powtórzyć tę logikę. filter
z indexOf
nie jest zbyt dobrym pomysłem. Złożoność $O(n^2)$ zamiast $O(n)$AdminUnit
raczej nie ma sensu pisać konstruktorów. Taki typ klas nazywa się DTO (inna wersja to POJO). Rekord z pliku lub bazy danych został zamieniony na obiekt. Gdzieś tam jest kod który wypełnia te atrybuty podczas odczytu lub odczytuje ich wartości podczas zapisu. Konstruktor tylko w tym przeszkadza. Patrz: https://stackoverflow.com/questions/1612334/difference-between-dto-vo-pojo-javabeans. Można też pisanie konstruktorów zautomatyzować: LombokAdminUnitsQuery
polecam rozwiązanie M.Ś. AdminUnitList execute(){ src = src.filter(p); src = src.sort(cmp); src = src.filter(x -> true, offset, limit); // x->true oznacza ze nic nie bedzie wurzucone, predykat zwiekszylby zlozonosc return src; }
fixMissingValues()
memoizacja ????. Gdyby drzewo miało głębokość 1000, było posortowane od najgłębiej połozonych węzłów, a szukana wartość byłaby w korzeniu, to przeglądalibyśmy je 1000+999+…1 razy - $O(n^2)$. Zamiast tego można zapisać wartość przy okazji rekurencji i znacznie zmniejszyć złożoność. To powinnien być automatyczny wybór.