Spring AOP autowiring scares the poopoo out of me

Usually brains are quick to sort everything into one of two categories: GOOD and BAD

Some things refuse to go to either category or, even worse, ping pong back and forth until who knows what else gets scrambled up there. My brain still struggles with categorizing the following…

 The Scala Language

 Candy Corn

 Richard Simmons

Until now, autowiring in Spring was somewhere between Candy Corn and Richard Simmons. Let me explain how it got there.

Every ounce of logic in me had been screaming that autowiring is a good thing because it takes away a bad thing: XML. Autowiring should cannonball at light speed into the GOOD half of my brain pool, splashing memories of Oregon Trail out my nose.

But the brain isn’t very logical. It’s mostly associations. We often get hunches, gut feelings, and red flags but we can’t always articulate or why. 

Saturday morning (you’d think I’d have better things to do) I finally realized why it’s so hard to let go of XML, this melted green icing of our framework cake. When I inherit a project here’s what I do get my bearings, since there’s absolutely no documentation available because some ivory tower Architecture committee banned wikis for “security reasons” yet our division was too cheap to get SharePoint and too disorganized to keep a few Word docs on a shared drive (yes this is from past experience):

1) Read the JavaDoc. There are only two types of information here: author names (I commit these to memory so I can retrieve formal apologies – it’s a small world and I will meet these people some day) and some banal rewording of class and method names (a comment for a class called DataHelper will say “A class to help the data”) 

2) Look at unit tests. Methods like testSetDescriptionOnDataHelper reveal that the agile developers before me were apparently only concerned that Eclipse didn’t screw up auto-generating their getters and setters.

3) Poke around classes, trying to at least figure out which ones are domains. Cross my fingers that design pattern names like DAO and BusinessDelegate are mashed into the class names just to help my brain spatially map the architecture.  

4) Grumble about the naive programmer who thought “program to the interface” meant that we should create an army of interfaces to Impl-cripple our architecture.

At this point, my brain begins throbbing under pressure and blood shoots out of my ears.

4) Give up looking at code.

5) Read the configuration XML file. This is the only hope I have of learning anything about the application.

I love the XML I hate. It forces bad developers (and sometimes brilliant developers under ridiculous timelines) to do something kinda good.

What scares the poopoo out of me about autowiring is… what in the world I’m going to do at step 5 when my monolithic XML is gone!?