Interfejsy w java
mateusz hyski
Dziedziczenie itd jest ok, ale poszukuje jakiegos wytlumaczenia, ktore
pokaze mi, ze to jest sensowne ( jak dziedziczenie).
PS. Do orłów - prosze bez smiechów, też zaczynaliscie.
Łukasz Lenart
<hyski....@gmail.com> napisał:
> Czesc. moze i glupie ale nie moge zrozumiec zastosowania interfejsow.
> Dziedziczenie itd jest ok, ale poszukuje jakiegos wytlumaczenia, ktore
> pokaze mi, ze to jest sensowne ( jak dziedziczenie).
Zobacz na interfejs List i jego implementację, możesz mieć zmienną
typu List ale użyć różnych implementacji w zależności od potrzeb -
ArrayList, LinkedList, etc
Pozdrawiam
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/
ags
--
In order to post a job offer or any other advertisement please contact us at in...@java.pl
Aby publikować na grupie "Polish Java User Group", wyślij wiadomość e-mail na adres
polish-java...@googlegroups.com
By wypisać się z grupy wyślij e-mail do
polish-java-user-...@googlegroups.com
Więcej opcji na stronie grupy
http://groups.google.com/group/polish-java-user-group?hl=pl?hl=pl
Konrad Malawski
--
Pozdrawiam,
Konrad Malawski
java.pl - Polish Java User Group
llp.pl - Lunar Logic Polska
blog.project13.pl - Private Blog
Rafał Skowron
Antoni Mylka
Wielokrotne dziedziczenie klas powoduje tzw. "problem kraty" i sprzyja
tworzeniu skomplikowanych designów. Dlatego w Javie jest jednokrotne
dziedziczenie klas.
Ale, wielodziedziczenie czasem się przydaje i jest prostsze, jak
dziedziczysz tylko interfejs bez implementacji. Dlatego w Javie można
"implementować" wiele interfejsów.
Czyli jak mam klasę, i chcę ją zapodać gdzieś gdzie wymagają jakiegoś
kontraktu XXX to mogę:
1. dodać "implements XXX" i zaimplementować potrzebne metody
2. dodać metodę getXXX, a w niej return new XXX() {} i potrzebne
metody zaimplementować w anonimowej klasie wewnętrznej. (Adapter)
3. Można też do wszystkiego robić takie adaptery jako osobne klasy
"top-level", ale wtedy często prowadzi to do zaciemniania, no i nie
bardzo się da zrobić bez wielodziedziczenia. (Np. Adapter Pattern w GOF
z tego co pamiętam jest pokazany jako klasa dziedzicząca z dwóch:
źródłowej i docelowej w C++).
Jakby nie było interfejsów, to mielibyśmy tylko rozwiązanie nr 3, bo
anonimowe klasy wewnętrzne też by straciły sens. Jakby były interfejsy,
ale bez wielodziedziczenia to mielibyśmy tylko 2 i 3. Tak mamy 1,2 i 3.
Antoni
Adrian Nowak
Czesciej niz tworzyc wlasne interfejsy (na poczatku, albo dosc dlugo bo ja juz nie pamietam) bedziesz korzystal z juz istniejacych i tym sposobem pozyskiwal dostep do wielu funkcjonalnosci jakie juz oferuja biblioteki Java.
Zastosowanie interfejsu (czyli implements przez klase definiujaca obiekt) moze rozumiec jako okreslenie przynaleznosc do obiektow posiadajacych pewne cechy, z ktorych to prawdopodobnie bedzie korzystaďż˝ dalej nasz lub obcy kod (wyobrazajac sobie ze implementacja tych cech jest poprawna i zgodna z przewidywaniami). Niekiedy okreslenie interfejsu jest tylko znacznikiem (interfejs jest pusty = nie ma metod do implementacji)ďż˝ co pozwala traktowac obiekty roznego typu jednakowo (przez juz zaimplementowane w bibliotekach funkcjonalnosci) np. Serializable.
Obiekty klas ktore implementuja jakis interfejs mozemy swobodnie przekazywac tam gdzie sďż˝ one oczekiwane (metody w bibliotekach Java beda pobierac np. List zeby moc posortowac cokolwiek) .W druga strone my (nasze metody) oczekujac zachowania np. listy (czyli glownie pozyskiwania kolejnego elementu metoda next()) nie musimy znac dokladnego typu obiektu (tablica, lista, cokolwie) zeby moc wyciagac kolejne elementy. Aby np. sortowac wystarczy ze (nasz) klasa implementuje interfejs Comperable czyli definiuj jego 1, jak dobrze pamietam, metode. Najlepiej przyjrzec sie jak to zrobiono w kolekcjach danych Javy...ďż˝ polecam odpowedzni rozdzial Thinking in Java (darmowe w sieci, chocby nawet stare wydanie 2) - przyklady z kolekcjami, sortowanie itd. powinny b.wiele wyjasnic...
o masz tu podobnyďż˝ przyklad (btw. chyba ciekawy blog sie znalazl): http://kodatnik.blogspot.com/2010/01/porownujemy-obiekty-interfejs.html
Oczywiscie zamiast uzywac Comparable we wlasnej klasie Student mozna meczyc sie jakimis wlasnymi sposobami bez wykorzystania dostepnych bibliotek zeby dostac ten sam efekt, ale nie o to chodzi :)
Pozdrawiam,
Adrian
-- GeeCON conference, http://geecon.org Polish JUG, http://www.java.pl Twitter: @geecon, @polishjug, @adrno
GeeCON conference, http://geecon.org Polish JUG, http://www.java.pl Twitter: @geecon, @polishjug, @adrno mobile: 0048 508 078 861
W dniu 2011-12-07 16:27, Rafaďż˝ Skowron pisze:
My�l�,�
�� @Konrad Malawski��� wyja�ni� jasno :)
2011/12/7 Konrad Malawski <konrad....@java.pl>
Mo�e kojarzysz przyk�ad jak si� uczy czasami ludzi o dziedziczeniu (failowo do�� si� to pokazuje).
Klasyczny przyk�ad z dziedziczeniem zwierz�tek po sobie etc, ma pewien problem, bo masz Zwierze -> Kot.Zrobisz sobie nagle �e Kot chodzi a potem uznasz �e w sumie wszystkie zwierz�ta chodz�. Nast�pnie przychodzi Ryba...Ryba to te� zwierzak, no to dziedziczysz - ZONK! No bo Ryba nie chodzi a zwierz�ciem jest... Wi�c chodzenie nagle nie jest wsp�lne...
Ten przyk�ad na interfejsach by si� zrobi�o poprzez interfejs np. Chodz�cyZwierzak, P�ywaj�cyZwierzak oraz Zwierzak etc.�Api jest wsp�lne dla wszystkich zwierzak�w, powiedzmy �e isAlive() czy co�. Ale inne rzeczy s� specyficzne dla innych grup - dzi�ki interfejsom mo�esz to sobie pogrupowa� i mie�metody pracuj�ce na Zwierz�Morskie etc etc...
Takie tam - przyk�ad listy te� jest dobry.
--ďż˝
Pozdrawiam,
Konrad Malawski
java.plďż˝- Polish Java User Group
blog.project13.plďż˝- Private Blog
W dniu 7 grudnia 2011 16:09 u�ytkownik mateusz hyski <hyski....@gmail.com> napisa�:
Czesc. moze i glupie ale nie moge zrozumiec zastosowania interfejsow.
Dziedziczenie itd jest ok, ale poszukuje jakiegos wytlumaczenia, ktore
pokaze mi, ze to jest sensowne ( jak dziedziczenie).
PS. Do or��w - prosze bez smiech�w, te� zaczynaliscie.
--
In order to post a job offer or any other advertisement please contact us at in...@java.pl
Aby publikowa� na grupie "Polish Java User Group", wy�lij wiadomo�� e-mail na adres
polish-java...@googlegroups.com
By wypisa� si� z grupy wy�lij e-mail do
polish-java-user-...@googlegroups.com
Wi�cej opcji na stronie grupy
http://groups.google.com/group/polish-java-user-group?hl=pl?hl=pl
Aby publikowaďż˝ na grupie „Polish Java User Group”, wyďż˝lij wiadomo�� e-mail na adres
polish-java...@googlegroups.com
By wypisa� si� z grupy wy�lij e-mail do
polish-java-user-...@googlegroups.com
Wi�cej opcji na stronie grupy
http://groups.google.com/group/polish-java-user-group?hl=pl?hl=pl
--
rs
--
In order to post a job offer or any other advertisement please contact us at in...@java.pl
Aby publikowaďż˝ na grupie „Polish Java User Group”, wyďż˝lij wiadomo�� e-mail na adres
polish-java...@googlegroups.com
By wypisa� si� z grupy wy�lij e-mail do
polish-java-user-...@googlegroups.com
Wi�cej opcji na stronie grupy
http://groups.google.com/group/polish-java-user-group?hl=pl?hl=pl
Sławek Sobótka
Bo sęk właśnie w tym, że rzadko kiedy ma ono sens w modelowaniu:P
Rzadko nie w sensie częstości stosowania a w sensie specyficznego
kontekstu.
Naprowadzi Cię Liskov Substitution Principle - w skrócie: dziedziczysz
gdy będziesz używał polimorfizmu a nie po to aby sobie wyciągnąć
kodzik "przed nawias"
Kiedy wyprostujemy dziedziczenie, to interfejsy same się wyjaśnią:)
Andrzej pisał o kontraktach - idź dokładnie w stronę tej metafory...
tak jak USB czy HDMI definiuje kontrakt napięć po obu stronach nie
wnikając co jest po obu stronach.
@Konrad: z tymi zwierzątkami nie jest tak łatwo:P
Z tego co rozumiem to i tak kod kliencki musi mieć wiedzę o tym z kim
ma do czynienia i rzutować aby mieć dostęp do kontraktu...
Bardziej eleganckie formy:
- Extension Object Pattern - na nim stoi Eclipse
- Role Object Pattern - bardziej w modelach biznesowych
Sławek Sobótka
http://art-of-software.blogspot.com/
http://ssepp.pl
l.kuczera
namiastkę wielodziedziczenia, które było źle zrobione w C++ ale za to
dużo lepiej już wypada w Scali. Zasadniczo dzielisz sobie swoją
dziedzinę problemu i jego rozwiązanie na małe kawałki i możesz z tych
kawałków budować jakieś większe (jedynie określając ich abstrakcyjne
API). Następnie możesz implementować różne interfejsy razem po kilka w
klasach lub pojedyńczo jak Ci wygodnie. Klasyczny przykład to tak
zwane mocki czy stuby, gdzie masz prawdziwą implementację jakiejś
usługi a do testów używasz włąsną przygotowaną która nie powoduje
skutków ubocznych. No i wszystko byłoby ładnie tylko niestety nie da
się już tak na kawałki podzielić implementacji w javie (brak
wielodziedziczenia) dlatego interfejsy w Javie częsti są ogromne
(List, Map etc.)
Inny przykład zastosowania to definiowanie "czystego" API, klasy mogą
mieć prywatne metody, które po wydziedziczeniu mogą bruździć w
działaniu klasy. Dodatkowo mamy pewność że nagle implementacja nie
zostanie gdzieś zmieniona bez naszej wiedzy i nie zmieni działania
naszej aplikacji.
Polecam wzorzec strategi sobie poczytać jak równiesz resztę wzorców
GoF.
On Dec 7, 8:47 pm, Adrian Nowak <adrian.no...@java.pl> wrote:
> A ja bym kombinowal tak (dalej tropem Lukasza):
>
> Czesciej niz tworzyc wlasne interfejsy (na poczatku, albo dosc dlugo bo
> ja juz nie pamietam) bedziesz korzystal z juz istniejacych i tym
> sposobem pozyskiwal dostep do wielu funkcjonalnosci jakie juz oferuja
> biblioteki Java.
>
> Zastosowanie interfejsu (czyli implements przez klase definiujaca
> obiekt) moze rozumiec jako okreslenie przynaleznosc do obiektow
> posiadajacych pewne cechy, z ktorych to prawdopodobnie bedzie korzystaďż˝
> dalej nasz lub obcy kod (wyobrazajac sobie ze implementacja tych cech
> jest poprawna i zgodna z przewidywaniami). Niekiedy okreslenie
> interfejsu jest tylko znacznikiem (interfejs jest pusty = nie ma metod
> do implementacji) co pozwala traktowac obiekty roznego typu jednakowo
> (przez juz zaimplementowane w bibliotekach funkcjonalnosci) np.
> Serializable.
>
> Obiekty klas ktore implementuja jakis interfejs mozemy swobodnie
> przekazywac tam gdzie sďż˝ one oczekiwane (metody w bibliotekach Java beda
> pobierac np. List zeby moc posortowac cokolwiek) .W druga strone my
> (nasze metody) oczekujac zachowania np. listy (czyli glownie
> pozyskiwania kolejnego elementu metoda next()) nie musimy znac
> dokladnego typu obiektu (tablica, lista, cokolwie) zeby moc wyciagac
> kolejne elementy. Aby np. sortowac wystarczy ze (nasz) klasa
> implementuje interfejs Comperable czyli definiuj jego 1, jak dobrze
> pamietam, metode. Najlepiej przyjrzec sie jak to zrobiono w kolekcjach
> danych Javy... polecam odpowedzni rozdzial Thinking in Java (darmowe w
> sieci, chocby nawet stare wydanie 2) - przyklady z kolekcjami,
> sortowanie itd. powinny b.wiele wyjasnic...
>
> o masz tu podobny przyklad (btw. chyba ciekawy blog sie znalazl):http://kodatnik.blogspot.com/2010/01/porownujemy-obiekty-interfejs.html
> Oczywiscie zamiast uzywac Comparable we wlasnej klasie Student mozna
> meczyc sie jakimis wlasnymi sposobami bez wykorzystania dostepnych
> bibliotek zeby dostac ten sam efekt, ale nie o to chodzi :)
>
> Pozdrawiam,
> Adrian
>
> --
> GeeCON conference,http://geecon.org
> Polish JUG,http://www.java.pl
> Twitter: @geecon, @polishjug, @adrno
>
> GeeCON conference,http://geecon.org
> Polish JUG,http://www.java.pl
> Twitter: @geecon, @polishjug, @adrno
> mobile: 0048 508 078 861
>
> W dniu 2011-12-07 16:27, Rafaďż˝ Skowron pisze:
>
>
>
>
>
>
>
> > My�l�,
> > �� @Konrad Malawski wyja�ni� jasno :)
>
> > 2011/12/7 Konrad Malawski <konrad.malaw...@java.pl
> > <mailto:konrad.malaw...@java.pl>>
>
> > Mo�e kojarzysz przyk�ad jak si� uczy czasami ludzi o dziedziczeniu
> > (failowo do�� si� to pokazuje).
>
> > Klasyczny przyk�ad z dziedziczeniem zwierz�tek po sobie etc, ma
> > pewien problem, bo masz Zwierze -> Kot.
> > Zrobisz sobie nagle �e Kot chodzi a potem uznasz �e w sumie
> > wszystkie zwierz�ta chodz�. Nast�pnie przychodzi Ryba...
> > Ryba to teďż˝ zwierzak, no to dziedziczysz - ZONK! No bo Ryba nie
> > chodzi a zwierz�ciem jest... Wi�c chodzenie nagle nie jest wsp�lne...
>
> > Ten przyk�ad na interfejsach by si� zrobi�o poprzez interfejs np.
> > Chodz�cyZwierzak, P�ywaj�cyZwierzak oraz Zwierzak etc.
> > Api jest wsp�lne dla wszystkich zwierzak�w, powiedzmy �e isAlive()
> > czy co�. Ale inne rzeczy s� specyficzne dla innych grup - dzi�ki
> > interfejsom mo�esz to sobie pogrupowa� i mie�
> > metody pracuj�ce na Zwierz�Morskie etc etc...
>
> > Takie tam - przyk�ad listy te� jest dobry.
> > --
> > Pozdrawiam,
> > Konrad Malawski
> > java.pl <http://java.pl> - Polish Java User Group
> > llp.pl <http://llp.pl> - Lunar Logic Polska
> > blog.project13.pl <http://blog.project13.pl> - Private Blog
>
> > W dniu 7 grudnia 2011 16:09 u�ytkownik mateusz hyski
> > <hyski.mate...@gmail.com <mailto:hyski.mate...@gmail.com>> napisaďż˝:
>
> > Czesc. moze i glupie ale nie moge zrozumiec zastosowania
> > interfejsow.
>
> > Dziedziczenie itd jest ok, ale poszukuje jakiegos
> > wytlumaczenia, ktore
> > pokaze mi, ze to jest sensowne ( jak dziedziczenie).
> > PS. Do or��w - prosze bez smiech�w, te� zaczynaliscie.
>
> > --
> > In order to post a job offer or any other advertisement please
> > contact us at i...@java.pl <mailto:i...@java.pl>
> > Aby publikowa� na grupie "Polish Java User Group", wy�lij
> > wiadomo�� e-mail na adres
> > polish-java...@googlegroups.com
> > <mailto:polish-java...@googlegroups.com>
> > By wypisa� si� z grupy wy�lij e-mail do
> > polish-java-user-...@googlegroups.com
> > <mailto:polish-java-user-group%2Bunsu...@googlegroups.com>
> > Wi�cej opcji na stronie grupy
> > http://groups.google.com/group/polish-java-user-group?hl=pl?hl=pl
>
> > --
> > In order to post a job offer or any other advertisement please
> > contact us at i...@java.pl <mailto:i...@java.pl>
> > Aby publikowa� na grupie "Polish Java User Group", wy�lij
> > wiadomo�� e-mail na adres
> > polish-java...@googlegroups.com
> > <mailto:polish-java...@googlegroups.com>
> > By wypisa� si� z grupy wy�lij e-mail do
> > polish-java-user-...@googlegroups.com
> > <mailto:polish-java-user-group%2Bunsu...@googlegroups.com>
> > Wi�cej opcji na stronie grupy
> > http://groups.google.com/group/polish-java-user-group?hl=pl?hl=pl
>
> > --
> > rs
>
> > --
> > In order to post a job offer or any other advertisement please contact
> > us at i...@java.pl
Michal Orman
zwierz�tkami), ale wiedzia�em, �e mnie nie zawiedziesz :D
Interfejs to kontrakt, a nie zast�pstwo wielodziedziczenia. Trzeba tak�e
pami�ta�, �e interfejsem nie jest tylko to co jest oznaczone s�owem
kluczowym interface, ka�da klasa te� jest interfejsem i powinna mie�
dobrze okre�lony kontrakt (kt�ry powinien by� spe�niany tak�e przez jej
podklasy - patrz wspomniany Liskov Substitution Principle). Interfejsy
przydaj� si� tam, gdzie potrzebujesz wymienia� implementacje (zachowuj�c
kontrakt).
Interfejsy znaczniki wystarczy wiedzieďż˝ co to jest, ale niech nikomu nie
przyjdzie do g�owy tworzenie tego samemu ;).
On 07.12.2011 23:53, S�awek Sob�tka wrote:
> Opisz w kilku zdaniach jak rozumiesz "sensowne" dziedziczenie.
> Bo s�k w�a�nie w tym, �e rzadko kiedy ma ono sens w modelowaniu:P
> Rzadko nie w sensie cz�sto�ci stosowania a w sensie specyficznego
> kontekstu.
> Naprowadzi Ci� Liskov Substitution Principle - w skr�cie: dziedziczysz
> gdy b�dziesz u�ywa� polimorfizmu a nie po to aby sobie wyci�gn��
> kodzik "przed nawias"
>
> Kiedy wyprostujemy dziedziczenie, to interfejsy same si� wyja�ni�:)
>
> Andrzej pisa� o kontraktach - id� dok�adnie w stron� tej metafory...
> tak jak USB czy HDMI definiuje kontrakt napi�� po obu stronach nie
> wnikaj�c co jest po obu stronach.
>
> @Konrad: z tymi zwierz�tkami nie jest tak �atwo:P
> Z tego co rozumiem to i tak kod kliencki musi mieďż˝ wiedzďż˝ o tym z kim
> ma do czynienia i rzutowa� aby mie� dost�p do kontraktu...
> Bardziej eleganckie formy:
> - Extension Object Pattern - na nim stoi Eclipse
> - Role Object Pattern - bardziej w modelach biznesowych
>
>
> S�awek Sob�tka
> http://art-of-software.blogspot.com/
> http://ssepp.pl
>
Łukasz Lenart
<michal...@gmail.com> napisał:
> Interfejsy znaczniki wystarczy wiedzieć co to jest, ale niech nikomu nie
> przyjdzie do głowy tworzenie tego samemu ;).
Dlaczego ?
Michal Orman
> W dniu 8 grudnia 2011 09:40 u�ytkownik Michal Orman
> <michal...@gmail.com> napisaďż˝:
>> Interfejsy znaczniki wystarczy wiedzieďż˝ co to jest, ale niech nikomu nie
>> przyjdzie do g�owy tworzenie tego samemu ;).
> Dlaczego ?
>
>
> Pozdrawiam
A jakiego konktraktu spodziewasz po pustym interfejsie? IMO je�eli
takiego interfejsu nie da si� zast�pi� adnotacj�, to prawdopodobnie
modelujesz co� �le. Ani tego nie u�yjesz w spos�b polimorficzny, ani
specjalnie podmiana implementacji takiego interfejsu nic nie daje. Mo�e
jeszcze za pomoc� refleksji b�dziesz szuka� magicznych metod w
implementacji (tak jak to jest przy serializacji)? Je�eli potrzebujesz
takiego markera to jeszcze raz, a potem drugi przemy�l sw�j model i
zastan�w si�, czy na pewno potrzebujesz tego markera ;)
Szymon Jachim
Haha, miałem dokładnie o tym napisać (a'propos tego przykładu z tymi zwierzątkami), ale wiedziałem, że mnie nie zawiedziesz :D
Interfejs to kontrakt, a nie zastępstwo wielodziedziczenia. Trzeba także pamiętać, że interfejsem nie jest tylko to co jest oznaczone słowem kluczowym interface, każda klasa też jest interfejsem i powinna mieć dobrze określony kontrakt (który powinien być spełniany także przez jej podklasy - patrz wspomniany Liskov Substitution Principle). Interfejsy przydają się tam, gdzie potrzebujesz wymieniać implementacje (zachowując kontrakt).
Interfejsy znaczniki wystarczy wiedzieć co to jest, ale niech nikomu nie przyjdzie do głowy tworzenie tego samemu ;).
On 07.12.2011 23:53, Sławek Sobótka wrote:
Opisz w kilku zdaniach jak rozumiesz "sensowne" dziedziczenie.
Bo sęk właśnie w tym, że rzadko kiedy ma ono sens w modelowaniu:P
Rzadko nie w sensie częstości stosowania a w sensie specyficznego
kontekstu.
Naprowadzi Cię Liskov Substitution Principle - w skrócie: dziedziczysz
gdy będziesz używał polimorfizmu a nie po to aby sobie wyciągnąć
kodzik "przed nawias"
Kiedy wyprostujemy dziedziczenie, to interfejsy same się wyjaśnią:)
Andrzej pisał o kontraktach - idź dokładnie w stronę tej metafory...
tak jak USB czy HDMI definiuje kontrakt napięć po obu stronach nie
wnikając co jest po obu stronach.
@Konrad: z tymi zwierzątkami nie jest tak łatwo:P
Z tego co rozumiem to i tak kod kliencki musi mieć wiedzę o tym z kim
ma do czynienia i rzutować aby mieć dostęp do kontraktu...
Bardziej eleganckie formy:
- Extension Object Pattern - na nim stoi Eclipse
- Role Object Pattern - bardziej w modelach biznesowych
Sławek Sobótka
http://art-of-software.blogspot.com/
http://ssepp.pl
Aby publikować na grupie "Polish Java User Group", wyślij wiadomość e-mail na adres
By wypisać się z grupy wyślij e-mail do
polish-java-user-group+unsub...@googlegroups.com
Więcej opcji na stronie grupy
http://groups.google.com/group/polish-java-user-group?hl=pl?hl=pl
Łukasz Lenart
<michal...@gmail.com> napisał:
> A jakiego konktraktu spodziewasz po pustym interfejsie? IMO jeżeli takiego
> interfejsu nie da się zastąpić adnotacją, to prawdopodobnie modelujesz coś
> źle. Ani tego nie użyjesz w sposób polimorficzny, ani specjalnie podmiana
> implementacji takiego interfejsu nic nie daje. Może jeszcze za pomocą
> refleksji będziesz szukał magicznych metod w implementacji (tak jak to jest
> przy serializacji)? Jeżeli potrzebujesz takiego markera to jeszcze raz, a
> potem drugi przemyśl swój model i zastanów się, czy na pewno potrzebujesz
> tego markera ;)
A jak nie modeluję tylko buduję framework ? Co do przemyślenia to masz
rację, ale nie stawiałbym tak rygorystycznie, żeby nie tworzyć ich
samemu.
Michal Orman
> W dniu 8 grudnia 2011 09:56 u�ytkownik Michal Orman
> <michal...@gmail.com> napisaďż˝:
>> A jakiego konktraktu spodziewasz po pustym interfejsie? IMO je�eli takiego
>> interfejsu nie da si� zast�pi� adnotacj�, to prawdopodobnie modelujesz co�
>> implementacji takiego interfejsu nic nie daje. Mo�e jeszcze za pomoc�
>> przy serializacji)? Je�eli potrzebujesz takiego markera to jeszcze raz, a
>> potem drugi przemy�l sw�j model i zastan�w si�, czy na pewno potrzebujesz
>> tego markera ;)
> A jak nie modeluj� tylko buduj� framework ? Co do przemy�lenia to masz
> racj�, ale nie stawia�bym tak rygorystycznie, �eby nie tworzy� ich
> samemu.
>
>
> Pozdrawiam
Jak budujesz framework, to do tego typu oznaczania masz adnotacje.
Radosław Szmit
W dniu 7 grudnia 2011 23:53 użytkownik Sławek Sobótka <sso...@gmail.com> napisał:
@Konrad: z tymi zwierzątkami nie jest tak łatwo:P
Zawsze mi się wydawało, że zwierzątka są przykładem antypaternu dziedziczenia i przy takiej ilości cech i możliwości to raczej trzeba iść w "strategie" lub nawet w jakiś model adaptacyjny.
--
Pozdrawiam serdecznie
Radosław Szmit
Łukasz Lenart
<michal...@gmail.com> napisał:
> Jak budujesz framework, to do tego typu oznaczania masz adnotacje.
Oczywiście, że tak ale to nie oznacza, że dla pewnych przypadków
interfejs będzie gorszy. Po prostu trzeba przemyśleć każde rozwiązanie
a nie odrzucać z góry dane podejście, bo jakaś święta krowa tak
powiedziała ;-)
Kazimierz Pogoda
starożytności. Arystoteles np. próbował definiować adekwatnie wszystko
co go otaczało. W związku z tym rozwijał nie tylko wiedzę
encyklopedyczną, ale przede wszystkim teorię definiowania.
* Klasy, zgodnie z etymologią, nadają się do wszelkich klasyfikacji,
gdzie definiując jeden byt określamy wszystkie cechy odróżniające go
od rodzaju (genus) z którego pochodzi - motocykl to pojazd silnikowy
jednośladowy - dziedziczymy więc z EnginePoweredVehicle i dodajemy
wszystkie cechy konstytuujące motocykl - koło przednie, koło tylne,
etc., czyli określamy differentia specifica.
* Interfejsy nadają się natomiast do kategoryzacji - definiowania
kategorii, czyli z grubsza predykacji. Powiedzmy że zdefiniujemy
kategorię Movable - podpadnie pod nią zarówno Vehicle, jak i
EnginePoweredVehicle, jak i Motorcycle, jak i OfficeChair.
'Marker interfaces' jak najbardziej mają sens - w końcu:
"x instaceof Movable" jest bardzo sensownym predykatem - czy x podpada
pod kategorię poruszalności.
Dziedziczenie wielobazowe najczęściej rozwiązuje problem techniczny -
agregację własności. Interfejsy odpowiednio stosowane (Closeable i
AutoCloseable z JRE, HasValue z GWT, etc.) są super o tyle, że
rozwiązują zupełnie inny problem teoretyczny - problem kategoryzacji,
a nie klasyfikacji.
Jeśli myślimy bardzo abstrakcyjnie, to jesteśmy w stanie rozważać
rzeczywistość w terminach kategorii, a nie klas bytów. To ma szereg
zalet, choć najczęściej do takiej abstrakcji projekty dochodzą z
czasem. Kiedyś Gosling bodaj powiedział żartem, że gdyby miał zacząć
jeszcze raz z Javą, to wszystko byłoby interfejsem. ;)
2011/12/7 mateusz hyski <hyski....@gmail.com>:
> --
> In order to post a job offer or any other advertisement please contact us at in...@java.pl
> Aby publikować na grupie "Polish Java User Group", wyślij wiadomość e-mail na adres
> polish-java...@googlegroups.com
> By wypisać się z grupy wyślij e-mail do
> polish-java-user-...@googlegroups.com
> Więcej opcji na stronie grupy
> http://groups.google.com/group/polish-java-user-group?hl=pl?hl=pl
--
Kazik 'morisil' Pogoda
http://memy.xemantic.com/
http://blog.xemantic.com/
Sławek Sobótka
> na swoim wykładzie o Software Craftsmanship, dobrze pamiętam? :D
>
> Zawsze mi się wydawało, że zwierzątka są przykładem antypaternu
> dziedziczenia i przy takiej ilości cech i możliwości to raczej trzeba iść w
> "strategie" lub nawet w jakiś model adaptacyjny.
Tak, przykład, który tam podałem zakładał, że w
"interfejsie" (technicznie konkretna klasa, bo nie potrzeba
abstrakcji) zwierzęcia mamy wszelkie jego umiejętności, takie jak
poruszanie i odżywianie.
Problem polega na tym, że każdy gatunek robi to inaczej, chociaż
niektóre gatunki poruszają się tak samo.
W proponowanym rozwiązaniu zwierzę deleguje poruszanie i odżywianie do
wewnętrznych strategii. Czyli zwierze składa się z wykonawców, a samo
przykrywa ich istnienie swym "interfejsem".
I tutaj na poziomie konkretnej strategii mogę sobie wprowadzać
dziedziczenie (zgodnie z LSP) po to aby np pewne strategie dekorować
lub szablonować.
Natomiast podejście, które proponuje Konrad lub Kazimierz mamy do
czynienia z innym modelem:
otóż zwierze miało by bardzo podstawowy interfejs (np. aktualna tem.
ciała) plus ew. mogłoby "grać" pewne role: umiemBiegać, umiemPływać.
Dodatkowo nie wiadomo jak dokładnie pływa, bo są różne rodzaje
pływania.
To już zupełnie inna klasa problemu. W nowszych językach możemy użyć
mixinow czy traitów, a w Javie mamy
Extension Object (na nim stoi Eclipse)
http://techjude.blogspot.com/2007/07/extension-object-pattern-eclipse.html
http://www.design-nation.net/en/archives/000489.php
Role Object (specjalne zastosowanie Extension)
http://hillside.net/plop/plop97/Proceedings/riehle.pdf
Można na siłę mówić, że jest to jakiś sposób na wielodziedziczenie.
Ale nie mieszałby bym tutaj (i w ogóle do interfejsów) pojęcia
dziedziczenia (bo niepotrzebnie focusuje umysł tą etykietą i ogranicza
myślenie) a raczej wprowadził nowe pojęcie: role.