July 2007


Pour le design de la BDD, comment on peut identifier les données dont on a besoin et comment les structurer dans la BDD (structure des tables et les relations) ? Voici deux approches possibles … à méditer:

  1. Commencer par la BDD avec le MCD (Modèle Conceptuel de Données):
    la base de données créée peut être relativement simple et claire dans la logique relationnelle. Sur cette BDD, on construit une couche des objets Java pour encapsuler les données. Ces objets sont appelés les objets models. Deux points à noter ici:

    • Les objets Java sont souvent le reflex des tables de la BDD : contraint ? Inconvénience ou avantage ?
    • Est-ce que cette structure des objets Java est bien compatible avec la logique de l’application
      (c’est-à-dire est-ce que c’est facile d’implémenter les cas d’utilisation prévus pour l’application avec cette structure des objets ou bien il faut avoir beaucoup de codes supplémentaires pour “régler” l’incompatibilité entre ceux qu’on veut faire – les cas d’utilisation, et l’environnement dans lequel on agit – la structure des objets models)
  2. On peut commencer par les utilisateurs avec les cas d’utilisation:
    à partir des cas d’utilisation prévus, on identifie les traitements et les informations nécessaires – c’est-à-dire la logique métier et les données de l’application. On construit les objets Java models qui reflexent ces connaissances. Puis on construit la BDD basé sur ces objets models. Points à noter: Est-ce que c’est facile d’interpréter la logique métier dans la langue relationnelle de la BDD ?

La même question se pose sur The M in MVC

Advertisements

J’ai récemment testé un programme qui produit quelques millions d’objet String. Evidemment, j’ai reçu un OutOfMemoryError. Comme d’habitude, j’ai augmenté le mémoire attribué pour le programme avec l’option -Xmx (dans Eclipse, c’est la boite de dialogue “Run”, voir l’image ci-dessous) et ça marche.

“Run” dialog

Mais je voulais comprendre mieux la cause de cette fameuse erreur, et en recherchant sur Internet, j’ai tombé sur quelques documents intéressants suivants:

Yes, the most effective way is Invest in yourself

I’m working for a bank in Paris, and my principle job is to maintain an application and add new features when needed. Because the application have been written and in production now, I usually have to read and re-use the legacy code. The application is written in Java.
Even Java is a very good Object-Oriented Programming Language, what I have seen here is NOT object-oriented programming at all. It is unstructured programming, ok, with a lot of tolerance, we can say that it is procedural programming, but it cannot be object-oriented programming in any case.
Let me explain why:
there are no objects (classes that model real-world object): when they want to encapsulate a contract, for exemple, with a list of people concerned. In the place of creating the People object and maintain a List of People, they have:

  • a Vector of people names
  • a Vector of people address
  • a Vector of people roles
  • a Vector of people sexes
  • a Vector of people ages
  • a Vector of anything you can imagine

no object, no List, no Set, nothing, just a disk of spaghetti made of Vector. And when they want to add a new Customer, they add his name in the Vector of names, his age in the Vector of ages, …. You can imagine that ? More than a nightmare, it is really a disaster. And even worse, there is no document – no Javadoc at all and names of variable and method are abbreviations in any ways, just what come in there head at the moment of coding. You can believe it ?
The guys who have create this application are all Software Professionnal Developers, at least it is what they are proud to be. And they were really paid for that.

So, when you use OOP language, please, think in object.

I suggest the book “Thinking in Java” for those who use Java.

Beware of Defensive Null Checking

Voici l’article :
Java EE 6 Gets it Right
Le débat sur TheServerSide est aussi très intéressant à lire : Rod Johnson: “Java EE 6 Gets it Right”

Here is the article: How to spot the dreaded non-coding architect