Instrukcje
Interface (klasa abstrakcyjna) finalny nie mógłby zostać rozszerzony (zaimplementowany) przez żadną klasę(interface), oprócz tych określonych wprost.
Przegląd
Podsumowanie:
Główne zalety / korzyści:
- Ograniczenie pomyłek, zwłaszcza w przypadku dużych projektów.
- Zwiększenie bezpieczeństwa.
Najistotniejsze wady:
- Trzeba zaimplementować.
Inne rozwiązania:
- Agregacja + validacja.
Przykłady:
Detale rozwiązania:
interface final Interface allow ClassI
Kompatybilność wsteczna:
Zapewniona.
Kompatybilność w przód:
Częściowa.
Moim zdaniem jest to bezsensowne bo tworzy wiązanie interfejsu z konkretnymi implementacjami (lub interfejsami rozszerzającymi).
ReplyDeleteI masz racje i się mylisz ;)
ReplyDeleteOczywiście w standardowych sytuacjach to jest 'bez sensu'.
Wiązanie tego typu jest natomiast konieczne (w niektórych przypadkach) ze względów bezpieczeństwa, aczkolwiek nie wszystkich ten problem interesuje.
Pozdrawiam.
Z doświadczenia wiem, że niewiele osób by korzystało z tego zgodnie z Twoją intencją, przez co interfejsy wiązały by się z implementacjami co tworzy mnóstwo problemów (używanie dowolnej implementacji lub brak możliwości napisania własnej).
ReplyDeletePowiedział bym raczej że mało kto by z tego korzystał.
ReplyDeleteTak jak rzadkie jest obecnie używanie słowa final przed klasą.
Nie bardzo widzę sensu tego, zwłaszcza że np. taki Spring potrafi dekorować co popadnie w różne proxy, np. do nałożenia tranzakcji.
ReplyDeleteAle jeśli już bardzo uważasz, że to potrzebne, nie trzeba zmian w języku. Wystarczyłoby napisać adnotację w stylu:
@OnlyImplementors({CostamImpl1, CostamImpl2, ...})
public interface Costam {
...
}
Następnie można napisać rozszerzenie do Findbugs, Checkstyle lub Spoon, czy Springowego BeanPostProcessora które by robiło łubut jak jest jakaś inna implementacja tego.
Ano można.
ReplyDelete