Jak prawidłowo projektować interfejsy ?

No właśnie jak ?

Moje rozumienie interfejsu sprowadza się do tego aby ustandaryzować pewne elementy/funkcjonalności. Na przykład jeżeli mamy obiekty: Client, Person, Car w jakimś tam katalogu to każdy z tych elementów chcemy np. dodać (add), pobrać (get), usunąć(delete). O ile get i delete są proste bo wystarczy podać uid z bazy żeby to wykonać to zastanawia mnie jak radzić sobie z metodami typu add ? No bo przecież każdy z tych obiektów ma inne właściwości.

W jaki sposób należałoby przekazać parametry, aby móc to prawidłowo obsłużyć. najprostsze rozwiązanie - ale wydaje mi się, że równocześnie najgorsze - to tablica String[].

Myśle o jakichś kontenerach, ale jakoś nie widzę tego. Jakie jest Wasze zdanie ?

Zazwyczaj tworzy się pośrednika, który implementuje pewien wspólny interfejs:

interace DAO<? extends Persistable>{
   void add(Persistable p);
   void get(Persistable p);
   void del(Persistable p);
}

//..
class Kot implements Persistable{
  //.. właściwości kota
}
//...
class KotDAO implements DAO<Kot>{
   void add(Kot p);
   void get(Kot p);
   void del(Kot p);
}

Jaśniejsze?

@Kozoiolek: a Ty jak zwykle - troche dobrze, ale wiecej zle. Wez ten Twoj kod tego DAO, sprobuj skompilowac i policz ile bledow moze zrobic 'pro' w 2 linijkach kodu (add, get i del uwazam za jedna linijke, nie licze zamykajacej klamry), i na przyszlosc naprawde postaraj sie pisac sensownie zeby nie mieszac mlodziezy. Dodaj taki pol-blad ktory polega na bezuzytecznosci tego interfejsu poza pakietem w ktorym zostal zdefiniowany.

public interace DAO<P extends Persistable> {
   void add(P p);
   void get(P p);
   void del(P p);
}

P mozna zamienic czymkolwiek, czeste jest np T (od slowa Type), ale musi byc wszedzie to samo oznaczenie. Nie ogranicza sie do jednej literki.
Persitable to jest interfejs ktory unifikuje twoje encje, moze zawierac rowniez jakies wspolne metody, jak np getId() czy podobne.

czym jest Persistable ? mam na myśli ten zapis

public interace DAO<P extends Persistable>

Czyli pierw tworzę interfejs DAO który rozszerza jakiś typ (czy tak ? ), potem klasę któa implementuje ten interfejs (czy nie możesz być to klasa abstrakcyjna skoro te metody i tak są tylko deklaracjami? ) a potem już de facto wykorzystuje to w kodzie

Bo trochę zamieszaliście :D

Ostatnia linijka w moim poprzednim poscie mowi co to jest Persistable. To jest jakis interfejs ktory jest czyms co wszystkie Twoje encje maja wspolnego. Moze byc pusty (tzw. marker interface) albo miec jakies wspolne metody. Np. wszystkie encje beda mialy id, wiec mozesz tam wrzucic metode getID / setID.

public interfce DAO<P extends Persistable> oznacza: tworzysz interfejs DAO ktory jest parametryzowany typem, ktory implementuje / rozszerza typ Persistable. Jak chcesz wiedziec wiecej poczytaj o Java Generics.
Sam interfejs DAO pokazany przez Koziolka jest tez bledny, metoda void get() jest bez sensu - przeciez chcesz zeby cos zwrocila prawda? Nie zauwazylem wtedy tego, skupilem sie na innej bzdurze, powinno byc cos takiego:

public interace DAO<P extends Persistable> {
   void add(P p);
   P get(Long id);
   void del(P p);
}

zakladajac ze Twoje encje beda mialy id typu Long. Zmien wedle widzimisie.

Nastepnie klasy Kot i KotDAO Koziolka sa ok (tylko dodaj public jesli chcesz moc uzywac poza pakietem gdzie sa definiowane, zmien metody na public bo to sie rowniez nie skompiluje, no i zmien metode get na public Kot get(Long id)). Cos w tym stylu. I patrz z razsadkiem na to co tutaj piszemy i sam mysl, bo jak widzisz robimy bledy.

W sumie Persistable moze rowniez byc abstrakcyjna klasa, parentem twoich encji, ktora ma w sobie zaimplementowane np id, oraz inne podstawowe wlasciwosci i metody, jak moze data utworzenia i jej getter (setter powinen byc niedostepny i to pole powinno byc generowane automatycznie - tak mysle), generyczny toString lub equals / hashCode, wedlug potrzeb. W ten sposob bedziesz mial zunifikowane tak samo jak z interfejsem, ale pominiesz jeden poziom - brak dodatkowego interfejsu, ale sa ludzie ktorym sie to nie podoba wiec znowu - Twoje widzimisie / potrzeby projektu sa najwazniejsze.

no i mam problem

package DAO;

public class CompanyDAO implements DAOInterface<Company> {
	public void add(Company company) {
		
	}
	
	public void delete(int uid) {
		
	}
	
	public Company get(int uid) {	
		return new Company();
	}
}

public interface DAOInterface<T extends Persistable> {
	public void add(T t);
	public void delete(int uid);
	public T get(int uid);
}

public interface Persistable {
	public int getId();
}

I zwraca następujące błędy:

• Bound mismatch: The type Company is not a valid substitute for the bounded parameter <T
  extends Persistable> of the type DAOInterface<T>
  • The type CompanyDAO must implement the inherited abstract method
    DAOInterface<Company>.add(Persistable)

Persistable mussiz sobie sam napisać. A implementowanie interfejsu wygląda np tak: class DupaDAO implements OrganDAO<Dupa>.

Wyglada na to ze Company nie implementuje Persistable.

::. napisał(a)

Wyglada na to ze Company nie implementuje Persistable.

Dokładnie o to chodziło.

Chyba zrozumiałem cały ten myk

Mój obiekt Company implementuje interfejs który deklaruje metody identyczne dla wszystkich obiektów lub po prostu pusty czyli ten marker.

Rozszerzam interfejs CompanyDAO który jest interfejsem dla klas narzędziowych (czyli klasa CompanyDAO jest parametryzowana ??? ) o interfejs Persistable. W ten sposób mam ładną warstę modelową do komunikacji z bazą, która jest odcięta od samego obiektu i wszystko jest ustandaryzowane

Jak Company jest taka nadrzedna klasa do wszystkiego co masz w bazie, to uzyj po prostu jej zamiast Persistable.

::. napisał(a)

Jak Company jest taka nadrzedna klasa do wszystkiego co masz w bazie, to uzyj po prostu jej zamiast Persistable.

Nie jest nadrzędna. Będzie wiele podobnych obiektów, które będą w pewien sposób odwzorowywać rekordy w bazie. No, ale temat zamknięty. Dzięki wszystkim za pomoc :)

no i znowu mam z tym problem - a może go po prostu wczesniej nie zauważyłem :/

package core;

import DAO.Persistable;;

public class Company implements Persistable {
	private String shortName;
	private String fullName;
	private int id;
	public Company() {}
	
	public Company(String shortName, String fullName) {
		this.shortName = shortName;
		this.fullName = fullName;
	}

	public String getShortName() {
		return shortName;
	}

	public void setShortName(String shortName) {
		this.shortName = shortName;
	}

	public String getFullName() {
		return fullName;
	}

	public void setFullName(String fullName) {
		this.fullName = fullName;
	}
	
	public int getId() {
		return this.getId();
	}
	
	public void setId(int id) {
		this.id = id;
	}
	
	public String toString() {
		return "Firma: " + shortName + " - " + fullName + "\n";
	}
}

package DAO;

public interface Persistable {
public int getId();
public void setId(int id);
}

package DAO;

public interface DAOInterface<T extends Persistable> {
public void add(Persistable T);
public void delete(int uid);
public Persistable get(int uid);
}

package DAO;

import core.Company;

public class CompanyDAO implements DAOInterface<Company> {
public void add(Company company) {
System.out.println("Podane dane to: " + company.getShortName() + " | " + company.getFullName());
}

public void delete(int uid) {
	
}

public Company get(int uid) {	
	return new Company();
}

}

No i w CompanyDAO zwraca mi następujący błąd


> The type CompanyDAO must implement the inherited abstract method DAOInterface<Company>.add
>  (Persistable)
> 

Zaczynam się gubić. Przecież Company implementuje Persistable więc dlaczego nie mogę dać add(Company)

No bo zrobiles jak mowil Koziolek, zmien DAOInterface zeby nie bylo tam Persistable tylko T, z wyjatkiem T extends Persistable - to ma zostac. Innymi slowy, add ma wygladac void add(T t); a get T get(id).

hmm...ja akurat w tym temacie jestem zielony, ale wiem że prędzej czy później w pracy spotkam się z tymi zagadnieniami więc chce uprzedzić zdarzenia i zadam pytanie:

Gdzie szukać przystępnych materiałów na temat EE? Chodzi mi o całościowe objęcie tematu-jak się ma np taki interfejs DAO do wzorców projektowych i co ma do tego np. SPring? Chodzi mi o takie lajtowe przyswojenie tych zagadnień jednocześnie nie wchodząc za głęboko w żadną z w/w technologi.

Pozdrawiam

Nie bagatelizujcie mnie:) Na dzień dzisiejszy programuje wiele różnych fajnych rzeczy związanych ze sprzętem i integracją z systemem i to wszystko w Javie-po prostu chce poszerzyć horyzonty....dajcie mi jakieś wytyczne

pozdrawiam

::. napisał(a)

No bo zrobiles jak mowil Koziolek, zmien DAOInterface zeby nie bylo tam Persistable tylko T, z wyjatkiem T extends Persistable - to ma zostac. Innymi slowy, add ma wygladac void add(T t); a get T get(id).

No cóż najlepiej się uczyć na błędach :)

Teraz będę wiedział już jak parametryzować takie rzeczy. Jeszcze raz dzięki wielkie za pomoc

Klucz jest chyba tworzony przez bazę i nie powinno być czegoś takiego jak setId.

@donki7, a jak ORM ma ustawić ID?

Generalnie ORM dokonuje refleksji na encjach i szuka odpowiednich adnotacji. Chodziło mi bardziej o to, że setId jest niepotrzebne w interfejsie Persistable.

http://wicketinaction.com/2008/09/building-a-smart-entitymodel/

To juz jest kwestia projektu i potrzeb. Bralem udzial w projektach ktory gaktycznie zostawial kwestie generacji kluczy dla bazy (rozne strategie: sekwencja, identity, ale najczesciej table bo przenosne), ale i bralem udzial w projekcie ktory sam to ustawial. Ot, dokonali wyboru.