1 May 2004 (updated 1 May 2004 at 09:56 UTC)
»
Many things to note, grouped by categories
Object Oriented Design and Layers
Nowadays everybody knows that a well architectered application consists in a set of layers (such as UI - Model - Database)and a well designed object oriented model. Even I do! Since I am teaching Programming Methodology I have tried to put together some nice tiny examples of object oriented layered architectures, and I have found that actual programming languages are not well suited for this need. If you do a good object oriented analysis, you will end up with an object model. This object model reappears at the three different layers. That, let's say I am implementing a TODO-list management program. I will have a UI layer Task and a Model layer Task, both containing the description of the task. Furthermore, if I make an inheritance hierarchy such that ImplementationTask inherits from Task and so does DesignTask, I have to repeat this inheritance hierarchy at every layer. Sure there will be objects specific for each layer, but most domain model objects will be present in all of them.
After thinking for a while I see two solutions to this:
- Using a programming language that allows open classes. In Ruby you can think of having one (or a set of) .rb file for each layer. Since we can add functionality to objects, the UI layer will just reopen the model layer objects and add the UI related functionality. Since the model is implemented in separate files, there is no dependence between the model and the UI, but the UI shares the model object model. Drawbacks are that classes are to be open at every layer.
- Providing usual OO languages such as Java with a construct and semantics to deal with layers and create an IDE that works with such constructs. While decoupling more and more from the filesystem, our way of programming and thinking of independence in programs is still very much influenced by how we store our code into files. In Java, for example, many times we assume everything under the same .java file as interdependant. We can break this by introducing (for example) a layer keyword that separates the different parts of the object that implement services for the different layers. So we will have something like
public class A {
layer Model
//Model functionality
layer UI
//UI functionality
}
Plus a file layers.xml for the complete application, describing the dependencies between the layers.
The IDE will know which layer we are working in and will show :
- The underlying layers as blackbox services (just the methods we can call, not the code)
- The code of the layer we are working in
- Nothing about layers that we do not depend on
Mass spectrometry classification
Finally I have found some GNU software and a reasonably well written article about mass spectrometry classification.
Network programming
J2EE sucks.
Reviewing
I have been reviewing papers for several conferences and workshops this week. Undoubtedly, GTDT04
papers were the most interesting and high quality. I will be really sad if I am not able to be in NY.
Family matters
Next Thursday I am driving to Seville to see my little niece. I will be back on Barcelona on Monday.
ZF inconsistent
fxn, I cannot reach the paper. Do this means we can now positively confirm my long time unproven theorem that 2+2=5? :o)