Witam

Pisze sobie aplikacje w skrocie mowiac
poczatkowo startuje parser ktory tworzy na wyjsciu liste obiektow
w pewnym momencie istnieje potrzeba ich graficznej reprezentacji.
Obiekty dziedzicza po klasie bazowej.

Poczatkowo uzywalem klasy pomocniczej i kilku metod statycznych do ich
rysowania jednak podczas refactoringu stwierdzilem
ze nie ma sensu juz dluzej traktowac ich jako zwykle struktury danych
tylko jako obiekty ktore same siebie rysuja,
czyli wiaze sie to z implelentacja metod bezposrednio w klasach.

Mysle ze takie podejscie jest lepsze szczegolnie przy rozbudowie
programu, jednak zawsze uwazam zeby zbytnio nie przesadzac z obiektowoscia.

do góry

> Mysle ze takie podejscie jest lepsze szczegolnie przy rozbudowie programu,
> jednak zawsze uwazam zeby zbytnio nie przesadzac z obiektowoscia.

polecam zastosowac obiektowy wzorzec kompozyt - idealny do tego typu zadan

do góry

> polecam zastosowac obiektowy wzorzec kompozyt - idealny do tego typu zadan
>

do organizacji hierarchii samej sturktury obiektów - jak najbardziej
kompozyt.

natomiast do separacji algorytmu rysującego od szczegółów tej struktury -
wzorzec visitor.

Wiktor Zychla

do góry

>
> do organizacji hierarchii samej sturktury obiektów - jak najbardziej
> kompozyt.
>
> natomiast do separacji algorytmu rysującego od szczegółów tej struktury
> - wzorzec visitor.

ten wzorzec >visitor< przypomina mi implementacje zdarzen w Javie

generalnie mam juz kompozyt ktory prawdopodobnie rozbuduje do czegos
podobnego jak visitor

do góry

>
> generalnie mam juz kompozyt ktory prawdopodobnie rozbuduje do czegos
> podobnego jak visitor

prawde mowiac to nawet kompozytu nie potrzebuje
bo mam strukture liniowa, tylko
ewentualna rozbudowe w kierunku visitora

public interface Entry {
public void draw(Graphics g, ViewportCfg cfg);
}

----

public class ... implements Entry { ... }

----

while (list.hasMoreElements()) {
entry = list.nextElement()
entry.draw(g, cfg);
}

do góry