[ Pobierz całość w formacie PDF ]

sprawdza katalogi umieszczone w ścieżce dostępu do klas. Gdybyśmy jednak zmienili
w wierszu 4. parametr wywołania metody z na
, to, sprawdzając katalogi umieszczone w ścieżce dostępu do klas, metoda
114 Java. PotrzaskI
poszukiwałaby pliku com/mycompany/myapp/System.properties.
Obie możliwości są równie dobre. Jeśli chcemy przechowywać razem wszystkie pliki
właściwości, to wybierzemy pierwszą z nich. Jeśli natomiast preferujemy umieszcza-
nie plików właściwości w tym samym katalogu, w którym korzystające z nich klasy,
właściwe będzie drugie rozwiązanie. Najważniejsze jednak jest to, że w obu przypad-
kach użytkownik nie musi już umieszczać pliku właściwości System.properties w ka-
talogu c:\myApp\properties. Możemy także utworzyć plik typu jar, który będzie za-
wierać klasy i pliki właściwości.
Spróbujmy teraz wykorzystać nasz plik właściwości do utworzenia paska narzędzi.
Załóżmy, że pliki ikon każdego narzędzia będzie określany w pliku System.properties.
Pozwoli to zmienić ikonę narzędzia bez konieczności wprowadzania zmian w kodzie
programu. Informacje opisujące ikonę narzędzia w pliku właściwości będą miały na-
stępującą postać:
Właściwości i określają kompletne ścieżki dostępu do ikon na-
rzędzi. Możliwość modyfikacji pliku właściwości jest z pewnością lepszym rozwią-
zaniem niż modyfikacja kodu programu. Jednak także w tym przypadku natrafiamy
na ten sam problem co w przypadku kodowania ścieżki dostępu do samego pliku wła-
ściwości. Jeśli użytkownik nie zainstaluje naszej aplikacji w katalogu c:\myApp, to
program nie odnajdzie plików ikon. Lepszym rozwiązaniem będzie więc umieszczenie
w pliku właściwości tylko ścieżek dostępu określonych względem katalogu, w którym
został zainstalowany program. Musimy wtedy dodatkowo utworzyć właściwość
, która będzie przechowywać informacje o katalogu, w którym został za-
instalowany program. Wiele programów instalacyjnych, na przykład InstallShield, umoż-
liwia uzyskanie informacji o katalogu, w którym użytkownik zainstalował aplikację.
Dzięki temu można prawidłowo zainicjować właściwość i przecho-
wywać jedynie względne ścieżki dostępu do zasobów. Na przykład, gdy użytkownik
zainstaluje aplikację myApp w katalogu d:\apps\myApp, to zawartość pliku właściwości
będzie wyglądać następująco:
Oczywiście teraz kod programu po pobraniu ścieżki dostępu do zasobu musi dołączać
ją do wartości . Oto fragment kodu pozwalający uzyskać pełną ścież-
kę dostępu do zasobu :
Użytkownik może teraz zainstalować aplikację w dowolnym katalogu i będzie ona zaw-
sze mogła uzyskać dostęp do swoich zasobów.
RozdzIał 3. f& Użyteczne kIasy I koIekcje 115
Z instalacją aplikacji mogą być związane jeszcze inne problemy. Na przykład użytkow-
nik zainstalował ją w katalogu /pkgs/programs systemu Unix. Aplikacja nada więc wła-
ściwości wartość . Aby załadować ikonę przycisku Save,
aplikacja dołączy do właściwości łańcuch . Pełna
ścieżka dostępu będzie więc miała postać /pkgs/program\\images\\save.gif, stanowiąc
mieszankę sposobu zapisu ścieżek w systemach Unix i Windows. Aby rozwiązać ten
problem, napiszemy pomocniczą metodę, która będzie zmieniać format ścieżek w za-
leżności od systemu operacyjnego. System operacyjny, w którym działa aplikacja, usta-
limy, korzystając z właściwości systemowej . Jeśli będzie nim Unix, to znaki
zastąpimy w ścieżkach znakiem . W ten sposób na przykład ścieżka dostępu do iko-
ny przycisku Save uzyska postać /pkgs/programs/images/save.gif.
Kolejny problem związany z naszym zastosowaniem obiektów klasy po-
lega na zapewnieniu, że wszyscy programiści pracujący nad aplikacją będą korzystać
z metody . Dotychczas omówiliśmy dwa sposoby ładowania
obiektów , ale istnieje ich znaczniej więcej. Jeśli więc kod aplikacji jest
tworzony przez kilku programistów, to istnieje szansa, że przynajmniej jeden z nich
będzie ładował obiekty klasy inaczej niż pozostali. Taka niespójność mo- [ Pobierz całość w formacie PDF ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • alwayshope.keep.pl

    •