:strip_exif()/u/31626/eend.gif?f=community)
De singleton design pattern wordt vaak te pas en te onpas gebruikt. Mijn ervaring ermee is dat het in sommige gevallen erg vervelend kan zijn, oa voor het testen. Je hebt een resource in je systeem waar je geen controle over uit kan oefenen (vaak weet je niet eens dat die er is)
De reden dat het singleton design pattern vaak in grote omgevingen wordt gebruik is omdat mensen slecht aan referenties van objecten kunnen komen. Verschillende frameworks worden aan elkaar vast gelijmt, en daarna is het maar de vraag hoe je dan maar aan je referentie komt -> singleton design pattern. Java heeft hier ook oa een handje van bij j2ee en je ziet dan allerlei constructies zoals service locators en allerlei jndi geneuzel. Het gevolg hiervan is dat je volledig afhankelijk begint te worden van de container waar je je applicatie in hangt. Persoonlijk vind ik dit erg vervelend omdat je niets meer onder controle hebt.
Singletons staan op mijn lijstje "gevaarlijke patterns" (dat wil niet zeggen dat ik ze nooit gebruik.. singletons kunnen nuttig zijn).
Maar objecten waar maar 1 van aangemaakt wordt hoeft zeker niet slecht te zijn. Je kunt veel eenvoudiger uitspraken doen over belangrijke objecten als er maar 1 van in je systeem aanwezig is. Stel dat je een of andere DocumentGenerator hebt met een zooi threads in een thread pool, dan weet je precies hoeveel threads bezig zijn om documenten aan te maken.
Services zijn bv ook ideaal om singleton te maken. Services zijn meestal stateless dus je hebt ook weinig te maken met concurrency. Verder is dit ook de ideale plek om je objecten te voorzien van transacties en security. Je weet dus exact wat je in je systeem hebt... je hebt controle... je kunt uitspraken doen over je systeem.
Singletons zijn dus goed.. objecten die het singleton design pattern gebruiken om singleton te worden vind ik persoonlijk minder (zie mijn commentaar hierboven). De vraag is dus hoe je eenvoudig aan je referentie van deze objecten kunt komen.
Op de een of andere manier heeft java met j2ee bv een enorm stuk complexiteit geintroduceerd zonder met goeie praktische oplossingen te komen zodat je op een menselijke manier met die complexiteit om kunt gaan. Ik gebruik nu al een tijdje Spring en het heeft echt mijn ogen geopend. Spring is een Inversion of Control container en het heeft de mogelijkheid om centraal al mijn belangrijke objecten op te bouwen en te voorzien van de goeie argumenten. Daarna is het object met alle goeie objecten gezet, klaar voor gebruik, en heeft dus totaal geen singletons meer nodig om aan referenties van andere objecten te komen. Ze zitten in de constructor!
Ik zie dus het nut dus steeds minder goed in van allerlei zware oplossingen zoals bv jndi en ik ben blij dat ik weer terug kan gaan naar eenvoud.
Ok.. tot zover mijn kritiek over singleton design pattern.. en lof over singleton objecten.. Wat is jullie mening erover? Hoe ga je om met het testen van singletons? Wat zijn jullie nare ervaringen ermee? Hoe gaan jullie om met het steeds-weer-opnieuw-aanmaken-van-objecten? Kunnen jullie uitspraken doen over het systeem?
De reden dat het singleton design pattern vaak in grote omgevingen wordt gebruik is omdat mensen slecht aan referenties van objecten kunnen komen. Verschillende frameworks worden aan elkaar vast gelijmt, en daarna is het maar de vraag hoe je dan maar aan je referentie komt -> singleton design pattern. Java heeft hier ook oa een handje van bij j2ee en je ziet dan allerlei constructies zoals service locators en allerlei jndi geneuzel. Het gevolg hiervan is dat je volledig afhankelijk begint te worden van de container waar je je applicatie in hangt. Persoonlijk vind ik dit erg vervelend omdat je niets meer onder controle hebt.
Singletons staan op mijn lijstje "gevaarlijke patterns" (dat wil niet zeggen dat ik ze nooit gebruik.. singletons kunnen nuttig zijn).
Maar objecten waar maar 1 van aangemaakt wordt hoeft zeker niet slecht te zijn. Je kunt veel eenvoudiger uitspraken doen over belangrijke objecten als er maar 1 van in je systeem aanwezig is. Stel dat je een of andere DocumentGenerator hebt met een zooi threads in een thread pool, dan weet je precies hoeveel threads bezig zijn om documenten aan te maken.
Services zijn bv ook ideaal om singleton te maken. Services zijn meestal stateless dus je hebt ook weinig te maken met concurrency. Verder is dit ook de ideale plek om je objecten te voorzien van transacties en security. Je weet dus exact wat je in je systeem hebt... je hebt controle... je kunt uitspraken doen over je systeem.
Singletons zijn dus goed.. objecten die het singleton design pattern gebruiken om singleton te worden vind ik persoonlijk minder (zie mijn commentaar hierboven). De vraag is dus hoe je eenvoudig aan je referentie van deze objecten kunt komen.
Op de een of andere manier heeft java met j2ee bv een enorm stuk complexiteit geintroduceerd zonder met goeie praktische oplossingen te komen zodat je op een menselijke manier met die complexiteit om kunt gaan. Ik gebruik nu al een tijdje Spring en het heeft echt mijn ogen geopend. Spring is een Inversion of Control container en het heeft de mogelijkheid om centraal al mijn belangrijke objecten op te bouwen en te voorzien van de goeie argumenten. Daarna is het object met alle goeie objecten gezet, klaar voor gebruik, en heeft dus totaal geen singletons meer nodig om aan referenties van andere objecten te komen. Ze zitten in de constructor!
Ik zie dus het nut dus steeds minder goed in van allerlei zware oplossingen zoals bv jndi en ik ben blij dat ik weer terug kan gaan naar eenvoud.
Ok.. tot zover mijn kritiek over singleton design pattern.. en lof over singleton objecten.. Wat is jullie mening erover? Hoe ga je om met het testen van singletons? Wat zijn jullie nare ervaringen ermee? Hoe gaan jullie om met het steeds-weer-opnieuw-aanmaken-van-objecten? Kunnen jullie uitspraken doen over het systeem?
[ Voor 6% gewijzigd door Alarmnummer op 18-01-2005 16:35 ]
).
