[JAVA] Sub klassen met elkaar laten refereren

[PhoneTech]

Voor een java project heb ik 1 superklasse waar allemaal gemeenschappelijke eigenschappen in staan, en sub klassen die dit allemaal overerven en specifieke eigenschappen toevoegen.



de superklasse is abstract, en kan niet geinstantieerd worden.

Nu wil ik dat alle sub klassen, 0 of meerdere referenties naar zichzelf of andere klassen die zijn overgeerft van de superklasse kunnen maken.

Nu heb ik dat opgelost door in Entity, een association naar zich zelf te maken zodat alles met elkaar te verbinden is.

Nu komt mijn vraag.

Ergens in mijn achterhoofd denk ik dat wel tegen een zooi programmeertechnische problemen gaan aanlopen.

Stel dat klasse A een collectie heeft met daarin instanties van B en C, dan kan ik via InstanceOf (of classname) achter de juiste entity komen, en dan correct casten.

Is dit wel de juiste manier? Het liefst zal ik een Composite pattern gebruiken hiervoor, maar dat kan niet, omdat een child meerdere parents kan hebben. Het is namelijk geen hierarchisch systeem maar een soort web systeem.

[Macros]

Je moet zorgen dat je vooral alleen methodes in A, B en C hebt die overgeerft zijn van je BaseClass. Dan hoef je niks te casten als je ze uit je collection haalt.

[Verbal Kint]

Als het alleen om methods gaat kan je mi beter een interface implementatie gebruiken in plaats van een abstracte superklasse.

[PhoneTech]

Macros schreef op 15 oktober 2004 @ 10:36:
Je moet zorgen dat je vooral alleen methodes in A, B en C hebt die overgeerft zijn van je BaseClass. Dan hoef je niks te casten als je ze uit je collection haalt.

Het zijn meer DTO klassen. Dit model gaat namelijk gebruikt worden voor een J2EE applicatie, waar de DTO klassen worden gevuld uit CMP's, en vervolgens geserialized worden om naar de client gestuurd te worden. De methodes die er in staan, zijn dus over het algemeen alleen de methodes die door xDoclet gegenereerd worden.

[PhoneTech]

heeft iemand nog hier suggesties over?

[Glimi]

PhoneTech schreef op 15 oktober 2004 @ 10:47:
Het zijn meer DTO klassen.

Data Tier Objects?

Dit model gaat namelijk gebruikt worden voor een J2EE applicatie, waar de DTO klassen worden gevuld uit CMP's, en vervolgens geserialized worden om naar de client gestuurd te worden.

CMP's, die ken ik alleen als compares

De methodes die er in staan, zijn dus over het algemeen alleen de methodes die door xDoclet gegenereerd worden.

Misschien kun je beter even wat concreter informatie geven, het model aangeven met je concrete implementaties en de situatie (liefst zonder al te veel 3 letter afkortingen ) want voor verwijzingen naar andere subclasses (en dan niet via een interface) kan ik niet zo heel redenen bedenken.

[Alarmnummer]

PhoneTech schreef op 15 oktober 2004 @ 10:28:
Nu wil ik dat alle sub klassen, 0 of meerdere referenties naar zichzelf of andere klassen die zijn overgeerft van de superklasse kunnen maken.

Waarom wil jij dit? Normale referenties ( _vader, _echtgenoot etc) zijn niet goed?

Stel dat klasse A een collectie heeft met daarin instanties van B en C, dan kan ik via InstanceOf (of classname) achter de juiste entity komen, en dan correct casten.

Waarom wil je weer terug casten, is dit niet iets dat je met polymorfisme kunt oplossen?

Is dit wel de juiste manier? Het liefst zal ik een Composite pattern gebruiken hiervoor, maar dat kan niet, omdat een child meerdere parents kan hebben. Het is namelijk geen hierarchisch systeem maar een soort web systeem.

Dat maakt niets uit hoor. En met patterns is het niet zo dat je ze exact moet volgen, patterns moet je juist op maat maken. Als je trouwens bang bent om in oneindige lussen terecht te komen, kun je natuurlijk ook bijhouden welke elementne je hebt gehad en die niet weer verwerken.

[Alarmnummer]

Glimi schreef op 16 oktober 2004 @ 10:53:
[...]

Data Tier Objects?

Data transfer objects. Je pakt alle info uit een entiteit object (bv persoon), gooit die in een ultra light object die eenvoudig te serializen is (en dus ook buiten zijn container kan leven). Na afloop van een of ander request geef je de entiteit object zijn dto terug en hij kan alle info eruit peuteren. Data transfer objecten zijn voornamelijk bedoelt om het netwerk te ontzien doordat je minder remote calls krijgt.

getPersoonDto().

of.

getVoornaam();
getAchternaam();
getWoonplaats();
getGeboorteDatum();
get.....

Scheelt je enorm in de netwerk calls.

(liefst zonder al te veel 3 letter afkortingen )

Als je thuis bent in de techniek is het juist erg prettig om te zien met wat voor soort object je te maken hebt.

[ Voor 24% gewijzigd door Alarmnummer op 16-10-2004 10:58 ]

[flowerp]

Alarmnummer schreef op 16 oktober 2004 @ 10:56:
Als je thuis bent in de techniek is het juist erg prettig om te zien met wat voor soort object je te maken hebt.

Maar 3-letterige afkortingen zijn niet altijd goed. Er zijn er te veel, ze worden te vaak onduidelijk gebruikt, en er zijn te veel die verschillende dingen kunnen betekenen. Laatst nog verwarring over met iemand die zei dat ie goed met UML overweg kon. Bleek dus User Mode Linux te zijn en geen Unified Modelling Language.

Voorts zie je ook dat zelfs de grootste experts niet altijd thuis zijn in 3 letterige afkortingen, terwijl ze het concept wel kennen. Was niet zo lang geleden nog een post over van msalters.

[Alarmnummer]

flowerp schreef op 16 oktober 2004 @ 16:03:
[...]
Maar 3-letterige afkortingen zijn niet altijd goed. Er zijn er te veel, ze worden te vaak onduidelijk gebruikt, en er zijn te veel die verschillende dingen kunnen betekenen. Laatst nog verwarring over met iemand die zei dat ie goed met UML overweg kon. Bleek dus User Mode Linux te zijn en geen Unified Modelling Language.

Hmm tja.. Persoonlijk vind ik het wel erg prettig en binnen een it bedrijf mag je er toch ook vanuit gaan dat de namen goed gebruikt wordt. En tja.. dat er eens een foutje kan onstaan... is volgens mij minder vervelend dan extreem lange class namen. PersoonDataTransferObject FietsDataAccessObject. pfff.. vervelend

[flowerp]

Alarmnummer schreef op 16 oktober 2004 @ 17:37:
[...]

Hmm tja.. Persoonlijk vind ik het wel erg prettig en binnen een it bedrijf mag je er toch ook vanuit gaan dat de namen goed gebruikt wordt. En tja.. dat er eens een foutje kan onstaan... is volgens mij minder vervelend dan extreem lange class namen. PersoonDataTransferObject FietsDataAccessObject. pfff.. vervelend

*lol* nu volg ik al lang P&W en zeker met jou comments ben ik het geloof ik altijd wel eens, maar met deze niet. Ik gebruik juist vrijwel alleen maar lange namen. Voor mij is het toch een stukje zelfdocumenterendheid (is dat een woord?) van je code. Met moderne IDE's en name completion is het vaak ook helemaal niet erg. Natuurlijk, als je geen IDE's gebruikt of geen IDE's met name completion dan wordt het wel snel vervelend.

Er zijn overigens best wel een aantal websites die gaan over de zin en onzin van met name 3 letterige afkortingen. Ik zag laatst nog voorbeelden hier langskomen als:

EfBe schreef op 21 september 2004 @ 09:47:
Als ik roep wat een DFD is of een DSD staan ook veel afgestudeerde Informatici me glazig aan te kijken, of bv wat NIAM is.... ze hebben geen idee...

en

Verwijderd schreef op 21 september 2004 @ 12:21:
Als ik bijvoorbeeld vraag wat een FSM is dan zou ik dat zeker weten zelf ook niet zo snel weten, maar als ik dan meteen daarna zeg "een Finite State Machine, of te wel een eindige automaat", ook wel in een STD (State Transition Diagram) gebruikt die je in zowel software engineering (bv modelling) of fundamentele informatica tegenkomt,

[...]

Het punt is mischien eerder dat (3 letterige) afkortingen buiten hun context niet zo nuttig zijn om te vragen. NIAM weet ik overigens absoluut niet, ook nog nooit van gehoord

[Alarmnummer]

[quote]flowerp schreef op 16 oktober 2004 @ 18:14:
[...]
*lol* nu volg ik al lang P&W en zeker met jou comments ben ik het geloof ik altijd wel eens, maar met deze niet. Ik gebruik juist vrijwel alleen maar lange namen. Voor mij is het toch een stukje zelfdocumenterendheid (is dat een woord?) van je code. Met moderne IDE's en name completion is het vaak ook helemaal niet erg.
[quote]
Ik snoei zo nu en dan wel stukken van namen af om het beter leesbaar te krijgen (of bedenk een nieuwe naam voor het object). ListMapStackQueueVectorController is zo naar

Ik heb er zelf in ieder geval niet zoveel problemen mee om afkortingen te gebruiken en de mensen waarmee ik samenwerk gebruiken dezelfde namen. Dus dao, dto is allemaal goed genoeg als postfix.

Maar ben het wel met je eens dat je door alle afkortingen door de bomen het bos niet meer ziet staan. Voorals als je richting J2EE gaat dan krijg je zoveel om de oren geslingerd.

[flowerp]

Alarmnummer schreef op 16 oktober 2004 @ 18:55:
Maar ben het wel met je eens dat je door alle afkortingen door de bomen het bos niet meer ziet staan. Voorals als je richting J2EE gaat dan krijg je zoveel om de oren geslingerd.

De netwerk richting is ook erg. Ik ben nog niet zo lang van school af en kan me nog goed herinneren dat als je alle afkortingen een beetje wist je al een heel eind was voor een tentamen als 'netwerken'. Later nog wat 'profesionele' boeken over netwerken doorgekeken en opvallend is dat veel daarvan aan de binnenkant van de kaft een (grote) lijst met afkortingen hadden.

[PhoneTech]

Alarmnummer schreef op 16 oktober 2004 @ 10:54:
[...]

Waarom wil jij dit? Normale referenties ( _vader, _echtgenoot etc) zijn niet goed?

Het systeem moet in staat zijn, alle soorten entiteiten met elkaar te kunnen linken. In de base class staat dus een collectie, waar in de verschillende gelinkte entiteiten komen te staan. Vervolgens wordt in de client de verschillende entiteiten gegroepeerd per type.

[...]

Waarom wil je weer terug casten, is dit niet iets dat je met polymorfisme kunt oplossen?

ja klopt, maar dan moet ik toch eerst weten wat voor klasse de entiteit is toch?

[...]

Dat maakt niets uit hoor. En met patterns is het niet zo dat je ze exact moet volgen, patterns moet je juist op maat maken. Als je trouwens bang bent om in oneindige lussen terecht te komen, kun je natuurlijk ook bijhouden welke elementne je hebt gehad en die niet weer verwerken.

Ik zou graag de composite gebruiken (die gebruik ik trouwens voor veel andere onderdelen in de applicatie), maar voor de relaties tussen de entiteiten te beheren, gebruik ik toch liever een ander mechaniek, omdat compisite je vast zit aan een hierarchisch data ontwerp, wat het bij ons absoluut niet is. Alles is met elkaar te linke,

A kan vader zijn van C en B kan een child van A en C zijn. compleet random relaties dus.

[PhoneTech]

Alarmnummer schreef op 16 oktober 2004 @ 10:56:
[...]

Data transfer objects. Je pakt alle info uit een entiteit object (bv persoon), gooit die in een ultra light object die eenvoudig te serializen is (en dus ook buiten zijn container kan leven). Na afloop van een of ander request geef je de entiteit object zijn dto terug en hij kan alle info eruit peuteren. Data transfer objecten zijn voornamelijk bedoelt om het netwerk te ontzien doordat je minder remote calls krijgt.

getPersoonDto().

of.

getVoornaam();
getAchternaam();
getWoonplaats();
getGeboorteDatum();
get.....

Scheelt je enorm in de netwerk calls.


[...]

Als je thuis bent in de techniek is het juist erg prettig om te zien met wat voor soort object je te maken hebt.

die hele discussie over die 3 letter begrijp ik niet echt. Als ik het over dto heb, dan heb ik het idd over lightweight klassen die makkelijk zijn te versturen. (het zijn er zelfs meerdere per object, light en normal)

Het domain model (fowler) bestaat uit de DTO klassen. verder zal het ejb cmp model niet in het domein klasse worden gezet vanwege performance overwegingen en omdat CMP gelimiteerd is in functionaliteit die je juist wel nodig hebt bij het domain model.

In de session beans worden alle data van de cmp's overgezet in dto's die makkelijk zijn te interpreteren door de client. (is trouwens een SWT client! Heerlijk!! die worden door webstart gedistribueerd.)

althans, als dat de goede manier is ten minste...