Obiekt + jego narzędzia

Powiedzcie mi czy moje rozważania mają sens i idą dobrą stronę.

Założenia: aplikacja* dodająca osoby

Mam obiekt Person który ma następujące pola

public String name
public String surname

2 konstruktory jeden bezargumentowy, drugi jako argumenty przyjmują imię i nazwisko. Oprócz tego posiada zestaw geterów i seterów.

Aplikacja musi te osoby dodawać więc pierwsza myśl: "dorzucić metodą addPerson do klasy Person". Z drugiej strony od kiedy to osoba sama się dodaje. Niby może się gdzieś zapisać, ale to bez sensu chyba. Więc druga myśl prowadzi mnie do utworzenia klasy PersonTools, która byłaby czymś w rodzaju modelu. Posiadałaby metody takie jak addPerson, deletePerson, editPerson. Byłaby to warstwa komunikująca się z bazą. Nic by nie dziedziczyła bo to de facto nie jest rozszerzenie. Czy może powinna dziedziczyć po klasie Person ?

Idąc dalej jeżeli aplikacja się rozrasta to chyba rozsądnie jest stworzyć interfejs Tools który posiadałby metody, a raczej wymuszał utworzenie metod:
add
delete
edit

na każdej klasie implementującej ten interfejs. Czy to ma ręce i nogi ? Czy gdzieś się pogubiłem ?

*aplikacja - szumnie nazwałem to aplikacją po to żeby mieć na czym wymodelować mój problem

Wiec tak:

Klasa PersonsSet, ktora przechowuje obiekty Klasy Person np w Vectorze. I ona posiada metody add, delete, itp.

Pola nigdy nie powinny byc public. Powinny byc protected (czasami private).

[losowa nazwa] napisał(a)

Wiec tak:

Klasa PersonsSet, ktora przechowuje obiekty Klasy Person np w Vectorze. I ona posiada metody add, delete, itp.

Pola nigdy nie powinny byc public. Powinny byc protected (czasami private).

Mógłbyś trochę rozwinąć myśl ? :) Np. czemu chciałbym trzymać obiekty klasy Person w Vectorze ?

A czy PersonSet powinna implementować np interfejs z tymi metodami ? Jeżeli będzie więcej obiektów wymagających takich operacji to chyba dobrze by mieć taki interfejs żeby to ustandaryzować

Dodam tylko - bo chyba się nie jasno wyraziłem - że przez dodanie, usunięcie, edycją (add, delete, edit) mam na myśli operację np. na bazie danych gdzie będą trzymane jakieś rekordy

Jesli chcesz miec wiecej tego typu klas-zbiorow i chcesz im ujednolicic interfejs, to rzeczywiscie warto stworzyc wspolny interfejs. Aleee... wtedy moze bardziej oplaci sie stworzyc jedna klase UniversalSet<T>, gdzie T jest typem danych, ktory bedzie przechowywany w zbiorze. Np:

UniversalSet<Person> personsSet = new UniversalSet<Person>();
Person p = new Person("Ala", "Makota");
personsSet.add(p);
Person p2 = personsSet.get(0); // np ;p

A czemu wektor ? Bo tak mi przyszlo do glowy ;) Masz do wyboru mnostwo udostepnionych w Javie kolekcji - wektory, mapy, zbiory, etc.

Poczytaj o serializacji oraz Hibernate.

a gdzie w tym wszystkim powłoka komunikująca się z bazą ? Czy jest to właśnie w metodzie np. get klasy UniversalSet ?

Tak, na przyklad tam. Poczytaj o Hibernate - on sluzy do obslugiwania baz danych w "ludzki" sposob.

Jeszcze jakieś opinie ? :)

Entities (tutaj klasa Person) powinny mieć tylko pola (wraz z getterami i setterami) wewnętrzne plus ewentualnie referencje do innych entity w których są w relacji.

Metody jak dodaj, usuń itp itd powinny lądować w DAO. List<Person> czy Set<Person> powinno lądować w środku DAO.

Zamiast Hibernate polecam od razu JPA 2.0, jako że jest niezależne od implementacji pod spodem.

donkey7 napisał(a)

Entities (tutaj klasa Person) powinny mieć tylko pola (wraz z getterami i setterami) wewnętrzne plus ewentualnie referencje do innych entity w których są w relacji.

Metody jak dodaj, usuń itp itd powinny lądować w DAO. List<Person> czy Set<Person> powinno lądować w środku DAO.

Zamiast Hibernate polecam od razu JPA 2.0, jako że jest niezależne od implementacji pod spodem.

Jeżeli dobrze wszystko kumam to tworzę interfejs z podstawowymi metodami add,get,delete (DAO) który będzie implementowany w "obiektach narzędziowych". Te obiekty będą tylko wykorzystywać odpowiednie metody, ale cała mechanika komunikacji z bazą będzie ukryta gdzieś niżej. Dodatkowo żeby metody te były uniwersalne, np. dla obiektów Person, Company, Car, Cokolwiek będą przyjmować jako parametr np. tablicę stringów. Czy dobrze to kminie ?

No i tu też mam problem z dobrym stworzeniem interfejsu. Zakładając, że chcę mieć tam metodę get która coś pobiera. Tylko jak stworzyć taką deklarację metody get abym mógł implementując ten interfejs pobrać np. Customer lub Person. W sensie jak nie zamknąć się w interfejsie na konkretny typ danych a maxymalnie uogólnić go, a dopiero uściślić w odpowiedniej klasie.

Generalnie spotykałem się z czymś takim, że tworzy się szereg DAO (ale nie dla każdej encji). Jeśli chcesz to usystematyzować to zrób np interfejs Identifiable, zawierający jedną metodę getId() zwracającą klucz potrzebny do podstawowych operacji w DAO jak get, delete itp. Entity będzie dziedziczyć po Identifiable, a EntityDAO po jakiejś bazowej klasie korzystającej z Identifiable.

Tablic Strigów się nie stosuje. Zapomnij o JDBC. Przy ORM mapowanie na obiekty jest robione automatycznie (po to jest ORM właśnie). Masz polecenie np: baza.get(klucz, Person.class) zwracające obiekt (np tutaj Person) o danym kluczu.

Zobacz sobie o co biega w JPA 2.0, jakimi sposobami się szuka w bazie, albo wyciąga dane, a potem pomyślisz jak zrobić DAO.