9 March 2009

Final interfaces... proposal

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.

6 comments:

  1. Moim zdaniem jest to bezsensowne bo tworzy wiązanie interfejsu z konkretnymi implementacjami (lub interfejsami rozszerzającymi).

    ReplyDelete
  2. I masz racje i się mylisz ;)

    Oczywiś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.

    ReplyDelete
  3. 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).

    ReplyDelete
  4. Powiedział bym raczej że mało kto by z tego korzystał.
    Tak jak rzadkie jest obecnie używanie słowa final przed klasą.

    ReplyDelete
  5. 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.
    Ale 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.

    ReplyDelete