Java design probleem (inheritance e.a.)

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Tharulerz
  • Registratie: April 2009
  • Laatst online: 10-04 05:16
Zoals jullie ongetwijfeld wel weten, is het niet mogelijk om static methods te overriden in een subklasse.

Echter is dat wel de functionaliteit die ik zou willen. Kan er hier iemand een goed alternatief bedenken?

De situatie is als volgt:

Superklasse (abstract) ConditieTest, met als subklasses fietstest, looptest, etc.

De user vraagt via de interface een lijst van mogelijke tests op, en kiest een test om aan te maken (sidenote: goede manier om lijst van mogelijke testen dynamisch te maken? Dacht voorlopig aan een collection van Class objects, opdewelke je dan class.newInstance kan doen? Wil vermijden dat UI moet weten welke subklasses er zijn)

Elke test heeft een bepaald aantal parameters, laten we die TestOptions noemen. Denk aan dingen zoals loopafstand, bandenspanning, hellingsgraad, tijd, etc (hier lijken ze nog vrij gemeenschappelijk voor eventueel in de superklasse te steken, maar ze zijn redelijk specifiek en horen dus bij elke subklasse apart.)

Om deze values in de user interface te kunnen invullen, dacht ik een static methode aan te maken die alle TestOptions opvraagt, en dan in de interface hierover te itereren om zo de required fields hiervoor aan te maken.

Echter kan ik op een Class object geen static methodes aanroepen, laat staan dat ik static methodes kan overerven (ik weet immers enkel dat mijn gekozen Class object van het type ConditieTest is, maar het subtype ken ik niet, dus ik zou het op de super moeten oproepen).

Concrete vragen:

Is er een betere manier om dynamisch de verschillende tests door te geven aan de user interface?
Is er een propere manier om de specifieke TestOptions per subklasse op te vragen?

De enige optie die ik zelf kan bedenken is een soort van buildermethod/klasse schrijven, maar alle input is welkom!

Acties:
  • 0 Henk 'm!

Verwijderd

Mijn eerste ingeving is: zoek eens op het factory pattern. Zodra een base class details moet kennen van z'n afgeleiden is er meestal iets niet in de haak...

Acties:
  • 0 Henk 'm!

  • Herko_ter_Horst
  • Registratie: November 2002
  • Niet online
Ik zou voor een factory+registry aanpak gaan, waarbij je voor elk van de implementaties van ConditieTest een ConditieTestFactory maakt die zich aanmeldt bij een (singleton) registry. De registry geeft toegang tot de lijst van factories, elke factory kan een instantie van de juiste ConditieTest subclass maken (geen geneuzel met Class.newInstance).

Voor de UI zou ik daarnaast een vergelijkbare hierarchie + factory + registry maken voor ConditieTestUI. De registry kan dan de juiste UI-factory opzoeken voor een ConditieTest subclass, waarna de factory weer een ConditieTestUI kan maken (voor een ConditieTest instantie).

Als je factories pluggable wil maken via aparte jar files, kijk dan ook eens naar java.util.ServiceLoader, of als het nog geavanceerder moet, naar OSGi (gebruik hiervoor bijvoorbeeld Apache Felix).

[ Voor 25% gewijzigd door Herko_ter_Horst op 25-11-2011 19:50 ]

"Any sufficiently advanced technology is indistinguishable from magic."


Acties:
  • 0 Henk 'm!

  • Tharulerz
  • Registratie: April 2009
  • Laatst online: 10-04 05:16
Bedankt Herko, daar heb ik al iets aan. Het is niet zo uitgebreid dat we aparte jars oid moeten maken, dus daar maak ik me nog niet teveel zorgen om.

Waltor: ik weet niet of je het topic uberhaupt gelezen heb maar ik denk niet dat ik ergens vermeld dat mijn base class details moet kennen van zijn subklasses?