Czy "wypada" przekazywać DataModel jako parametr..

0

Piszę w Javie program, który ma wykorzystywać bazę danych. Pomyślałem, że stworzę klasę DataModel, która mi tą bazę ładnie opakuje. Program będzie miał dużo okien dialogowych i moje pytanie jest następujące: Czy "wypada" przekazywać DataModel do konstruktora okna dialogowego, aby to pobrało sobie z niego potrzebne dane, a czasem coś dodało od siebie po zaakceptowaniu przez użytkownika?

0

Odpowie ktoś?

0

Wydaje mi sie, ze lepiej bedzie, jesli DataModel bedzie singletonem, jezeli reprezentuje polaczenie z baza i czynnosci, ktore mozna na niej wykonac. Latwiej bedzie sie do niego dostac i nie trzeba zasmiecac sobie listy parametrow obiektem, ktory zawsze przekazywany jest taki sam.

0

A jak profesjonaliści inicjalizują singletona, który potrzebuje jakiś zewętrznych danych? Czy singleton sam się inicjalizuje i reszta programu o tym nie wie, czy może podczas uruchamiania programu zrobić coś takiego:

Singleton.getInstance().init(/*parametry*/);
0

Jakie zewnetrzne dane masz na mysli? Dane do serwera bazy danych na przyklad? Ja w takim wypadku przy tworzeniu pierwszej instancji singletona pobieram je powiedzmy z pliku. Ale robi to metoda getInstance singletona, tak ze obiekt wywolujacy nie ma o tym pojecia.

0

Dane do serwera bazy danych na przyklad?

Dokładnie. Nie wiedziałem, czy wypada, żeby robiła to metoda getInstance() ;)

0

Wiesz, wypada nie wypada. Z punktu widzenia obiektu potrzebujacego DataModel nie interesuje go jak, gdzie i skad tworzony jest ten obiekt. Interesuje nas gotowy, w pelni zainicjalizowany obiekt. Stad, jezeli getInstance zna lub moze pobrac sobie sama dane do inicjalizacji to niech to zrobi i nie zrzuca odpowiedzialnosci na klase zewnatrz. Tym bardziej, ze DataModel moze reprezentowac dowolna implementacje bazy danych (np. plik tekstowy), stad obiekt wywolujacy nie powinien sie wtracac ta implementacje - na przyklad podajac dane polaczeniowe do mysql'a.

Dodatkowa zaleta rozwiazania jest tzw. lazy load - dane zostana pobrane wtedy, kiedy beda potrzebne (podczas pierwszego wywolania getInstance), wiec nie obciazasz aplikacji na starcie.

Z drugiej strony mozliwe jest inne rozwiazanie. Jezeli DataModel jest fabryka polaczen parametr przy getInstance moglby okreslac rodzaj tworzonego obiektu. Np. w bibliotece PEAR (php) jest sobie 'zestaw' MDB2 do laczenia z baza. Podajac przy laczeniu string: 'mysql:server=localhost, database=..., itp' informujesz singletona-fabryke by podal Ci obiekt polaczeniowy sluzacy jako interfejs do MySQLa. Z tymze tutaj ta klasa jest zarowno fabryka, bo tworzy odpowiedni obiekt na podstawie stringu i pool manager'em (nie pamietam jak sie wzorzec nazywa) - bo podaje zawsze ten sam obiekt dla tego samego stringu. Zaleta jest przechowywanie otwartych polaczen do roznych baz danych, ale nie wiecej niz ilosc unikalnych danych polaczeniowych. Czyli jesli podasz 2 rozne stringi to otrzymasz w rozne polaczenia, jesli podasz 2 takie same stringi otrzymasz 1 obiekt, utworzony tylko raz.

Zaleznie od potrzebnego rozwiazania obydwie propozycje maja wady i zalety jak widac.

//edit
W zadnym z dwoch rozwiazan jak widac obiekt nie jest przekazywany jako parametr tylko pobierany z singletona/pool managera.

0

Nigdy nie pisałem aplikacji biznesowych, więc nie wiem jak to powinno wyglądać. Wydawało mi się jednak, że cała inicjaliazacja powinna odbywać się w jednym miejscu w aplikacji, a nie tak, że każda klasa dba o siebie. Myślę, że wtedy widać dokładnie z czego aplikacja korzysta.

0

Obydwa rozwiazania maja sens, tylko pytanie, ktore jest wygodne. Jezeli klasa moze zajac sie wlasna inicjalizacja, bo jest ona nieskomplikowana to lepiej, bo zrzucasz ciezar na klase, ktorej on dotyczy. Jezeli natomiast inicjalizacja wiaze sie z odczytaniem np. 1kB xml'a, sparsowaniem i wczytaniem roznych danych dotyczacych roznych obiektow do obiektu klasy np. Settings, to wtedy lepiej to odczytanie i inicjalizacje zamknac w osobnej klasie, np. Settings wlasnie, bo jest na tyle skomplikowanym procesem, ze lepiej nadzorowac go osobnym 'bytem'.

Inicjalizacja na poczatku ma te wade, ze podczas startu czekasz na inicjalizacje wszystkich elementow, podczas gdy niekoniecznie wszystkie musza istniec od poczatku. Polaczenie jest wlasnie dobrym przykladem, bo zwykle nie trzeba sie laczyc od razu po starcie aplikacji, tylko w momencie wykonania pierwszego zapytania.

Co do przedstawionych rozwiazan (singleton i fabryka/pool manager) wybierz takie, ktore nie bedzie przesadnie skomplikowane. Jezeli laczysz sie z jedna baza i wiecej polaczen mial nie bedziesz to nie ma sensu zatrudniac fabryki tam, gdzie zwykly singleton da rade.

Odradzalbym natomiast przekazywanie obiektu polaczenia jako parametr bo to wymusza przekazywanie go zawsze i wszedzie, oprocz tego ktos musi go zainicjalizowac i zadbac by byl poprawny i musisz sie upewnic, ze zrobisz to na poczatku. Singleton tutaj jest nieco lepszy, bo sam dba o te szczegoly.

0

Więc zdecyduję się na samoinicjalizującego Singletona. Dzięki za wyczerpującą wypowiedź.

1 użytkowników online, w tym zalogowanych: 0, gości: 1