Sunday, March 15, 2009

Qi4j == Magritte + Traits + OODB + Newspeak

I recently came across the opensource Qi4j project which has Rickard Öberg co-founder of JBoss as one of its core developers. Now I haven't gone into a large amount of detail, but I have read the tutorial and some examples and although I see the benefit, I feel Java as the implementation language was definitely the wrong choice.

If you are going to try predict the future and the best way is to invent it then why cripple it with Java? Ok so thats a little harsh but look at the examples and tell me if you can see the domain code easily, Java is just not expressive/malleable enough to make it read well and Qi4j's meta-descriptions (as annotations) are not extensible or dynamic. In my opinion this limits its power.

Qi4j == Magritte + Traits + OODB + Newspeak

Magritte
...is a meta-description framework, describing domain classes and their respective attributes, relationships and constraints.
With Magritte you can describe your domain model similar to what Qi4j is doing. A major difference is that Magritte is self-describing and the meta-model is modifiable at runtime. So since you can describe your domain you can do things like object persistency, indexing, reports and views etc. and having this meta-model would allow one to create an optimised OODB (ROE?, Gemstone) persistence facility or a relational database mapping scheme (GLORP).

The mixin and behaviour separation constructs in Qi4j remind me of traits which arguably is a better form of behaviour composition.

The Qi4j application 'assembly' steps remind me of Newspeak's nested classes and module system.

I appreciate the ideas that Qi4j is trying to achieve but believe they are most likely wasting lots of developer 'cycles' trying to wrangle Java rather than coming up with some innovative ideas. A dynamic, fully reflective OO lanaguage (like Smalltalk :)) would be better suited to their needs as it would allow them to focus on their 'domain' which is building a DDD enabling framework.

Friday, March 13, 2009

Are you an OO Bigot? Time for a different modeling technique maybe...

After reading through a blog entry which basically centered on 'Reducing cost by using OO principles'
it made me realise that there is the danger where we stick to our ways and preclude lots of other valid design and modeling choices. The author describes how he has been described as 'over object orienting' solutions. I feel it happens to many of us, and when people are telling us this it may be a valid flag that we are over-generalising and therefore over-complicating our design
i.e. typically the more generalised the solution the more 'mental hoops' the readers of the code will have to go through to understand it. It might be time to use another modeling technique, function oriented, rule based etc.

BTW I'm not implying that the referenced blog entry is wrong in saying that OO design can reduce cost but what I do think is that cost can be measured in many ways.
Yes there are cost 'reductions' in being able to localise code change as to me one of OO designs strength's lies in the ability to package behaviour and state.

This 'hopefully' reduces the cost of change as the state changing behaviour should be localised in a few key areas (depending on how deep the change 'cuts across the grain').

But here lies the rub; OO works well when the object model lies close to the actual real world 'object' or metaphor that it is modeling.

What I mean is that OO designs favour mental models where we can safely imply what the expected behaviour is of an object and not have to dive into the details.
In this way users of our code can safely modify the code (tests help to verify that the known behaviours still work after the change but they don't verify all possibilities, just the ones the tester deemed important).

OO design does not lend itself to composing of behaviours because it has to typically deal with state. Users of the object need to understand the messages that the object can react to and what the intended result of the message is. They don't need to know how it is done just that it will be done, but this limits how you can compose behaviour because the timing of calls is important.

Functional languages and designs would (and by no means am I an expert) favour applying functions to a data structure (and to other functions ala higher order functions) that transform the data safely and typically are side effect free.
This is crucial to being able to compose behaviour as you can apply the function to data over and over again knowing the result will be the same. Nothing changes that behaviour, there is no concern of state to add to the stack of your 'conceptual model'.

I believe (and not from first hand experience) that it falls down somewhat because it lacks powerful logic structuring mechanisms. i.e. it's hard to keep track of the transforms and group/package them, the function may be too coarse and have to be broken down into 2 or more functions; or it may be too fine grained and therefore be more difficult to understand how the transforms fit together i.e. to get a desired result which set of transformations should I use.

Ok example time, I'll use working with collections of objects in Smalltalk and Java
Say we have a business requirement to contact patients who are in arrears at a medical practice.


kindReminder := [:account | account dueDate > (Date today + 30 days)].
slightlyOverdue := [:account | account dueDate > (Date today + 60 days)].
veryOverdue := [:account | account dueDate > (Date today + 90 days)].

'this is a function that emails a contact with a message'
email := [:contact :message | Email mail: contact with: message].
'email the patient'
emailPatient := [:account | email value: account contact value: 'overdue'].
'leave a voice mail on their phone'
leaveVoiceMail := [:account | PhoneService leaveVoiceMailFor: account contact saying: 'overdue please call us'].
'apply the normal email function to the patient and then make the lawyers aware by sending the same email sent to the patient'
emailLawyers := emailPatient ensure: [email value: lawyer contact value: emailPatient value asMessage].

'apply the functions to the data'
Accounts findAll select: kindReminder thenDo: emailPatient.
Accounts findAll select: slightlyOverdue thenDo: leaveVoiceMail.
Accounts findAll select: veryOverdue thenDo: emailLawyers


OO would be cleaner to the eye, we could do something like:

List inArrears=Accounts.findAllInArrearsByAtLeast(Days.from(30)); // 30 days
for (Account account : inArrears) {
account.notifyInArrears();
}

public void notifyInArrears() {
ContactStrategy.createArrearsStrategyFor(this).contact();
}

// ContactStrategy factory method would create the relevant strategy based on the account dueDate etc


The 'functional style' (kind of, it still is Smalltalk) is more amenable to composition of behaviour safely by using higher order functions.
The OO style is separated cleaner so change is easier to localise but extension points are harder to 'mould' in unless hooks were provided already.

Now to get back to some kind of takeaway from this rambling post :).

OO is great to factor behaviour;
...In Smalltalk, nothing ever happens here...
'nothing ever happens here behaviour' (I think Adele Goldberg said that about Smalltalk/OO design) though means that typically understanding the model is more complex. There are just more moving parts with state and everything seems to happen elsewhere.

Functional design favours transformations where we know what the input and output are meant to be, so we can compose behaviour more easily which is a very powerful tool.

I feel a blend of styles would be best, something akin to the Smalltalk example but putting most of the logic behind intention revealing methods, and using the powers of functions (closures) or even Traits — Composable Units of Behavior to compose certain behaviours.

The ultimate goal for me when designing a solution is that it must be readable, understandable and therefore easy to change.

Sorry about the long rambling post...if you made it here...well...wow

Tuesday, March 3, 2009

Smalltalk: power of simplicity and personal mastery

One of the principles stated in Design Principles Behind Smalltalk by Daniel H. H. Ingalls which appeared in the BYTE Magazine, August 1981 was that the Smalltalk project had a bias towards:
Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.

Well my Smalltalk is not great, I have read some of the free books on Stephane Ducasse's website, and yet I still find Smalltalk to be intuitive and easy to do things with. I'm not sure if it was the way the language was designed, the class design (libraries) or a combination of the 2.

Let me give a simple example, but first a disclaimer; I could have used excel or some other mechanism to do this but it was more of a learning experience.
Ok so basically I had 2 CSV reports that i had run on 2 environments that I wanted to compare to make sure that there were no differences. Thats really simple and I didn't explore many options, I just fired up Pharo and started typing into a workspace:

firstReportList:= (CSVParser parse: (FileDirectory default readOnlyFileNamed: 'resources\first.csv')).
firstReportList := firstReportList asOrderedCollection.
firstReportList allButFirstDo: [:entry | entry at: 5 put: nil.].

secondReportList := (CSVParser parse: (FileDirectory default readOnlyFileNamed: 'resources\second.csv')).
secondReportList :=secondReportList asOrderedCollection.
secondReportList allButFirstDo: [:entry | entry at: 5 put: nil.].

Transcript clear.
Transcript nextPutAll: (liveList = wareList) asString; cr; flush.
Transcript nextPutAll: firstReportList size asString; cr; flush.
Transcript nextPutAll: secondReportList size asString; cr; flush.


CSVParser was a small nifty library by Avi Bryant that I had previously loaded in my image. The line firstReportList allButFirstDo: [:entry | entry at: 5 put: nil.]. was put in to ignore the heading on the first line and then for all the other rows blank out (by making it nil) a column that was deliberately different in the 2 files with which I did not want to compare.

Now firstly how sweet is that!
Secondly I didn't get any differences so I was happy with the code i.e. I didn't have to write code to spit out the differences although I feel that would have been trivial.
Thirdly try doing that in my staple language Java...umm no thanks...I know its possible but not as succintly as Smalltalk. I'm sure Lisp or Perl would have a nifty way of doing this, and probably Smalltalks distant cousins offspring Ruby.

I can't wait for what Daniel Ingalls ended the article with (I think many people want to be part of this too :) and its not Ruby )
Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones.


On another language note I see the Lift web framework written in Scala was released, I took a very brief look at some of their examples and I was not impressed with the mental hoops it took to make it do something simple. Seaside seems simpler to grasp and as expressive if not more....but I'd still need to look at it in more detail.