...
var ninja:Ninja = new Ninja();
ninja.meditate()
       .levelup()
       .save();

Sweet and to the point if you ask me. Perhaps this is not directly named domain driven design but just plain Object Oriented Programming using the Tell don’t ask principle. Frankly I don’t care that much. Potato, potato. But what happens in save? One should guess there will be nullpointers all over that ninja if using some service/repository for saving him(or her). Or is it magically injected a repository using Swiz or Parsley maybe? No. That won’t work. Swiz and Parlsey doesn’t have the skills to inject dependencies during simple instantiation of objects. Hardcode the services right into the Ninja? Well that’s just nasty in so many ways. And if you have some guys who is into that test driven development you’ll quickly get a taste of nasty.

Why?

Itemrenderers. Yes. These little guys. Every Flex developers first nightmare.

This DataGrids dataProvider is a collection of Ninjas. Usually the itemrenderer for the Action column is implemented by the button either throw an Event containing the Ninja selected to do something with or injecting a service for Leveling-up and one for Prepare-for-mission into every itemrenderer. This causes most of the times a lot of duplicated code as well as hard-to-track code because you have to search the code for whom ever is set to eventListener for that event you’d be throwing. And injecting the services in every itemrenderer? Try looking at that performance when having a gazillion ninjas at your helm.

Proposal?

I say: Hello good ol’ Singleton! Give the Ninjaclass reference to the LevelUpService. I recently started using something like this

public class Ninja{
    private function get levelUpService():LevelUpService {
        return ApplicationContext.getObjectByType(LevelUpService);
    }
    ...
    public function levelUp() : void {
         levelUpService.levelUp(this);
    }
}

The singleton(ApplicationContext) is just a selfmade class with static methods and a static final map which contains all the objects in the context.
Or to say it in more understandable terms:

public dynamic class ApplicationContext {
    internal static var objects:Dictionary = new Dictionary();
 
    public static function addObject(object:*, id:String = null):void {...}
    public static function getObjectById(id:String):* {...}
    public static function getObjectByType(clazz:Class):* {...}

The various object/beans or whatever you would like to call them I usually create using Swiz/Parsley and then use the addObject to the context. Using this approach I can now tell the ninja what to do, not pass him around from class to class just so he in the end can be leveledup by a service. Also the ninja can add extra ninjatrix so that he update his own state. For example add a callbackfunction to the levelUp-method and then update an useful isLevelingUp flag. Everything behind the scenes for the itemrenderer and making it possible for every component to bind to the isLevelingUp.

Sum up, drawbacks, example

What I’ve kind of created here is a very small and very basic dependency injection framework. I believe it even would work on very small projects. The big drawback of this code is of course the rock hard reference to ApplicationContext. It means that wherever you want to use the Ninja class and code using the ApplicationContext is also used, you have to instantiate the ApplicationContext with the necessary objects/services. In tests you can just mock it away, but when bringing the code to other projects you’ll have to set up the ApplicationContext. Also, once you go down this path of singleton ApplicationContext, turning back in the future and throwing out your code and returning to event-throwing etc is quite a handful.

Anyways, how about how I implement the ApplicationContext? An example you say?
Try Tell Dont Ask swf for size. It’s an extremely simple Ninja-example showing injection of services and the ApplicationContext code. The code is zipped up and ready for you here.

public class InternettFasade{
...
public String leverAnmeldelse(Anmeldelse anmeldelse){
    return anmeldelse.sendFaxTilAnsvarligPolitiDistrikt()
                     .sendEpostTilPolitiDistrikt()
                     .sendBekreftelseEpostTilAnmelder()
                     .lagre()
                     .referanseNummer();
}

Sterkt preget av min egen lille forståelse av Domain Driven Design så passer sånn type kode meg ypperlig. Noen vil sikkert arrestere meg og si at i DDD så er det ikke opp til entitetene selv å drive å lagre, men jeg liker nå det engang sånn. Skader det så mye også egentlig? Sikkert masse annet jeg har bommet på med DDD også. Når jeg først har slike fine entiteter/modeller så synes jeg det er storveis å bare sende de rundt omkring hos forskjellige fasader og servicer helt uten å tenke meg om de har injisert de riktige repositories/servicer/validatorer osv, osv.

Til å begynne med gjorde jeg injiseringen i forskjellige factories som populerte entitetene med det nødvendige. Etterhvert bli disse factories’ene ganske kompliserte. Selv fikk jeg i alle fall lyst til å ordne det slik at det var bare disse factories’ene som fikk lov til å opprette domenemodellene. Da først snakker vi om skikkelig kontroll. None shall pass og one factory to rule them all. Og straks har jeg litt ekstra uønsket kompleksitet og kode. Huff. Derfor ble jeg ganske interessert i å finne ut hva denne Spring load-time-weaving var for noe. Og kunne det gjøre akkurat det samme som en factory? Bare behind the scenes? Joda. Såklart. Hvorfor hadde jeg ellers giddet å skrive denne bloggen? Here’s how!

Hva?

Load-time-weaving er i korttekst runtime instrumentering av klassene dine. Det er slik fancy AOP som legger seg rundt objektene dine og slår inn straks noen prøver seg. Prøver seg i dette tilfelle med Spring-ltw er rett etter du har opprettet et AOP-instrumentert objekt. Jeg kan illustrere med et kodeeksempel

@Configurable
public class Ansatt{
    @Autowired
    private AnsattRepository repo;
    @Autowired
    private EpostService epostService;
    ...
    public Ansatt lagre(){
        repo.lagre(this);
        return this;
    }

Her har vi først fortalt at klassen skal instrumenteres runtime av Spring vha annoteringen @Configurable. Det som skjer nå er at hver gang, og hvor som helst i koden, det kjøres en new Ansatt() så vil Spring hoppe inn og injisere EpostService og AnsattRepository fra konteksten sin. Det gjelder ikke bare koden du skriver, men også knæshe xml-to-java bibliotek og lignende. Så nå blir det fullt ut mulig å gjøre for eksempel dette:
new Ansatt(ansattNr).giSparken().sendSluttPakkePaaEpost().lagre();

Hvordan?

Hvordan er like enkelt som å skrive new Person(). Vel.. Nesten da. Kors på halsen. Det første du må gjøre er å bruke Spring. Hvis du har slengt på @Configurable så mangler du en slik en i Spring contexten din:

<context:load-time-weaver />

Da begynner Spring straks å mase om at den mangler en java-agent. Det er et annet ord for instrumenteringen som er det siste du må fikse. Det kan du gjør på forskjellige måter:

Java argument

For de fleste tilfeller må man sende inn java agenten som et java-argument. For eksempel for å starte den superenkle og populære Jetty sender du inn Spring sin java-agent gjennom Maven slik(Linux):

export MAVEN_OPTS="-javaagent:$HOME/.m2/repository/org/springframework/spring-agent/2.5.6/spring-agent-2.5.6.jar"

Og da er det bare å mvn jetty:run

Tomcat, GlassFish, Oracle OC4J, WebLogic

Apache Tomcat

<Context>
<Loader loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader"/>
</Context>

For at dette skal fungere så må Tomcat innstallasjonen kjenne til klassen TomcatInstrumentableClassLoader. Dvs du slenger
spring-tomcat-weaver.jar i lib katalogen til Tomcat, og vips - tilgjengelig java-agent! DET burde ikke være vanskelig å overbevise drift om å tillate!

Testing

Eclipse

Skal du teste at load-time-weaving koden din faktisk injiserer objektene som du håper må du også her tilby en java agent. Det gjør du ved å redigere vm argumentene til den testen eller koden du skal kjøre. Dette finner du under Run=>Run Configurations=>Arguments
Der mangler det en slik:
-javaagent:"${USER_HOME}/.m2/repository/org/springframework/spring-agent/2.5.6/spring-agent-2.5.6.jar

Maven

Ønsker du å kjøre enhets- eller integrasjonstester som bruker load-time-weaving så redigerer du argumentene for surefire-plugin slik at den instrumenterer likt Eclipse. Det kan du gjøre slik:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<configuration>
		<forkMode>once</forkMode>
		<argLine>
			-javaagent:${settings.localRepository}/org/springframework/spring-agent/${spring.version}/spring-agent-${spring.version}.jar
                </argLine>
		<useSystemClassloader>true</useSystemClassloader>
	</configuration>
</plugin>

Alt vel i paradis?

Veeel... Det koster litt. Skal du opprette en drøss med objekter så går det atskillig raskere å gjøre det på gamlemåten med en Factory. En helt enkel test jeg gjorde viste at med en Factory fikk jeg laget 200 objekter på samme tid som det tok å lage ett @Configurable objekt. Så hvis du får en case med å opprette tusen på tusen av objekter med et hardt krav til responstid så må du kanskje være litt oppfinnsom. Personlig har jeg ikke erfart at load time weaving har gitt merkbart dårligere responstid.

En ting som kanskje er enda litt mer irriterende for deg som sitter og utvikler load-time-weavet kode er at du ikke kan bruke det sammen med ditt favoritt mock rammeverk. Den ene utsletter dessverre den andre og plutselig fungerer ingen tester. Det mock-rammeverket ditt trodde var et Person-objekt er ikke lengre et Person-objekt etter ltw. Nå er det et cglib objekt som utgir seg for å være et Person objekt. Personlig har jeg ikke funnet en smart måte å omgå dette på, og endt opp med å ikke teste med load time weaving men heller sørge for at enhets og integrasjonstester dekker det som dekkes skal slik at det blir middag.

For de som har lyst til å leke litt med load-time-weaving eller bare se et kjempeenkelt eksempel så har jeg snekret sammen et lite kodeeksempel her:
http://github.com/judoole/ddd-ltw-spring