L’art des anti-patterns

La négligence vis a vis de la conception objet amène malheureusement ses adeptes à se demander pourquoi il faudrait s’embarrasser à modéliser des classes quand on peut récupérer directement un tuple sous forme d’objet raw-typed via mysql_fetch_object().

Notre pensée est tellement focalisée sur la base de données, le data-dentric, lieu Sacré de stockage, qu’on l’on s’éloigne complètement de la logique objet.
Certains mêmes persistent à croire que PHP c’est fait QUE pour dialoguer avec la base de données. C’est à la fois tellement réducteur et tellement répandu.

Mon ancien Directeur Technique m’avait en effet demandé un jour :

« pourquoi tu t’embête à créer des classe d’entités métier : tu fais un SELECT dans la base puis un mysql_fetch_objet() et comme ça Mysql il te retourne des objets tout faits à la volée »

Ok donc tu assumes l’usage d’objets raw-typed stdClass générés à la volée.
Maintenant à mon tour :

  • quid de la validation des propriétés de l’objet ?
  • comment peux-tu générer un formulaire à partir d’un Model dont la classe n’existe pas ?
  • comment fais-tu pour instancier un objet Métier non hydraté (récupéré et rempli) via Mysql ?
  • as-tu déja entendu parler de découplage des couches  ? (en l’occurence ici : Business et Persistance Layers)
  • quid si tu dois renvoyer un objet dégradé en réponse à une requête client REST pour du data-binding ?
  • …et qui côté client, dans une architecture JS-MVC,  va forcément vérifier son intégrité ?
  • comment gères-tu le binding entre ton objet et celui attendu par un service web SOAP ?
  • comment fais-tu pour passer ton objet stdClass à une méthode qui attend un type d’objet Métier bien précis
  • …sans bidouiller un cast sauvage via une pattern Adapter
  • qui des objets qui transitent d’un SI à l’autre ou un service web à l’autre sans passer par le SGBD ?
  • Lorsque feras appel à un ORM le jour où l’appli grossira : comment celui-ci pourra gérer la persistance d’objets non annotés ?

Ok tu as une approche POJO :  en soit c’est très bien, mais suivant l’architecture en place ca s’avère trop rudimentaire.

C’est bien de penser KISS, mais faut amener la perspective plus loin que ça !

Le Business Model et la View

La véritable erreur je pense , c’est de construire un Business Model qui est adapté uniquement à la UI dans laquelle on prévoit de l’afficher.
Pourquoi l’objet devrait il se conformer uniquement à sa représentation web ?
Ca va l’encontre d’un des principes fondateurs du modèle d’architecture  MVC : Separation of Concerns.
L’entité Métier n’a pas à savoir comment elle sera affichée, ni où ni quand ni comment.
Elle ne doit jamais être conçue en ayant le souci de sa représentation visuelle.
Elle doit être pensée pour être exploitable quelque soit le format du flux de sortie : JSON, XML, HTML, console, YAML, CSV, whatever…
En revanche la vue elle doit savoir où dans le HTML, placer les données JSON reçues d’un service web.
Principe du MVVM, pensé à l’origine par Microsoft dans ASP.net et exploité par AngularJS

 

C’est comme si on demandait à un humain de se vêtir exclusivement en jean basket, parce que quelqu’un en a décidé ainsi à un instantT de l’histoire.
Or évidemment ca parait complètement absurde de devoir porter les même types de vêtement advitam eternam.
Un objet doit avoir le droit d’exister sans lui coller une étiquette, un comportement d’affichage pré-calculé.
Ce qui n’empêche que parfois l’objet doit pouvoir être visuellement déclinable par exemple en tant que widget externe.

Et paf voila le défi : il doit fonctionner pareil mais pas s’afficher pareil.

En tant qu’humain je n’ai pas à changer mon anatomie ni ma nature profonde. En revanche je peux adapter mon accoutrement en fonction :
– des circonstances : rdv pro, rdv galant , mariage, funérailles, baptême.
– du climat : pluie, soleil, vent, neige, jour, nuit.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s