Wskazówki do projektu

Witam,

Mam do napisania projekt zaliczeniowy:
http://www.cs.put.poznan.pl/dbrzezinski/teaching/poZaoczne/po_proj_zaoczne.pdf

Nie szukam gotowego rozwiązania lecz wskazówek jak ugryźć to zadanie. Chodzi mi na te chwile o warstwę prezentacyjna w Swingu mianowicie w jaki sposób prezentować zamówienia?
Zwykła tabela z nazwa, opis, kalorie, cena , zawartości x3, adres dostawy, przycisk zobacz, przycisk usuń.

I w przypadku zamówienia prostego to wygląda mniej więcej tak:
nazwa | opis | kalorie | zawartości x3 | adres dostawy | przycisk zobacz | przycisk usuń
jakaś nazwa | - | 100kc | 100g | wypisany lub brak | brak | usuń

a w przypadku zamówienia złożonego:
nazwa | opis | kalorie | zawartości x3 | adres dostawy | przycisk zobacz | przycisk usuń
jakas nazwa | treść opisu | suma kalorii | suma zawartości | brak | zobacz | usuń

i po kliknięciu na zobacz otwiera się okienko z tabela zawierająca zamówienia proste dla danego zamówienia?

Czy lepiej to zrobić za pomocą treeTables lub w jakiś inny sposób?

Klikasz zamówienie. Jeżeli jest to zamówienie proste to pokazuje się tabelka z zamówieniem. Proponuję tu wygląd "formularzowy", czyli dwie kolumny ileś tam wierszy.
Jeżeli zamówienie złożone to pokazuje się drzewko

Zamówienie złożone
    |-zamówienie proste 1
    |-zamówienie proste 2
    +-podzamówenie zlożone
    \-zamówienie proste 3

Jak klikniesz na coś to można wybrać opcję "pokaż szczegóły". W przypadku złożonego pokazujesz tylko informacje sumaryczne.

Czy dobrym podejściem jest tworzenie 3 klas, Zamowienie, ZamowienieProste extends Zamowienie, ZamowienieZlozone extends Zamowienie i następnie tworzenie kolekcji List<Zamowienie> lista = new ArrayList<Zamowienie>(); w której beda trzymane wszystkie zamówienia ? Dla zamówienia złożonego było by pole ArrayList z podzamówieniami.

I zdecydowałem że najlepiej będzie wyświetlać elementy w drzewie(Jtree) bo zadanie zamówienia maja jak najbardziej przypominać strukture plików. Tylko teraz z racji referencji typów nie moge odwołac się przy pętli for each dla listy dla metod ZamowieniaProstego, ani ZamowieniaZlozonego. Mołby mi ktoś wskazać jakaś drogę rozwiązania tego problemu, zadania ?

Zamówienie to raczej interfejs mi tu bardziej pasuje. Każde zamówienie można opisać w konkretny sposób, czyli zamówienia mają wspólny interfejs. Następnie z tego robisz klasę ZamówienieProste i ZamówienieZłożone. Po czym dokonujesz rafaktoryzacji polegającej na wyciągnięciu powtarzającego się w tych klasach kodu do klasy ZamówienieAbstrakcyjne, z której klasy będą dziedziczyć ZamówienieProste i ZamówienieZłożone.

W ten sposób:

• Dalej w kodzie możesz używać interfejsu Zamówienie bez wnikania w implementację.
• Nie masz powtarzającego się kodu
• Nadal masz swobodę pracy z konkretnymi typami jeżeli zajdzie taka potrzeba.
• Możesz w razie czego całkowicie wymienić implementacje bez zmian w reszcie kodu.