A common complaint I hear about constructor injection is “I don’t like having so many constructor arguments”. Yup this crossed my mind when I first came across it too - then it dawned on me: perhaps having too many dependencies injected into a class is a code smell? How many other classes should this class be collaborating with? Am I missing an abstraction in my model? Many times I’ve looked at a class and simply by looking at it’s constructor signature I’ve had a nagging doubt about it’s hygiene.

A big reason I prefer constructor injection is that I can ensure that when an object is constructed is ready to do it’s job. I do not have to concern myself with whether the class has been ‘wired’ correctly in configuration and that all dependencies have been met. If I introduce a new dependency, I can find all places in the code (and pretty quickly in configuration) where I’ve caused a breakage.

However it’s now 2009 and I’m still (occasionally) writing java, but pretty regularly I’m in a team that has settled on setter injection as a standard. It’s the default option in the Rod Johnson scriptures I guess. I also believe in most cases it’s better to be consistent than argue what some see as a fine point, so again I fall into line and am forced to use setter injection. But I do want to bitch about it.

How about this test setup code:

        WidgetGetter widgetGetter = new WidgetGetter();
        widgetGetter.setHttpClient(new HttpClient());
        WeeResourceFactory resourceFactory = new WeeResourceFactory();
        resourceFactory.setWidgetGetter(widgetGetter);
        resourceFactory.setSomeParameter("the quick brown fox");
        FooRepository repo = new FooRepository();
        repo.setBarFactory(new BarFactory());
        repo.setResourceFactory(resourceFactory);

versus this?:

        WidgetGetter widgetGetter = new WidgetGetter(new HttpClient());
        WeeResourceFactory resourceFactory = 
            new WeeResourceFactory(widgetGetter, "the quick brown fox");
        FooRepository repo = new FooRepository(resourceFactory, new BarFactory());

I’m also into configuration in code rather than in XML, but I worry I’ll get burned at the stake if I bring THAT up again.

IF IT ALL GOES HORRIBLY WRONG DON’T BLAME ME!

What I didn’t mention in my post is that the first time I installed vmware and loaded up the windows partition it worked great.  Then I was tooling about in windows (I think uninstalling some cruft) and it required a reboot.  No worries, but then my attention drifted and I went off to another desktop on the linux host.  When I looked back a few minutes later I realised in great horror that the vm had automatically booted via GRUB into the ubuntu partition.  I was looking at the ubuntu login screen, in a vm running on the same ubuntu install.  Nasty feeling.  Power off button on the VM.

Too late - everything in the running host OS started to unravel and I quickly crashed and burned.  Someone in the audience will probably pipe up at this point and say “you could have recovered by xyz” but after a couple of people had a poke around with no success I took the quick route and reinstalled ubuntu again.

Not recommended…

Luckily the windows partition was untouched.

I love Linux (and particularly Ubuntu) as a working environment. Most of the applications I’ve worked on in the last 10 years have been deployed on a flavour of unix, and despite doing a lot of Java I also do a lot of scripting and glue code, build and deployment tooling in particular. Working on Windows even with cygwin is just a world of pain.

Unfortunately I’m not able to avoid Microsoft Outlook *sigh*. I spend more time in meetings than I care to admit, and I regularly have to set up meetings with invitees and meeting room resources. Webmail doesn’t cut it. Evolution really doesn’t cut it for much more than reading mail - even sending mail it’s a bit flakey. Great effort, I really hope one day someone gets involved who can make it stable.

So what I and some others are doing is running VMWare Server under Ubuntu, booting the physical Windows partition from disk. When I installed Ubuntu I resized the existing single partition and left the client SOE Windows installation fully functional. It works incredibly well booted under VMWare once everything is loaded - we run Outlook 2007 which is slow as a dog even non-virtualized - and I’m never going to look back. The best part is if I ever NEED to I can boot the same partition directly.

It’s a little tricky getting VMWare Server to run on Ubuntu, as you have to apply a patch (vmware-any-any) to make it install. I followed the instructions here on howtoforge, and they worked on Hardy. I found I had to run vmware-config.pl twice - once when the patch is applied, and then once more to make it work properly.

Once VMWare is installed it is important to boot under Windows directly, and set up a new hardware profile for “virtual boot”. When you boot Windows under VMWare the first time, choose the virtual boot profile. It will detect a bunch of new VMWare hardware, which will then be associated with the virtual boot profile. This means when you boot directly for some reason later, you can choose the default boot profile and everything will work as it always did.

I’m stoked at how well this works. I have VMWare tools installed so that it gives focus to Windows when I move my mouse over the VMWare window (no Ctrl-Alt-Esc). Highly recommended.

I’m frighteningly similar when it comes to writing code on my desktop machine at home - of course there are 227 incoming critical updates from ubuntu.  Or maybe I need to upgrade from Hefty to Iggy (or whatever).  Of course my Eclipse is 3 versions out of date, and I couldn’t possibly use that Java version (or ruby or pascal, or whatever it is I use these days).  By the time I get everything up to date I’ve usually forgotten what it was I came upstairs to work on anyway.

They’re my habits and I love them.

Like at user group nights and conferences I’m awkwardly shy and awful at striking conversation so I missed talking to a lot of interesting people today. It’s a different mix of people than I’m used to (like the Ruby user group) with a slant towards freelancing and smaller projects which is so refreshing compared to the behemoth corporate beasts I’m more familiar with these days.

Favorite presentations today: Mark Ryall’s Intro to Scala (second time around), and Paul Fenwick on an Illustrated History of Failure (with sound effects).

I winged a short demo of the Rspec Story Framework which is my current shiny-toy-of-the-week. I might have been better placed to answer questions if I’d actually used it in the wild yet…

Don’t miss BarCamp Melbourne 2009.

At the ER they put me in a room and gave me a dose of Morphine. Morphine is a very nice drug. It had the effect of filing the pain away in a convenient subdirectory where I could access it if I needed it, but was otherwise out of the way.

Brilliant description. I recently had a healthy diet of Morphine for a couple of days (followed by a few more days of oxynorm, which is similar). After my first dose of Morphine the emergency doctor came to see me and I couldn’t help grinning like a loony, despite the horror of my injury. Good stuff when you need it.

When I’m evangelising the use of Entities, Aggregates, Value Objects, and Repositories, one question that comes up regularly is “what’s the difference between a Repository and a plain old DAO?”. It’s a very good question with the right level of skepticism.

I really enjoyed reading Christian Bauer’s post “Repository Pattern vs. Transparent Persistence” - particularly the title which implies that there is a choice to be made between two approaches. In actual fact transparent persistence as implemented in Hibernate makes DDD and the use of Repositories extremely powerful. I’ll backtrack a little…

A lot of web application code that I find these days that was written with ‘best practice’ of just a few years ago follows a rough outline like this. DAO objects (or Data Mappers) provide find/save/update/delete operations methods for each object in your domain. The DAO is a basic abstraction around database persistence, often JDBC.

Business logic is usually either written directly within Transaction Scripts (recently I’ve become used to inheriting hundreds of lines of code in Struts actions… *sigh*) or within a basic Service Layer. The script or service is the only thing that can hold references to the DAOs, so of course you HAVE to put the business logic there - in most web apps there is a lot of creation and persistence of objects. No problem, we’ll just divide and conquer - from our scripts we’ll extract services, then we’ll divide our services into more services and delegate between them.

Because the application does a lot of operations requiring persistence, there’s a natural force preventing any business logic being moved to anywhere but scripts or service layers. So what are our domain object? Nothing but structures carrying data, with maybe some rudimentary logic that only affect local state. The client code asks the domain to provide it with data, and then the client code makes decisions based on that data.

The transaction script and service layer approach is simple to begin with, but as the application becomes more complex it leads to a bunch of problems, especially as developers try to avoid duplication (cut and paste is bad kiddies). Ever picked up a hierarchy of Struts actions seven layers deep with multiple Template Methods to allow overrides for different sub-classes? Bloody nightmare.

What I’ve achieved by applying the DDD patterns is the elimination of those transaction scripts and (most) services. The transaction script (e.g. struts action in a web application if you’re so inclined) is simply responsible for finding an appropriate entry-point into the domain, then telling that domain class to do some work.

The consequence is that business logic can be expressed more deeply in your domain, you are free to find the right abstractions that will allow you to make your code understandable, and to create small classes with single responsibilities.  This also means that the creation and persistence of objects will be deep in the bowels of the domain, and even better - without the calling client code or script HAVING to be aware of the object creation.  How can this be?  Domain classes aren’t allowed to hold references to DAOs - that would break our traditional view of layering.

But… when I apply DDD, Repository and Factory interfaces are part of the domain.  This is a fundamental change - that a domain object deep in an aggregate can be constructed with a reference to a Repository in order to look up persistent data.  That a domain object can also use a Factory to construct objects, hiding the detail of construction (and dependency injection).  None of this work has to be done in a transaction script or script - move that responsibility into a place in your domain where it makes sense.

Repositories can be used to perform lazy instantiation of relationships in a persistent graph of domain objects.  E.g. retrieve a PurchaseOrder from the PurchaseOrderRepository, when the PurchaseOrder requires it’s line items it asks the LineItemRepository for matching line items.  A consequence is that this will lead to a bunch of Repositories being created in a complex model.  It’s simpler (less code) if you can use a tool like Hibernate to manage persistence of the entire graph, and configure it to automatically instantiate collection relationships lazily.  Nothing about Repository prevents you from doing that - you would just eliminate the use of Repository at that point and use the collection directly.   Hibernate is no solution to fit all problems however, and we commonly find places where explicit use of a Repository is cleaner.

I also deal with a lot of ‘legacy’ code that needs to be renovated into submission - often a safe path with JDBC code is to refactor towards the use of Repositories and moving the use of those Repositories into the domain to make it more understandable.  Often the JDBC code inside the Repository implementation does not have to change much.  When it does later on, you have the opportunity to make a shift towards a technology like Hibernate.

Transparent persistence and the Hibernate Session is a really important tool for implementing a rich domain model - if we make our client code (transaction script, service) as thin as possible, it is no longer responsible for remembering which objects have been updated and saving them back to the database.  Instead we use the Hibernate Session as a Unit of Work - our client code tells the domain to go and do something and the domain can go ahead and perform calculations, validate data, and update fields as need be.  When the work is complete we tell the Session to commit and it works out what needs to be updated in the database.  Brilliant - now if we add more complexity to the domain we don’t have to add matching complexity to our client code, and not in multiple places.

Christian is very concerned with adding additional layers into our code - a Repository wrapping a DAO.  I personally do away with the DAO idea altogether - the Repository implementation is performing the same thing.  The important thing is that the Repository interface (e.g. PurchaseOrderRepository) lives in the domain, and the implementation (e.g. JdbcPurchaseOrderRepository or HibernatePurchaseOrderRepository) lives outside the domain in infrastructure.

Conclusion (otherwise I’ll go on all day):  let go of the idea that domain classes must not interact with a database (or a message queue or a file system) - free them to do their responsibility, just make sure they do so through an appropriate domain abstraction - Repository and Factory are good examples.

Oh - and stop using Struts (1.x anyway).

The forum itself was mostly interesting - I don’t really identify well with the title “Architect” although that is a large part of the work that I do. I find that most software architects seem to struggle to remain relevant as they get further divorced from project delivery. For this reason I found my colleague Gianny Damour’s discussion group on “The role of the architect on agile projects” most entertaining as he described architectural practices found to be questionable including “pretentious modelling”, “over technical design” and “ivory tower mentality”. It definitely sparked a healthy debate, especially the assertion that architects should code.

Much less amusing was a discussion group by the local chapter of the International Association of Software Architects that was preaching _certification_ as the answer to peer recognition of your mad architecting skillz. That and several hundred pages of an “IT architect skills library”. I think the secret architect handshake is detailed in UML 2.0 on page 259. Forgive my skepticism.

Overall though a successful forum - congratulations to the organisers!