[ALG] Architectuur applicatie met Spring

[Cuball]

Ik heb onlangs een stukje code geschreven maar begon me nu af te vragen of ik nie teveel gebruik maak van de IoC van Spring?

Een korte schets:

Ik heb een lijst, wat erin steekt speelt niet zo'n rol maar het zijn objecten die een verschillende status kunnen hebben.

Deze lijst moet verwerkt worden, naargelang de status dat het object heeft moet een andere bewerking (algoritme) gebeuren.

Wat ik nu opgezet heb is een Interface (nu ja het is in feite een Abstracte klasse omdat een deel van de functionaliteit die de afgeleide objecten moet uitvoeren voor alle statussen gelijk zijn).
Voor elk type status maak ik een Object die deze interface implementeerd en een speciefieke bewerking (algoritme) op het object uit deze lijst uitvoert.

Nu heb ik een algemene klasse waarin er zich een lijst zit met deze verschillende objecten die deze interface implementeren. (dit zijn objecten die allemaal een andere algoritme uitvoeren)

Ik heb het nu zo opgesteld dat ik via Spring deze lijst opvul met de verschillende Algoritmen (dit zijn die objecten die deze voorgenoemde interface implementeren).

Ik heb dan nu in deze algemene klasse een methode die over al deze algortimen itereerd en elk hun bewerking (algoritmen) uitvoeren op de objecten uit de lijst met specifieke status.

Is dit een goede manier van werken om verschillende strategies als spring beans te injecteren ?

[Alarmnummer]

Cuball schreef op donderdag 16 februari 2006 @ 17:02:
Ik heb onlangs een stukje code geschreven maar begon me nu af te vragen of ik nie teveel gebruik maak van de IoC van Spring?

Een korte schets:

Ik heb een lijst, wat erin steekt speelt niet zo'n rol maar het zijn objecten die een verschillende status kunnen hebben.

Deze lijst moet verwerkt worden, naargelang de status dat het object heeft moet een andere bewerking (algoritme) gebeuren.

Wat ik nu opgezet heb is een Interface (nu ja het is in feite een Abstracte klasse omdat een deel van de functionaliteit die de afgeleide objecten moet uitvoeren voor alle statussen gelijk zijn).

Ik zou nog steeds beginnen te ontwerpen van een interface. Dat jij ook een abstracte implementatie hebt die gedeeld kan worden door verschillende implementaties is een implementatie detail. Vanuit testoogpunt is het ook wel zo prettig omdat je interfaces veel makkelijker kunt mocken (vooral met een product zoals EasyMock)

Voor elk type status maak ik een Object die deze interface implementeerd en een speciefieke bewerking (algoritme) op het object uit deze lijst uitvoert.

Nu heb ik een algemene klasse waarin er zich een lijst zit met deze verschillende objecten die deze interface implementeren. (dit zijn objecten die allemaal een andere algoritme uitvoeren)

*Schenkt maar ff een bak koffie in want het begint wel vrij abstract te worden*

Ik heb het nu zo opgesteld dat ik via Spring deze lijst opvul met de verschillende Algoritmen (dit zijn die objecten die deze voorgenoemde interface implementeren).

Voor mijn begrip:
Is het niet handiger dat je ze in een map plaatst? En dat je dan als key de status gebruikt?

Dus Map<Status,Algoritme>

Ik heb dan nu in deze algemene klasse een methode die over al deze algortimen itereerd en elk hun bewerking (algoritmen) uitvoeren op de objecten uit de lijst met specifieke status.

Dat kan ook. Maar ik denk dat ik liever het algoritme ophaal op basis van een status.

Dus:

Element element = someElement;
Algoritme alg = algoritmeMap.get(element.getStatus());
alg.process(element)

Is dit een goede manier van werken om verschillende strategies als spring beans te injecteren ?

Ik weet verder niet over je ontwerp maar ik vind dit geen slechte manier van werken. Pas wel op dat de extra complexiteit die je creeert het wel waard is.

[ Voor 5% gewijzigd door Alarmnummer op 17-02-2006 09:07 ]

[Cuball]

Alarmnummer schreef op vrijdag 17 februari 2006 @ 08:58:
[...]

Ik zou nog steeds beginnen te ontwerpen van een interface. Dat jij ook een abstracte implementatie hebt die gedeeld kan worden door verschillende implementaties is een implementatie detail. Vanuit testoogpunt is het ook wel zo prettig omdat je interfaces veel makkelijker kunt mocken (vooral met een product zoals EasyMock)

goed idee

*Schenkt maar ff een bak koffie in want het begint wel vrij abstract te worden*

ik weet het, maar ik vond het niet echt nodig om met meer details te werken dan nodig om het probleem uit te leggen

[...]

Voor mijn begrip:
Is het niet handiger dat je ze in een map plaatst? En dat je dan als key de status gebruikt?

Dus Map<Status,Algoritme>

Dat kan ook. Maar ik denk dat ik liever het algoritme ophaal op basis van een status.

Dus:

Element element = someElement;
Algoritme alg = algoritmeMap.get(element.getStatus());
alg.process(element)

Ik weet verder niet over je ontwerp maar ik vind dit geen slechte manier van werken. Pas wel op dat de extra complexiteit die je creeert het wel waard is.

Een map lijkt inderdaad nog niet zo'n slecht idee, maar zal hier niet echt lukken vrees ik.

Ik heb dus die lijst van Objecten met elke een verschillende status, ik kan nu niet per object met een bepaalde status dit algoritme gaan uitvoeren. Er is dus eerst een methode die over deze grote lijst van objecten gaat en daar alle objecten met een bepaalde status uithaalt en die ook nog es volgens een bepaalde manier sorteert en pas dan kan ik het algoritme over die nieuwe gesorteerde lijst met allemaal dezelfde status loslaten.

Hier zit ik met een niet zo'n nette oplossing vrees ik, want voor elke algoritme moet de lijst dus opnieuw overlopen worden om alle objecten die het bepaalde algoritme kan af werken eruit te halen en te sorteren volgens een ordering waarmee dit algoritme overweg kan.

[sparidem]

Ik heb twee suggesties:
Je kunt eerst je masterlijst met objecten uitsplitsen in verschillende sublijsten met objecten met dezelfde status. Op deze manier hoef je je master lijst maar één keer door, dat is wat efficienter.

Verder als alternatief op de map, kan je ook opteren voor een factory die op basis van de meegeleverde status een algoritme teruggeeft.

[Cuball]

sparidem schreef op vrijdag 17 februari 2006 @ 09:30:
Ik heb twee suggesties:
Je kunt eerst je masterlijst met objecten uitsplitsen in verschillende sublijsten met objecten met dezelfde status. Op deze manier hoef je je master lijst maar één keer door, dat is wat efficienter.

op deze manier kan ik wel niet on the fly een nieuw algoritme toevoegen, want dan moet ik de code om deze lijst te gaan opsplitsen per status aanpassen voor het nieuwe toegevoegde algoritme. Stel er komen objecten bij met een nieuwe status, nu hoef ik enkel in Spring een nieuw algoritme bean in de lijst van algoritmen te steken en het algoritme op zich zorgt ervoor dat hij uit de lijst de objecten haalt die hijzelf kan gebruiken. Ik zie niet direct een methode waar ik niet per algoritme de lijst moet gaan overlopen

Verder als alternatief op de map, kan je ook opteren voor een factory die op basis van de meegeleverde status een algoritme teruggeeft.

hier heb ik dan ook nog de afhankelijkheid in de code van de factory waar elke status op voorhand gekend moet zijn opdat hij het juist algoritme kan toekennen.

[sparidem]

Cuball schreef op vrijdag 17 februari 2006 @ 09:41:
[...]

op deze manier kan ik wel niet on the fly een nieuw algoritme toevoegen, want dan moet ik de code om deze lijst te gaan opsplitsen per status aanpassen voor het nieuwe toegevoegde algoritme. Stel er komen objecten bij met een nieuwe status, nu hoef ik enkel in Spring een nieuw algoritme bean in de lijst van algoritmen te steken en het algoritme op zich zorgt ervoor dat hij uit de lijst de objecten haalt die hijzelf kan gebruiken. Ik zie niet direct een methode waar ik niet per algoritme de lijst moet gaan overlopen

Voor het toevoegen van een nieuwe status moet je ook de code aanpassen, dus helemaal 'on the fly' is het niet, maar inderdaad de cohesion is beter in jouw geval.

hier heb ik dan ook nog de afhankelijkheid in de code van de factory waar elke status op voorhand gekend moet zijn opdat hij het juist algoritme kan toekennen.

Ik ken je requirements niet, dus ik weet niet hoeveel flexibiliteit je nodig hebt, maar bedenk wel dat flexibiliteit een prijs heeft. Hoe meer flexibiliteit, hoe complexer je code, dus hoe lastiger te onderhouden. Als het een studieonderwerp is, is dat uiteraard geen probleem.

Eén van de grondprincipes van Spring: "We should minimize complexity up front to what's necessary to support actual (and reasonably foreseeable) requirements." (Rod Johnson)