Thursday July 03, 2003
Finishing the metrics component, considerations on checked exceptions
My objective today is to finish this component once and for all. Then I will document the use and deployment next week.
--------------------------------------------------------------------------------
I am still wondering about the checked exceptions debate. I feel I can hear arguments from both sides:
-pro-runtime exceptions : avoid catching exceptions without doing anything valuable
-pro-checked exceptions : formally declaring what could go wrong when using an interface.
I may incline for the runtime camp, but I think the exceptions that can be recovered from by interacting differently with the interface should be at least documented (and then may be checked exceptions).
In UML2.0, there is a notion of Protocol. It is not enough to declare as contract what are the operations/ parameters/ pre-postconditions that the interface has, sometimes, the order on operations calling and parameters values are also very important. A protocol state machine can then be linked to an interface (or any classifier) in order to declare more precisely what can be its behaviour.
The conclusion of this is that: if an exception thrown by the interface contains enough information for the caller to resume the protocol execution, then it could be a checked exception.Eventually, in my case, practise is what I need,... code with both runtime and checked exceptions and the rules will follow. ($entry.pubTime) # [Edit]
Tuesday May 20, 2003
Context switching
--------------------------------------------------------------------------------
I would like to note some of my ideas regarding "Context Switching".
What is it ? It is a common fact observed by any consultant or programmer : it is quite hard to work on something, being interrupted, then to resume on the work to do.
The questions that arise are :
How is it possible to resume faster ?
Is it possible not to be interrupted ?
On the other hand is it possible to completly switch context, so that private life is not parasitized by work ? And many more question that I dont have time to write right-on !
(2003-05-20 16:30:00.0) # [Edit]
Friday May 16, 2003
Streamlined Object Modeling
--------------------------------------------------------------------------------
Here is a message I wrote on the french XP mailing list about this great book :
--------------------------------------------------------------------------------
Bonjour à tous,
Puisque l'on aborde le sujet des livres, je souhaiterais vous faire partager ma dernière lecture :
Streamlined Object Modeling: Patterns, Rules, and Implementation
de Jill Nicola, Michael Abney et Mark Mayfield
Cela sort au départ un peu de la programmation puisqu'il s'agit plutôt de patterns d'analyse objet (objets métiers, régles métier).
En revanche, lorsqu'il s'agit d'implémentation, le livre aborde une question qui me paraît très intéressante :
Quand une régle métier porte sur 2 objets (la possibilité de les associer par exemple) qui porte la régle?
C'est à ma connaissance, le seul livre qui donne des régles explicites sur le sujet. Globalement, la réponse est connue de tout développeur objet (consciemment ou inconsciemment):
celui des deux qui possède le plus d'informations pour vérifier la régle.
La vraie force du livre est de poser la question pour chacun des 12 patterns de base qui sont présentés.
J'ai trouvé, à la lecture de ce livre (en particulier les premiers chapitres), que ce qu'est "penser objet" était assez bien expliqué et ça fait donc partie des choses que j'aurais sans doute aimé lire un peu plus tôt (en aurais-je compris tout l'intérêt ? -cf les Design Patterns).
D'autre part la connaissance des 12 patterns est un excellent framework conceptuel pour analyser les objets et régles métier à implémenter.
A bientôt pour des réflexions plus XP, quand j'en utiliserai autre chose que les tests unitaires,...
--------------------------------------------------------------------------------
