- Degene die deze klasse heeft aangemaakt heeft ook de dependency gezet
- De dependency kan nooit meer gewijzigd worden

Bijvoorbeeld:

public class PersoonService {

//Compiler dwingt dat deze gevuld moet worden door een constructor
final PersoonDao persoonDao;

public PersoonService(final PersoonDao persoonDao) {
this.persoonDao = persoonDao; //Kan nooit meer gemuteerd worden!
}
}

Je kan dan zelfs een eigen (hardcoded) booster schrijven die de dependencies eenmalig zet, de instanties zijn dan misschien wel geen singletons, maar de dependencies zijn wel final en gezet.

Bijvoorbeeld:

public class Booster {
public void onStartup() {
//Wire everything
PersoonDao persoonDao = new PersoonDao(myJDBCConnectie);
PersoonService persoonService = new PersoonService(persoonDao);
PersoonBean bean = new PersoonBean(persoonService);

//etc etc misschien met factory erbij
}
}

Yay, weer een eigen IoC framework geschreven, nog even een annotation-processor toevoegen, klaar

Zeker met Dependency Injection is dit het geval, want in de klasse die gebruik maakt van een dependency heb je alleen een constructor of setter, meer doe je daar niet.

Tevens denk ik dat je heel snel problemen krijgt als je op verschillende projecten zelfgemaakte oplossingen tegenkomt, het is naar mijn mening voor de meeste programmeurs erg goed om een vaste manier te hebben van werken.. en tegenwoordig lijkt Spring de defacto te zijn.

Er zitten natuurlijk altijd ‘nadelen’ aan het gebruik van een IoC framework, maarja… waar praten we dan over, deze dingen hoor je veel:

Guice (en Spring tegenwoordig): Je hebt annotations van je IoC framework in je code staan, dus zelf een dependency op het IoC framework. Je gecompileerde code heeft dus altijd het IoC framework nodig om te kunnen draaien. (Ja en? waarschijnlijk ook nog wel 10 andere frameworks)

Spring: De XML heeft een relatie met de Java-code, dus het hernoemen van een klasse kan ervoor zorgen dat het run-time niet meer werkt als je vergeet goed de XML-verwijzingen te veranderen. Maar een beetje IDE kan dit ook voor je oplossen natuurlijk.

Persoonlijk zou ik graag een keer een groot project met Guice willen doen, de echte “Java manier” met annotations. Want naast de snelheid (volgens sommige blogs 10x zo snel als Spring) heeft het nog een ander voordeel, de annotations zijn ook zelf-documenterend en makkelijker de refactoren.

@JKVA: Ja, deze post is compleet off-topic, maar ik vind het zelf schrijven van Singletons in de huidige enterprise wereld overboden en zonde van de tijd

“Kom ik terug op mijn vraag: waarom is IoC eigenlijk altijd run-time?”
Stel dat je 2 implementaties hebt, 1 mock en 1 echte. De mock implementatie heeft de default constructor en de productie implementatie bevat een constructor met parameters, maar zonder @Inject. Dat gaat tijdens het draaien van de test goed en kan toch op de server fout gaan. Hence, runtime controle. Is dat erg? Ik denk van niet, net zoals dat het niet zo erg is dat mijn Singleton pas @runtime zal crashen bij een fout.

In een Guice app vinden wel meer checks @runtime plaats. Je kunt dus een access modifier verkeerd zetten (class/constructor/setter). Je kunt @Inject vergeten op een constructor of een empty constructor vergeten. Je kunt de bind() vergeten. Je kunt vergeten een implementatie te schrijven… Allemaal fouten die je kunt maken die de compiler niet detecteert. Het zijn deels theoretische gevallen, dat snap ik ook wel, maar in mijn optiek zijn bij mijn reflection Singleton de nadelen ook voornamelijk theoretisch.

Ik zie qua type safety dus vrij weinig verschillen tussen Guice en de Singleton. De Reflection API is generic en in dit geval type safe. Het enige waar je voor op moet letten qua type safety is dat je de signature van de GoodSingleton constructor niet moet veranderen, maar met 1 unit test (op getInstance) vang je zulke problemen waterdicht af. Thread safety is gemakkelijk aan te tonen (het zijn immers maar 2 kleine klassen) op basis van code analyse, terwijl je bij een framework maar moet hopen dat alles bugvrij is. Je haalt immers een enorme codebase binnen (snelle scan met Winrar levert in Guice 470 classes op).

Maar goed, het blijft een afweging, dus: Heb je geen IoC container? Wil je wel een Singleton? Moet je Singleton concurrent zijn (lijkt me een no-brainer)? Staat je SecurityManager setAccessible() toe? Wil je je Singleton unit testen (lijkt me ook een no-brainer)? Ben je bereid om een heel klein beetje type safety op te geven ten behoeve van testbaarheid? Wil je je code kunnen analyseren en niet meer dan 2 classes lezen?
Als je al deze vragen met JA kunt beantwoorden, dan is dit volgens mij een prima oplossing. Anders moet je waarschijnlijk tussen een standaard Singleton of IoC kiezen. Of geen Singleton gebruiken, want in veel gevallen heb je hem niet nodig.

Ps. Ik ben benieuwd of er voor Guice al APT Processors en Eclipse builders zijn. Lijken me nuttige tools. Dan kunnen ze @compile-time alle classes inspecteren op basis van de relaties tussen de classes/annotations en onderlinge consistentie controleren. @ImplementedBy is bijvoorbeeld erg eenvoudig te checken met APT, maar het is onmogelijk met standaard javac.

@Pieter: Idd. Bij reloaden van die applicaties wordt het nog vervelender, zeker als de client applicaties de referenties bewaren i.p.v. opvragen met getInstance(). Krijg je allemaal erg obscure bugs van (NullPointers, inconsistente data…).

Wat ik vooral bedoelde is dat bijna alle (Enterprise?) projecten een IoC container gebruiken. En als je die al gebruikt, waarom zou je dan nog met reflectie gaan goochelen? Immers, alle IoC containers zullen onder water ook reflectie gebruiken om hun doel te bereiken. Het zit er al in. En goed getest ook. Dus waarom zelf opnieuw implementeren? Dat wil dus niet zeggen dat ik een fan van IoC ben!

Als je echter nog geen IoC container gebruikt, dan vind ik het een ander verhaal.

IoC is natuurlijk ook run-time (waarom eigenlijk?), maar bijvoorbeeld met Google Guice kun je de bindings van interfaces aan implementatie wel gewoon compile-time en type-safe definiëren in een Module. Het lukt je niet een implementatie te koppelen aan een interface die de concrete klasse niet implementeert. Dat compileert gewoon niet. De enige echte fout die je nog kunt maken is dat je vergeet een implementatie te koppelen aan een implementatie en daar kom je dan pas run-time achter. (Ook al heb je een simpele integratietest die niks anders doet dan je Module in de lucht hijsen, dan nog is het te laat.)

Kom ik terug op mijn vraag: waarom is IoC eigenlijk altijd run-time?

public class BadSingletonTest {

@Before
public void setup() {
System.setProperty(“prop1″, “test value1″);
System.setProperty(“prop2″, “test value2″);

}

@Test
public void testSingleton() throws Exception {

BadSingleton obj1 = BadSingleton.getInstance();
BadSingleton obj2 = BadSingleton.getInstance();

Assert.assertTrue(“not same object” ,obj1==obj2);
}

@Test
public void testProperty() throws Exception {

BadSingleton obj = BadSingleton.getInstance();

Assert.assertEquals(obj.getProp1(), “test value1″);
Assert.assertEquals(obj.getProp2(), “test value2″);
}
}

Mijn punt is dat Singletons bepaalde nadelen hebben, zoals testbaarheid. Ik draag daar een oplossing voor aan. Die oplossing heeft voor- en nadelen, zoals ook aangegeven in het stukje. Eén van die nadelen is inderdaad dat reflection meer bug gevoelig is dan alles wat je @compile-time kunt checken. Onderaan het stukje noem ik ook een alternatief (zie 2de bullet) dat geen reflection gebruikt.

De reden dat ik het stukje plaatste, is dat ik in de praktijk wel degelijk ontestbare Singletons tegenkom. Voor die gevallen is dit een relatief nette oplossing, maar het blijft een middel. Een middel met voor- en nadelen.

IoC is leuk, maar niet @compile-time (dat geldt niet alleen voor Spring). Dat is aan de ene kant een sterk punt van IoC, maar je verliest er een stukje veiligheid mee. Vandaar dat ik jouw opmerking over IoC zo vreemd vond. 3 regels reflection op een gecontroleerde plaats vind je slecht, maar een dependency @runtime opzoeken en injecteren vind je wel goed? Dat vind ik appels met peren vergelijken. En zeg nou zelf, hoeveel type safety raak je nou feitelijk kwijt? Zeker aangezien vrijwel alles in de reflection API generic is.

Maar goed, laten we het maar op “ruis op de lijn” houden. Volgens mij zijn we het er allebei over eens dat IoC in bepaalde gevallen nuttig is, reflection in bepaalde gevallen nuttig is en singletons in bepaalde gevallen nuttig zijn. Welk geval, daar heb ik in dit blog niets over gezegd, want dat is context afhankelijk.

Zijn we het nu eens?

Appels en peren.

En ook nog eens niet waar, op meer dan 1 manier…

Oh ja, en Spring is niet het enige IOC framework.

Worst case: Singleton instance per class loader. Zie ook issues met bijvoorbeeld Log4J en meerdere apps in een single JVM.

Geen hond bouwt nog (enterprise) applicaties zonder gebruik te maken van een dependency injection framework. En die stellen je prima in staat om Singletons te definieren zonder dat je dat in de klasse vast moet leggen. Dus waarom zou je allerlei technische trucs gaan toepassen? Helemaal als die het je onmogelijk maken je code goed te unit testen?

Singleton is een Design Pattern. Een pattern waar op zich niks mis mee is. Met veel van de technische uitwerkingen ervan wel.