Dziedziczenie @Controller w Spring

[Piotr Buczak]

Witam

Probuje sprawic, ze jeden Controller dziedziczy od drugiego: Controller_B extends Controller_A.

Wszystko dziala poprawnie, ale problem w tym, ze Spring duplikuje wszystkie sciezki URL z Controller_A na Controller_B.

Przyklad:

@Controller
public class Controller_A
{
@RequestMapping(value = "/foo")   
    public void foo(){}
}


@Controller.
@RequestMapping(value = "/bar")   
public class Controller_B extends Controller_A
{
@RequestMapping(value = "/test")   
    public void bar(){}
}

INFO: Mapped URL path [/foo/.*] onto handler 'Controller_A'
INFO: Mapped URL path [/bar/test.*] onto handler 'Controller_B'
INFO: Mapped URL path [/bar/foo.*] onto handler 'Controller_B' <-- Dlaczego?

Czy mozna sprawic, ze sciezki URL nie beda dziedziczone w Controller_B?

Pozdrawiam,
Piotr

[Sławek Sobótka]

To ja może podejdę do problemu od strony: "problem nie istnieje":

Czy pomiędzy kontrolerem A oraz B zachodzi relacja "is a"?
Czy dziedziczenie jest zgodne z zasadą podstawienia Liskov?

Domyślam się, że raczej nie (nie znam kontekstu, ale dla kontrolerów
zwykle tak bywa), zatem dziedziczenie jest błędem w designie klas.
Typowy błąd polega na jego zastosowaniu do "wyciągnięcia przed nawias"
kodu. Do tego służy agregacja, dziedziczenie natomiast służy do
wspomagania polimorfizmu.

Tak więc gdyby usunąć dziedziczenie z designu klas to możemy dać
spokój Springowi...
...odpowiedź pewnie nie jest satysfakcjonująca:P

z poważaniem
Sławek Sobótka
http://art-of-software.blogspot.com/
http://ssepp.pl

[Piotr Buczak]

Odpowiedz jest jak najbardziej satysfakcjonujaca. Sprowokowala do glebszej refleksji nad polimorfizem i nad tym, ze problem faktycznie nie istnieje. Dziekuje :)

2011/12/15 Sławek Sobótka <sso...@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

[Sławek Sobótka]

Dodam jeszcze, że dziedziczenie w kontrolerach może mieć sens w
specyficznym przypadku.
Wyobraźmy sobie coś takiego:
Jest sobie widok, który może mieć różne kontrolery (np. w zależności
od konfiguracji wdrożenia, czy tego kto jest aktualnie zalogowany).
Takie kontrolery mogłyby być w runtime "wyliczane" np w metodach
fabrykujących adnotowanych @Bean.
Np do fabryki wstrzykujemy aktualnie zalogowanego usera lub
repozytorium z dostępem do tabel konfiguracyjnych a metoda fabrykujący
na ich podstawie decyduje jaką konkretną implementację kontrolera
zwrócić.

W takim wypadku mielibyśmy "polimorficzny" (w cudzysłowu) dostęp z
widoku do kontrolera.

Oczywiście można podejść inaczej, niejako "piętro niżej" i zrobić
jeden konkretny kontroler, który deleguje obsługę specyficznych żądań
do agregatowanych handlerów (wzorzec strategii).

[Damian Nowak]

Witam,

A ja odpowiem dokładnie na pytania zadane przez autora. :)

> INFO: Mapped URL path [/foo/.*] onto handler 'Controller_A'
> INFO: Mapped URL path [/bar/test.*] onto handler 'Controller_B'
> INFO: Mapped URL path [/bar/foo.*] onto handler 'Controller_B' <--
> Dlaczego?

Kontroler B ma po prostu akcje "foo" i "bar" za sprawą dziedziczenia.
Dlaczegoż część akcji nie miałaby być widoczna? Wszystkie są publiczne i
zaadnotowane, więc Web MVC robi to, o co go prosimy - mapuje urle
na metody. :)

> Czy mozna sprawic, ze sciezki URL nie beda dziedziczone w
> Controller_B?

Ja nie widziałem... I pewnie nie ma, bo takie zachowanie byłoby
nieoczywiste, dziwne i redundantne (można przecież zamienić
dziedziczenie na delegację lub ewentualnie na klasę abstrakcyjną,
którą rozszerzą A i B).

--
Damian Nowak
www.nowaker.net