Catégories: Conception, Conventions de codage, Design Patterns, MVC, Singleton

Suite à son dernier article, je suis tombé sur le blog de julien et en remontant le temps, j'ai eu envie de réagir à son premier billet.

Comme mes commentaires commençaient à s'allonger, j'ai préféré rédigé ce petit billet.

• Quand je faisais du Swing et du JDBC, j'aimai bien à partir de mes ResultSet remplir un objet métier qui implémentait une interface modèle de la vue (GridModel, ListLodel, ...) qui pouvait être présenté différemment par un Renderer. Cela évitait ainsi des recopies inutiles.

• En GXT, j'ai essayé de faire la même chose en remplissant avec Ibatis des Maps qui implémentent ModelData (l'interface des modèles de données dans GXT).

Dans les deux cas, il y a une "adhérence" aux interfaces "Model" d'une couche graphique (Swing, GXT).
Et si cela me dérangeait moins en Swing à l'époque, avec le web, ça me plaît pas trop.

Du coup, je me demande si deux objets ne sont pas nécessaires puisqu'ils ont deux responsabilités différentes :

• Un type d'objet MA qui sert de conteneur de données (POJO du modèle de l'application)

• Un type d'objet MV qui sert d'objet de rendu (Modèle de donnée d'un composant de la vue de l'application) qui représente directement des MA ou une vue consolidée de MA)

Et donc une recopie partielle des données d'un MA dans un MV ?

Ce qui illustre de plus en plus ce sentiment que j'ai que le MVC s'applique à plusieurs niveaux :

• Un MVC global au niveau de l'application métier : Des vues (Vue) qui permettent via des actions (Contrôleur) de traiter des données (Modèle)

• Un MVC local au niveau d'objets techniques : les composants graphiques d'une couche de présentation, ceux qui servent à construire les vues de l'application métier.

Et vous, qu'en pensez vous ?

Avec un titre pareil, toi, esprit perspicace, tu auras compris de qui je veux parler, n'est-ce pas ?

Et puisque que je ne t'apprendrai rien sur lui, je vais plutôt te parler de notre histoire à tous les deux, de notre rencontre, du temps qu'on a pensé ensemble, des infidélités, de notre séparation, de nos retrouvailles, etc...

» Lire la suite!

Dans un précédent billet, je faisais état des données membres que l'on veut exposer et je rappelai les avantages du principe d'encapsulation.

Bien entendu, de même qu'il n'est pas question de mettre tous les attributs en visibilité publique, il n'est pas question pour autant de créer des getters/setters pour tous les attributs. (J'aurai même tendance à penser qu'il ne faut les créer que si une classe cliente en a vraiment besoin.)

En poussant un peu plus loin la réflexion, je pense qu'on ne devrait même pas se poser les questions

• getter or not getter ?
• setter or not setter ?

» Lire la suite!

Chez les développeurs débutants, on peut observer deux attitudes opposées :

• Soit ils utilisent beaucoup trop de variables publiques
• Soit ils suivent aveuglément les conseils et utilisent des getters partout, même dans la classe d'origine.

Selon moi, ces deux cas extrêmes illustrent qu'ils n'ont pas compris l'intérêt du principe d'encapsulation des données.

Je me propose d'en faire le sujet de ce billet qui je l'espère sera propice à quelques réflexions.

» Lire la suite!

Avec ce billet, j'ai envie d'introduire des petites questions de style que l'on se pose parfois.

Comme tout acte d'écriture, chaque développeur possède son style de codage.
Ce style se forge avec le temps

• en suivant le style de nos maîtres
• en suivant les conventions qui rendent un travail d'équipe plus homogène
• en suivant nos propres choix ...

Parfois, ces choix sont purement arbitraires (les alternatives se valent, les avantages de l'une compensent les inconvénients de l'autre et vice-versa)
D'autre fois, de bonnes pratiques émergent avec l'expérience ...

Quoi qu'il en soit, si l'essentiel est de rester cohérent, réfléchir à la question ne peut être que bénéfique pour comprendre une convention existante ou pour créer la nôtre.

"This" is the first question ...

» Lire la suite!

Je ne vais pas vous parler de ma dépendance à GAE (Je m'arrête quand je veux !) mais de la dépendance d'une application Java à cette offre de Cloud Computing.

Je vous propose de vous montrer ce qui peut vous rendre dépendant et je vous suggère des pistes pour éviter ou minimiser ces dépendances. D'ailleurs, certains conseils sont valables en dehors de GAE et même en dehors de Java ...

» Lire la suite!

J'ai conclu l'article précédent en me déclarant de type Homme.
La classe EtreHumain est cependant conservée :

• elle surclasse les classes Homme et Femme
• elle paramètre l'interface générique PeutMettreAuMonde<E> implémentée par Femme.

Soit f une instance de Femme que l'on supposera enceinte et dont le bébé arrive à terme.
Considérons l'instruction EtreHumain e = f.metAuMonde();
e est donc une instance d'EtreHumain et plus spécifiquement une instance d'Homme ou une instance de Femme.

Le mystère de la création enfin résolu ? Pas vraiment ! une question se pose : D'où vient f ? Si f = (Femme) mf.metAuMonde(), d'où vient alors mf ? ...

L'histoire de la poule et de l'œuf : une régression infinie ?

Dans l'histoire de la poule et de l'œuf où on cherche qui précède qui ?

• l'œuf est en fait une ovule non fécondé et la poule précède donc l'oeuf !
• l'œuf est une ovule fécondé qui donnera un coq, la poule précède l'œuf car on n'a jamais vu un coq faire une poule, seulement des coqs "se faire" des poules !!!
• l'œuf est une ovule fécondé qui donnera une poule, la question devient "Quelle est la poule qui a fait la poule ?"

Dans notre cas, si on met également de côté le mâle qui participe de manière indirecte à la création, la question est similaire : "Quelle est la femme qui a fait la femme ?"

Créationniste VS Évolutionniste ?

A la question "Quelle est la femme qui a fait la femme ?", je ne vois que deux réponses :

• Soit on considère qu'en remontant la chaîne de création, on finit par tomber sur une femme première, tombée du ciel ? créée par miracle ? ou existante depuis toujours ? (N'est-ce pas là la preuve que Dieu est une femme ! ;o))
• Soit on considère l'évolution ...
  On ne dit pas d'un bébé "Quel bel homme !" ou "Quelle belle femme !" parce que si sur un plan biologique, c'est déjà un mâle ou une femelle, il va évoluer au cours de sa vie ... On devient Homme, on devient Femme ... De la même manière que ses instances, la classe EtreHumain n'est pas apparue du jour au lendemain, on est devenu être humain au cours du temps ... Il n'y a pas de frontière nette, on est dans un monde continu ...
  Dire qu'on est plus humain que nos ancêtres d'il y a plusieurs milliers d'années est un point de vue : vue d'ici où nous sommes les représentants des êtres humains.
  Un représentant de nos ancêtres pourrait très bien dire qu'ils sont les êtres humains et que nous, nous sommes autre chose; c'est un autre point de vue.
  Disons donc simplement que nous sommes différents de nos ancêtres et de nos descendants.

Comment modéliser ?

• A priori, la création ex nihilo me paraît plus facile à implémenter : Je partirai d'une femme initiale (Femme eve = Femme.getPremiereFemme();) puis je ferai des appels à la méthode metAuMonde() de chaque femme de sa descendance ... On devrait bien tomber sur ma mère !
  Cependant, en suivant cette façon de faire, il y a une difficulté : combien de femmes intermédiaires ? Je ne saurai le dire !
  La seule solution que j'imagine est de ne pas remonter à l'origine mais de partir d'un état initial où préexisterait une femme de ma branche maternelle.
• A priori, l'évolution soulève une difficulté originelle insurmontable : D'où partir ?
  Lavoisier apporte la solution avec sa célèbre formule "rien ne se perd, rien ne se crée, tout se transforme". L'évolution, c'est donc ce qui nous transforme, ce qui nous fait passer d'un état initial à un état final ! Je peux donc choisir l'état initial qui me convient : considérer une femme de ma branche maternelle ou même considérer que j'existe déjà !

Du coup, on voit que dans cette modélisation, quelque soit la position adoptée, on part d'un état initial où préexistent certaines entités.
C'est d'ailleurs souvent le cas en POO, c'est pourquoi il existe des librairies qui initialise un graphe d'objets (Comme Spring dans le monde Java).

La réponse à la question posée en introduction est donc : La femme f vient d'un état initial.

A suivre ...

Si j'étais un objet, je serai une instance d'EtreHumain (voir les épisodes précédents)

Comment je viens au monde ?

Un développeur Java pourrait suggérer : new EtreHumain();

Si vous avez lu mon article précédent, vous aurez compris que cette réponse est loin de me satisfaire.
Dans le cas contraire, je vais vous expliquer pourquoi cette réponse ne me convient pas vraiment alors qu'au final, il y aura bien cette instruction quelque part !

Vous vous doutez bien que l'appel à ce constructeur ne crée pas un un être humain mais une structure de données représentant un être humain. Le problème n'est donc pas là.

Le problème, c'est que cette instruction appartient au niveau technique et non au niveau fonctionnel.
Elle ne devrait donc pas être accessible directement depuis n'importe quelle classe cliente, surtout si on ne souhaite pas modéliser la création d'EtreHumain !
Et même dans le cas où on souhaite la modéliser, comment rendre applicable les règles fonctionnelles concernant cette création si on ne l'encapsule pas dans une méthode de création ?

Voyons donc quelle pourrait être cette méthode fonctionnelle ?

Le plus naturellement possible !

Et si la classe EtreHumain avait une méthode : public EtreHumain metAuMonde()

Bien vu mais non ! Ce qui me dérange, c'est que cette méthode soit dans la classe EtreHumain alors qu'elle ne concerne même pas la moitié d'entre eux.

Remarquons au passage que c'est un problème typique de POO ! Certains s'en satisfont très bien en disant qu'une méthode qui ne s'applique pas à toutes les instances retournera null ou lancera une Exception pour les cas inappropriés. Personnellement, cela ne me satisfait pas.

Le choix de la classe EtreHumain montrerait t'elle ses premières limites dans le cadre de ma modélisation ? Les deux classes Homme/Femme ne sont t'elles pas plus justifiées tout à coup ? Classes où seule la classe Femme contiendrait cette méthode :

public class Femme extends EtreHumain implements PeutMettreAuMonde<EtreHumain>
où l'interface générique PeutMettreAuMonde<E> aurait la méthode public E metAuMonde().

On pourrait hésiter à placer cette méthode dans cette classe en faisant remarquer une fois de plus que toutes les instances ne sont pas forcément concernées (Toutes celles qui ne sont pas enceintes). Toutefois, la différence avec précédemment, c'est que potentiellement, elles pourraient l'être !

Conceptuellement, je trouve cela beaucoup plus satisfaisant ! Surtout que mine de rien, l'interface a été travaillée :

• Le nom de l'interface évoque bien la potentialité.
• Les noms de l'interface et de sa méthode se veulent le plus général possible pour s'appliquer également à d'autres mammifères et même d'autres espèces. (Je trouvai une interface Enceinte avec sa méthode accouche() trop spécifique : dans ce cas là, plus besoin d'interface !)
• La méthode metAuMonde renvoit un E et pas une List<E> car c'est le cas le moins général et même dans ce cas, ils viennent au monde un après l'autre ...

Avec une telle modélisation, je suis donc une instance d'Homme !

A suivre ...

Un système informatique ne modélise pas la réalité. Au mieux, il modélise un modèle d'une partie d'une réalité.
Ainsi, je suis en train de modéliser une vision de ce que je peux être.

Une des difficultés est de ne pas mélanger les niveaux, surtout si on parle à la fois de modèle pour désigner ma représentation mentale et de modèle pour désigner la représentation informatique de ma représentation mentale.

Appelons donc fonctionnel le premier modèle et technique le second.

La première étape de la modélisation est de créer au niveau technique des objets (des structures de données) qui vont représenter des entités du niveau fonctionnel.

Cette distinction est nécessaire lorsqu'on aborde la phase de création :

• Au niveau technique, il y a création d'objets pour allouer de la mémoire à la structure de données informatique.
• Au niveau fonctionnel, il y a création d'entités si on veut modéliser cet aspect. Autrement dit, l'acte de création est modélisé.

Il est important de noter que la création d'entité :

• reposera toujours sur une création d'objet.
• n'est pas obligatoire puisque notre modèle fonctionnel peut "démarrer" avec une certaine configuration, un ensemble d'entités représenté par un ensemble d'objets.

On peut également en profiter pour faire d'autres remarques :

• Les classes représentent les types d'entités de mon modèle mental et toutes leur méthodes représentent ce qu'il est permis de faire fonctionnellement.
• Les classes peuvent avoir des méthodes techniques qu'on essayera de cacher par un niveau de visibilité privé. Si ce n'est pas possible, on représentera les types d'entités par des classes abstraites ou interfaces et ce sont dans des classes concrètes qu'on placera le code technique. On aura ainsi séparer la spécification de l'implémentation.
• La construction des objets devrait se faire uniquement par des méthodes fonctionnelles si le modèle fonctionnel l'autorise et devrait être interdite autrement (par les moyens expliqués au point précédent)

Ces précisions étant faites, on pourra passer à la phase de création dans un prochain article ...

Etre ou avoir ?

C'est une question qui se pose souvent en POO.
Ai-je une relation d'héritage ? (classe parente, sous classes, héritage multiple, interfaces, ...)
ou une relation de client ? (agrégation, composition, dépendance, ...)

Je suis un corps qui a une âme ...

Est-ce que je suis un corps ou est-ce que j'ai un corps ?
Si j'ai un corps ? Qui possède ce corps ?
A part la classe PersonnePhysique qui pourrait avoir un attribut corps, je ne vois pas bien dans l'immédiat d'autres candidats. De plus, il faudrait créer une classe pour cet attribut.
Avoir quelque chose m'évoque le fait que je ne pourrai ne plus avoir cette chose. Or si je ne devais plus avoir de corps, je crois que je ne pourrai pas continuer d'exister. Ce qui me prouve qu'on est plus ce corps qu'on ne le possède. Il me paraît donc beaucoup plus naturel de dire que je suis un corps d'où mon choix de la classe EtreHumain qui représente des corps physiques particuliers.

De la même manière, suis-je une âme ou ai-je une âme ? Aussi étrange qu'il me semble de l'écrire, je crois que je possède plus une âme (au sens conscience) que je n'en suis une. En reprenant mon argument sur le fait d'avoir, je conçois très bien l'idée de mon corps sans âme. C'est juste que je ne n'en aurai pas conscience.
Dois-je pour autant dans ma classe EtreHumain ajouter un attribut âme ? et créer une classe pour cet attribut ? Non, si je crois que la conscience est une faculté émergente d'une partie de mon corps.

... ou une âme qui a un corps ?

La solution matérialiste me séduit. Pour autant, j'imagine bien une solution duale. On ne pourrait être qu'informations, des objets abstraits, des âmes qui élaborent tout un monde physique et qui se perçoivent dans ce monde comme des entités. Là, c'est le corps qui serait une propriété émergente de l'esprit. Je reconnais que cette idée me donne le vertige ... Rien n'existe en dehors de mon regard ?

Pourquoi choisir ?

Ne peut on pas concilier ces deux idées ? Un corps physique a jamais inconnu dont émerge une conscience qui se représente son propre corps et son environnement ?
De toute manière, dans le cadre de mon exercice, quelque soit la position philosophique que l'on choisit, j'aurai besoin d'une part de modéliser un corps et d'autre part, je ne vois pas comment modéliser une âme.

A ce stade, je suis toujours une instance d'EtreHumain. Ce choix sera peut être remis en cause ultérieurement, mais dans l'immédiat, je pense que c'est le plus justifié.

A suivre ...

Je ne sais pas vous, mais moi, même une fois qu'une solution a été trouvée, dans les jours qui suivent, je ne peux pas m'empêcher d'avoir de nouvelles idées. Comme si les processus lancés en arrière plan dans ma boite crânienne continuaient de tourner ...

Je suis conscient que pour avancer, il ne faut pas toujours remettre en cause ses premières solutions mais lorsqu'on peut se le permettre, autant laisser s'exprimer ce petit côté perfectionniste. Je vois un avantage à confronter les idées : Soit elles fragilisent mon choix initial et le remplacent avantageusement, soit elles le renforcent.

J'ai imaginé d'autres classes candidates qu'EtreHumain : Individu, Personne, EtrePensant...

- Individu :
Soit cela me fait pensé à un élément d'une population et je trouve ça un peu trop général,
Soit cela me fait pensé à Personne.

- Personne :
C'est une classe candidate qui me séduit assez. Pour une application de gestion ou application juridique, c'est assurément elle que je choisirai pour me représenter. J'irai même jusqu'à en faire deux sous classes : PersonnePhysique et PersonneMorale. Cela à l'avantage de pouvoir gérer à la fois des gens et des entreprises.
En revanche, dans le cadre de mon problème (Si j'étais un objet ...), modéliser une personne morale ne m'intéresse pas.

- EtrePensant :
C'est une classe qui me caractérise bien, comme EtreHumain et EtreVivant. Parfois, lorsque certains de mes congénères me disent "Tu penses trop, tu te poses trop de questions", j'ai l'impression qu'ils sous-exploitent cette capacité unique. Le problème, c'est que c'est une notion assez flou, plus flou encore que celle d'EtreVivant.

Pourquoi EtreHumain demeure ma meilleure classe ?

Cela ressortira prochainement lorsque j'aborderai la phase de création mais sans présumer de la suite, on peut déjà remarquer ce qui distingue EtreHumain de ces trois classes.
Un être humain, c'est d'avantage concret non ? Si on le voit comme un "animal" particulier, si on imagine son corps, on en voit les contours.
Alors qu'individu, personne, etre pensant, c'est plus abstrait, cela se rapproche plus d'esprit, d'âme, de conscience ...

En écrivant "Si j'étais un objet ...", par objet, je pensais au sens informatique de la POO, à une instance d'une classe.
Maintenant, je suis arrivé à un autre niveau : savoir si cet objet informatique modélise un objet concret (un corps) ou un objet abstrait (une âme) ?

Là encore, cela dépend de ce que veut modéliser le client (pour peu qu'il le sache).
Je vous expliquerai pourquoi j'ai choisi le premier cas dans un prochain article...

Le problème à modéliser est dans le titre ! Je ne sais pas trop où ça va me conduire mais on verra bien ... (non, non, pas la camisole !!!)

Si je suis un objet, je suis une instance mais une instance de quoi ? Informaticien/Informaticienne, Homme/Femme, EtreHumain, Mammifère, EtreVivant, Etre ... ?

Les idées de classes jetées en pâtures indiquent déjà une potentielle chaîne d'héritage mais laissons la de côté pour l'instant.

Quelle classe choisir ? A quel niveau je me situe ?

Pour moi, c'est le problème qu'on veut modéliser qui doit trancher.

Le plus général : Je dirai que c'est en faire un peu trop !!!
Dans l'esprit du client, c'est ni un problème de philosophie, ni un problème de biologie !

Le plus spécialisé : Je dirai que c'est un peu trop limitatif au goût du client !
- Si je veux changer de profession, comment je fais ?
- Si j'étais amené à choisir les deux sous classes Homme / Femme, à quoi rattacher Informaticien ? A Homme ? Dans ce cas, il me faudrait une sous classe Informaticienne et donc potentiellement, une explosion du nombre de classes ...

Doit-on avoir deux sous classes d'EtreHumain : Homme & Femme ou est-ce que l'ajout d'un attribut sexe à la classe EtreHumain ne suffit-il pas ?

Cette question de modélisation entre l'ajout d'un attribut ou la création de sous classes se pose très souvent en POO.
On peut d'ailleurs le voir pour de nombreux attributs (pour ne pas dire tous) :

• attribut sexe vs classes Homme/Femme
• attribut nationalité vs classes Français/Italien/Allemand/...
• attribut profession vs classes Informaticien/Philosophe/...

Personnellement, j'ai pour règle de ne pas créer de sous classes tant que le comportement ne diffère pas et que les attributs en question ne sont pas complètement inappropriés.

Dans mon exemple flou, deux sous classes ne se justifient pas pour l'instant, optons donc pour l'attribut sexe.

Aujourd'hui, je suis donc un objet de classe EtreHumain qui aura son attribut booléen "sexe" à 1 !

A suivre ...