[JAVA] final implementatie binnen een interface mogelijk?

[dip]

Ik had zojuist een discussie met een collega over het volgende:

Ik heb een interface genaamd LookupService met daarin 3 methods. 1 van deze methods, method x heeft altijd dezelfde implementatie en er zal in geen gevallen een andere implementatie voorkomen. Hoe kan ik, zonder deze medhod als static in een util class te plaatsen, een vaste implementatie geven? Ook moet het een interface blijven omdat ik anders vastzit aan LookupService super.

Ik heb al het volgende geprobeerd:
Binnen de interface een final innerclass gemaakt met een public final static implementatie van mijn methode x.

Wanneer ik vervolgens deze interface probeer te gebruiken

Java:

public class JaNee implements LookupService {
}

krijg ik de melding dat mijn abstracte methode x nog niet geïmplementeerd is.

Weet iemand of wat ik wil überhaupt wel mogelijk is? Indien dit niet mogelijk is lijkt me dit wel vervelend, want in sommige situaties wil je een component als interface aanbieden met soms een vaste invulling. dip

[Alarmnummer]

dip schreef op donderdag 11 mei 2006 @ 11:15:
Ik had zojuist een discussie met een collega over het volgende:

Ik heb een interface genaamd LookupService met daarin 3 methods. 1 van deze methods, method x heeft altijd dezelfde implementatie en er zal in geen gevallen een andere implementatie voorkomen. Hoe kan ik, zonder deze medhod als static in een util class te plaatsen, een vaste implementatie geven? Ook moet het een interface blijven omdat ik anders vastzit aan LookupService super.

Ik heb al het volgende geprobeerd:
Binnen de interface een final innerclass gemaakt met een public final static implementatie van mijn methode x.

Wanneer ik vervolgens deze interface probeer te gebruiken

Java:

public class JaNee implements LookupService {
}

krijg ik de melding dat mijn abstracte methode x nog niet geïmplementeerd is.

Weet iemand of wat ik wil überhaupt wel mogelijk is? Indien dit niet mogelijk is lijkt me dit wel vervelend, want in sommige situaties wil je een component als interface aanbieden met soms een vaste invulling. dip

Je moet niet dingen altijd onmogelijk proberen te maken in code. Soms is een goed stuk documentatie veel handiger.

Ik zou gewoon een interface maken. Daar een abstract implementatie van maken met die methode geimplementeerd (eventueel zou je die methode final kunnen maken). En dan kun je subclasses maken van die abstract implementatie die de andere methodes implementeren.

Als je heel lastig wilt doen zou je ook de interface kunnen droppen en alleen die abstract class met die final methode aanbieden. Maar imho is dit niet echt goed aangezien er gewoon veel problemen kleven aan het werken met een class ipv een interface als basis.

[dip]

Alarmnummer schreef op donderdag 11 mei 2006 @ 11:24:Ik zou gewoon een interface maken. Daar een abstract implementatie van maken met die methode geimplementeerd (eventueel zou je die methode final kunnen maken). En dan kun je subclasses maken van die abstract implementatie die de andere methodes implementeren.

Als je heel lastig wilt doen zou je ook de interface kunnen droppen en alleen die abstract class met die final methode aanbieden. Maar imho is dit niet echt goed aangezien er gewoon veel problemen kleven aan het werken met een class ipv een interface als basis.

En wat nu als mijn implementerende (niet abstracte) klasse ook nog subclasse is van een van mijn Base classes?

[Alarmnummer]

dip schreef op donderdag 11 mei 2006 @ 11:38:
[...]
En wat nu als mijn implementerende (niet abstracte) klasse ook nog subclasse is van een van mijn Base classes?

Voorbeeld?

[dip]

Java:

public class Voorbeeld extends Form implements LookupService {
}

dan moet ik nog steeds een implementatie geven aan mijn mothode x, en dat is juist waar ik vanaf wil.

[Alarmnummer]

dip schreef op donderdag 11 mei 2006 @ 11:46:

Java:

public class Voorbeeld extends Form implements LookupService {
}

dan moet ik nog steeds een implementatie geven aan mijn mothode x, en dat is juist waar ik vanaf wil.

Je moet je dan afvragen of je wel een handige structuur gebruikt. Subclassen is overrated Compositie is meestal een veel beter ontwerp:

code:

class JouwForm extends AbstractForm{

   private LookupService lookupService;

   public JouwForm(LookupService lookupService){
       this.lookupService = lookupService;
   }
}

Dus meer denken in termen van 'A heeft een B' ipv 'A is een B'. Jij hebt een horloge, en jij bent niet een horloge. Jij hebt een broek en jij bent niet een broek. Bij het 'hebben' kan je in principe oneindig veel dingen toevoegen, bij het 'zijn' kom je toch snel in de problemen omdat je class erg complex begint te worden (en ook vreemd)

persoon.plaatsNieuweBatterijen()

Waar plaats ik nu die batterijen in? In je horloge? of in je IPod?

Dit is veel duidelijker:
persoon.getHorloge().plaatsNieuweBatterijen()

[ Voor 39% gewijzigd door Alarmnummer op 11-05-2006 12:14 ]

[Verwijderd]

En niet te vergeten dat final classes/methodes lastiger te testen zijn. Je kunt ze immers niet extenden/overriden.

[den 150]

Ik heb ooit eens iets gelezen dat het eventueel wel mogelijk is (maar het is natuurlijk not done)
Dit gezegd zijnde, kijk eens op http://www.javaspecialist...do?issue=006&locale=en_US.

Conclusie, niet doen

[TukkerTweaker]

laat maar

[ Voor 94% gewijzigd door TukkerTweaker op 11-05-2006 13:29 ]