Today’s podcasts gives takes brief look at a couple template classes provided by Spring, and why the idea is really important. I’m still working on a good format for show notes. Here’s a bare bones version.
This podcast focuses on a quick intro to Spring and how it affects your code dependencies.
If don’t want to listen to it with the player above, you can download Spring and Dependencies podcast.
Show Notes
Here’s the outline I worked from while recording the podcast. It’s sketchy, so don’t take it for hard information. I’ve woven in a couple links, though.
Who I am
Java developer since 90’s
J2EE since Struts 0.5
Worked as programmer for university, .com, government
What the show format is
Cover interesting topics, many of them as they’re emerging
Mainly my own experience and my reading: get what I think is a decent overview
I wanted something substantive to listen to on the way to work or somewhere else
10-20 minutes
Split topics across shows often
Perhaps have a basic theme for week
EJ classes
90 minutes, 3 times per week
Spring IoC: Basic bean factory
Allows for creation and wiring up
Gives you home theater components instead of an all-in-one
Encourages interface programming
Can/should replace config file
Eliminates creation and relationship code, allows object to focus on its reall purpose
Moves dependency definitions to configuration
Dependencies
Variable type (Comcast comcast)
Constructor choice (new Comcast())
Variable methods used (comcast.connect(), comcast.sendSpam())
Getting rid of dependencies
Change variable type from concrete class to interface (Isp isp)
That eliminates dependency on variable type
That also standardizes the methods used — (isp.connect(), isp doesn’t have sendSpam() call). This may require changes to your code. You see this recommendation when using Map vs. Hasmap.
Remove constructor call and replace with set method.
Lets object creation be someone else’s problem
Your object is now dealing simply with how to get its work done and collaborate with other objects.
This has a really cool side effect: you’ve now made it really easy to use mocks of your Isp during testing instead of a real implementation.
About a year ago, we were using jWebUnit, which is an API built on HttpUnit — which in turn is very similar to HtmlUnit. We used it in conjunction with DbUnit to load the database tables before the test and verify them after. It worked really well. We had tests that could verify the operation properly manipulated the database, and could check the structure of the HTML returned.
We went away from it mainly because functional tests could only be written by programmers with that method, and with JMeter we could have someone a systems analyst or a tester write the functional tests. Using the proxy recorder available in JMeter let a user click through the test and replay it. JMeter could load the DB and check it based on CSV files, instead of XML. In the end I think the flexibility is a little less, but the number of people who can help get the work done has increased.
