[instanceof i rzutowanie] 2 pytania

Piszę slinik do gry 2D. Mam już menedżery ekranu i wejścia. Przyszedł czas na stworzenie mapy stworzonej z kafelków. Ponieważ chcę, aby była ona dość złożona - tzn. kafelki mogą być animowane, mogą wpadać w kolizję z jednej strony, a z innej nie itd. Nie chcę, aby moja mapa przechowywała zbyt wiele danych, bo moze to być obciążeniem dla kompa. Pomyślałem, że mógłbym przechowywać wszystkie kafelki w tablicy Object.

W metodzie getImage(x, y) zwracał bym obrazek kafelka. Sprawdzałbym, czy kafelek nalezy do Image, do Animation (moja własna klasa), czy do czegoś tam jeszcze innego. Później rzutowałbym obiekt na odpowiedni typ, wyciągał z niego obrazek i zwracał go.
Czy używanie w jednej bardzo często wykorzystywanej metodzie instanceof i rzutowania nie spowolni działania gry?

I to jeszcze jak :)
W ten sposób nic nie zoptymalizujesz, a tylko pogorszysz sprawę. Ilość danych pozostanie taka sama, a dodatkowo może zdarzyć się ich utrata. Lepszą metodą jest utrzymywanie wszystkich kafli planszy w ramach pojedynczej klasy, która będzie zbiorem i która będzie wykonywała odpowiednie operacje na wskazanych kaflach bez przekazywania ich poza siebie. Czyli w praktyce otoczenie grupy obiektów kafli jednym obiektem pełniącym rolę proxy.

Ja chciałem zrobić coś takiego:

class TileSet
Image getImage(int x, int y) - zwraca obrazek jaki aktualnie wyświetla kafelek
void set(int x, int y, Image image) - ustawia kafelek na obrazek 
void set(int x, int y, Animation anim) - ustawia kafelek na animację
i jeszcze jakaś metoda, która by ustawiała kafelek, który może kolidować tylko z niektóych stron, a z innych można go przenikać

No i wydaje mi się, że marnowanie miejsca na przechowywanie tablicy takich samych obiektów Tile byłoby marnowaiem pamięci. Bo powiedzmy, że ten tile może kloidować tylko z prawej strony, to wtedy przechowuje 4 wartości boolean dla każdej strony z kafelka. Na takiej mapie jest strasznie dużo kafelków. Więc pamięć się marnuje, chociaż większość kafelków koliduje z każdej strony. Dodatkowo niektóre kafelki mogą przechowywać tylko pojedyńczy obiekt Image, a inne mogą się animować i przechowywać Animation. Gdyby wszystkie miał przechowywać Animation pamięć by się marnowała, bo Animation jest wewnetrznie bardziej złozona.

Ale tak mi teraz wpadło do głowy, żeby zrobić interfejs Tile. Zawierałby on jedną metodę getImage()
Byłyby podklasy SimpleTile, która by zawierała tylko obrazek i istniałyby bardziej skomplikowane klasy. Pamięć by się wtedy nie marnowała. Uważasz, że to dobry pomysł?

Hm... można by podzielić kafle na krawędziowe i wewnętrzne. Przyjrzyj się też obrazkom. Można by oszczędzić masę miejsca gdyby wszystkie jednakowe kafle wskazywały na ten sam obrazek, czyli trzymany był by jako singleton.

Tylko ja chciałbym zrobić silnik o dużych możliwościach. W grze możnaby np. niszczyć kafelki. Wtedy podział na krawędziowe i wewnętrzne nie miałby sensu, bo to które są wewnętrzne szybko mogłyby stać się krawędziowe.

Ale stworzenie interfejsu Tile i podklas tak jak to pisałem byłoby wydajne? Mi się wydaje, że tak, ale ja się nie znam tak dobrze na działaniu JVM, więc wolałbym sie upewnić.

Na pewno było by lepiej. Co do podziału to może być użyta flaga lub enum do oznaczania typu, a nie od razu cała klasa.

Nie do końca rozumiem jak miałoby wyglądać to z tymi kafelkami krawędziowymi i wewnętrznymi. Możesz mi to dokładniej przedstawić. Czym taki wewnętrzny by się różnił?

Witam

W wolnej chwili możesz chwili , jeśli nie znajdziesz satysfakcjonującego cię rozwiązania, możesz zerknać na wzorzec Flyweight (który tłumaczy sie na "pyłek" lub "waga piórkowa").

http://en.wikipedia.org/wiki/Flyweight_pattern

W teorii ma to zmniejszyć zużycie pamięci.

pzdr