Thu 22 Jun 2006
The Luca Class Model - and what it means
Category : Technology/LucaClassModel.txt
I generated this class model diagram from within Xcode. It shows a portion of the Luca class hierarchy. I was going to draw this manually when I remembered that Xcode has this feature - so, with just one click, it's done :
We've ported Luca, from its beginning as a 4th Dimension (4D)-based application, through PHP, Java, Java-Cocoa, and now to Objective-C, all the while using it to learn about the capabilities of each language.
While MailServe and DNS Enabler were technically difficult because of the need to know enough Unix, these were single-window applications, after all.
Luca is a better example of a real-world business application. It gives us a chance to see how well an object-oriented language like Objective-C performs when we use it to model real-world business processes.
The point is, you can use an object-oriented language like Java or Objective-C without using any of its object-oriented features. Until Luca version 2.1 (that we've just released), Luca was a straight port from its 4D days, and its code was largely procedural, except where we make the Cocoa calls.
Luca 2.1 was where we try to take advantage of the underlying object-oriented language. For example, we recognise that a Balance Sheet or Profit/Loss report is a special case of a Trial Balance report, and we factored the code so that we make one a sub-class of the other.
What we've found, from re-organising the code this way, was that we can cut down the total number of lines of code in the project by half, through elimininating a lot of repetitive code (by making specialised code inherit the behaviour of more general-purpose code).
What this says is that people can, and do, teach the use of Java, etc, in colleges and universities, without exploiting its power as a modelling tool. And even when they do, they miss the point, for want of good examples. How many polytechnics or universities teach the Mac as an example of good object-oriented design? Yet I know, for sure, that we had actually learnt a lot about how to build our own classes from observing how well the Cocoa classes work. The Mac has been largely ignored in the IT (as opposed to art/design) curriculum and the IT industry everywhere remains all the poorer, in terms of imagination, for it.
The second point I'd like to make, through the Luca example, is that IT is a very hard activity to manage. How would a mere "human resource" manager know that the number of lines of code that a programmer writes is a very tricky indicator of programmer productivity and ability?
"The best code is the code you don't have to write", so says Steve Jobs famously while introducing (what became) Cocoa to the Mac world, because each code we write introduces a possibility for error. The best programmer will use the least number of lines of code to do the most number of things, without sacrificing readability or maintainability of the code. Lines of code get whittled away by the quality of the thought.
But which manager, weighing the lines of code each programmer produces, will be able to tell the good guy from the bad?