Która koncepcja przechowywania danych jest lepsza?

Powiedzmy, że mamy klasę, która operuje na bardzo wielu obrazkach, które są wykorzystywane przez wszystkie metody tej klasy. Możemy zrobić dwie rzeczy:

1. Zadeklarować oraz zainicjować n pól klasy reprezentujących te obrazki:

Image img1 = new Image("img/img1");
Image img1 = new Image("img/img2");
                    ....
Image imgn = new Image("img/imgn");

1. W jakimś zwięzłym fragmencie kodu (na przykład plik xml ze ścieżkami do obrazków i pojedyncza pętla) wczytać wszystkie do mapy typu np. HashMap<String,Image>, a następnie odnosić się do nich poprzez wywołania typu:

HashMap<String,Image> images;
....

images.get(img1).operation1();
images.get(img2).operation2();

itd.

Zawsze byłem zwolennikiem wykorzystywania takich map, ponieważ pozwalają często uprościć zapis i pozbyć się niepotrzebnego bałaganu w kodzie - w przedstawionym przypadku - tworzenia licznych pól klasy. Czasem jednak zastanawiam się, czy nie przesadzam. Teoretycznie dostęp do HashMapy zaindeksowanej jakimś Stringiem nie jest bardzo długi (funkcja haszująca), jednak na pewno wolniejszy niż do zwyczajnej zmiennej. Ponaddto jeżeli jeżeli wpiszemy złą nazwę obrazka, to wystąpi błąd czasu wykonania zamiast błędu kompilacji..

Czy może ktoś wyrazić swoją opinię na ten temat, żeby pomóc mi zdecydować się na określony styl programowania?

Jesli tych obrazkow bedzie zawsze tyle samo, to mozesz sobie darowac hashmape. z drugiej strony, jesil nie znasz ich ilosci to jest to rozsadne podejscie. jesli liczba obrazkow jest stala i wynosi np 50, to moze tablica?

jesli nie znasz ich ilosci to jest to rozsadne podejscie. jesli liczba obrazkow jest stala i wynosi np 50, to moze tablica?

Ale wtedy musiałbym zdefiniować sobie szereg stałych typu int, żeby móc wygodnie odnosić się do wybranego obrazka, np:

static final int IMG_MOUSE = 5;
...
images[IMG_MOUSE].operation1();

A w więc w zasadzie z deszczu pod rynnę. To czego chciałem uniknąc - rozległą cześć "deklaracyjna" - i tak tutaj robię.

Jeżeli chodzi tylko obrazki, które chcę zawsze przetwarzać w identyczny sposób, bez wnikania w to, jaką dany obrazek pełni rolę, to oczywiście masz rację - umieszczając obrazki w tablicy lub HashMapie można je wszystkie przetworzyć w jednej pętli, a w przypadku tablicy będzie to wykonane znacznie szybciej. Powiedzmy jednak, że chciałbym rozróżniać obrazki.

Się tak zastanawiam czy ty przez przypadek nie będziesz szczęśliwym posiadaczem listy. HashMapa jest dobra pod warunkiem, że musisz koniecznie posiadać dostęp do konkretnego obrazka, a nie obrazka tak generalnie.
Co do HashMapy to możesz też spróbować napisać własną implementację, która rozwiąże ten problem. Jest jeszcze kolejna możliwość, czyli użycie Properties.

HashMapa jest dobra pod warunkiem, że musisz koniecznie posiadać dostęp do konkretnego obrazka, a nie obrazka tak generalnie.

No właśnie chciałbym mieć możliwość dostępu do konkretnego obrazka :).

Proporties to tak naprawdę HashMapa typu <String, String>, nie sądzę, żeby była użyteczna w tym akurat problemie.

Nie wiem, czy nie będzie dobrze po prostu stworzyć osobnej klasy, do której wyrzucę wszystkie te pola obrazków i dam im widoczność w obrębie pakietu. Dzięki temu klasa główna pozostanie czytelna (nie będzie zaśmiecona niepotrzebnym kodem), a ja będę miał dostep do wszystkich obrazków "po nazwie". Wada: nie błędę mógł wykonywać operacji na wielu na raz.

A dlaczego boisz sie stalych i "rozleglej czesci deklaracyjnej"? Nie widze w tym nic zlego ogolnie, jak mus to mus. Jesli masz stala, konkretna ilosc obrazkow, to ja z kolei nie widze sensu korzystac z dynamicznej struktury danych. Myslac o tablicy nie myslalem co prawda o indeksach w postaci stalych int, ale to w sumie niezly pomysl, wiec ja bym obstawal za wlasnie takim rozwiazaniem. Tak samo, nie widze sensu korzystania z List dla stalej ilosci elementow, znanej z gory...
Co do tego ze osobne zmienne nie pozwola na wykonywanie czynnosci w petli - potrzebujesz taka funkcjonalnosc?

Masz rację, pikseloza, na razie nie potrzebuję takiej funkcjonalnosci. Może Twoja propozycja rzeczywiście jest najlepsza...

Witam po półrocznej przerwie.

A może enumy?

import java.awt.Image;
import java.io.File;
import java.io.IOException;

import javax.imageio.ImageIO;

public enum PreloadedImage {

	A("a.jpg"), B("b.jpg");

	private final String path;

	private Image image;

	private PreloadedImage(String path) {
		this.path = path;
	}

	public synchronized Image getImage() throws IOException {
		if (image == null) {
			image = ImageIO.read(new File(path));
		}
		return image;
	}

}

I mały test:

import java.awt.Image;
import java.io.IOException;

public class TestImage {

	public static void main(String[] args) throws IOException {
		TestImage test = new TestImage();
		test.test();
	}

	private void test() throws IOException {
		Image image = PreloadedImage.A.getImage();
		// do sth with image
		
		for (PreloadedImage im : PreloadedImage.values()) {
			image = im.getImage();
			// do sth with image
		}
	}
}