Développement et conception : mon approche P(N)OO

Ces derniers temps, j’ai eu plusieurs occasions pour échanger au sujet de l’architecture du code, comment concevoir ses classes, ses objets, leurs liens, leurs interactions, leurs tests, etc … Il y a eu des échanges avec des développeurs qui ont leurs visions, qui s’interrogent, qui cherchent la bonne voie vers l’excellence. Et il y a eu des interventions auprès d’équipes qu’il m’a fallu guider, qui attendaient de moi une réponse, et avec qui j’ai partagé ma vision, plutôt pragmatique même si ce n’est pas la pure beauté du geste …

Je vous la propose aujourd’hui en espérant vos avis et réactions.

La Programmation Orientée Objet (POO) : c’est bien !

Depuis que ça existe, ou presque, je fais de la POO, Programmation Orientée Objet … du moins, je le pensais … Car, comme tous les développeurs actuellement (ou presque), j’utilise des objets, comme par exemple en Java. Prenons un exemple en imaginant le développement d’une application de vente dans laquelle il nous faudra un « panier » avec une liste de produits, une référence à un client, une date, un état, etc … Le début de l’objet Java représentant ce panier pourrait ressembler à ça :

public class Carts {
 
 private List<product> products;
 
 private Client client;
 
 private Date date;
 
 private Status status;
 
 ...
 
}

Nous allons poursuivre en enrichissant notre objet, selon la POO telle que je l’ai comprise…

Nous aurons besoin d’accéder à ses attributs, nous allons donc ajouter des accesseurs :

 public void setClient(Client client) {
  this.client = client;
 }

 public Date getDate() {
  return date;
 }

 public void setDate(Date date) {
  this.date = date;
 }

 public Status getStatus() {
  return status;
 }
 
 public void setStatus(Status status) {
  this.status = status;
 }
 
 public List<product> getProducts() {
  return products;
 }

Nous avons également besoin de modifier ses données par des méthodes utilitaires :

 public void addProduct(Product product) {
  products.add(product);
 }

 public void removeProduct(Product product) {
  products.remove(product);
 }

Dans le cycle de vie de la vente, il nous faudra le prix total à payer, nous ajoutons donc une méthode utilitaire :

 public float computeTotalPrice() {
  float total = 0;
  for (Product product : products) {
   total += product.getPrice();
  }
  return total;
 }

Pour des besoins de gestion, une fois la vente réalisée, nous devons stocker le panier dans une base de données, nous allons donc demander au panier de nous donner une requête d’insertion en base SQL :

 public String computeSqlInsertRequest() {
  return "insert into carts date=? clientId=? ....";
 }

A noter que cette requête ne sera pas forcément valable pour tous les SGBD (exemple classique : la date), il faudra certainement pouvoir demander des variantes.

Pour la partie vente en ligne sur internet, nous devons générer un mail avec un résumé du contenu, nous ajoutons donc une nouvelle méthode à notre objet « Panier » qui dispose de toutes les informations nécessaires :

 public String computeMailContent() {
  String content = "Bonjour,\nVotre panier composé le " + date
    + " comporte les éléments suivants :\n";
  for (Product product : products) {
   content += "- " + product.getName() + " au prix de "
     + product.getPrice() + "\n";
  }
  return content;
 }

OK, mais là c’est bon pour un mail en texte brut, mais il faut gérer les mails au format HTML …

Bon, je m’arrête là, mais vous me voyez venir : ma classe « Carts » commence à devenir fourre-tout, elle va vite devenir énorme, et regrouper tout et n’importe quoi. Tout ça pour répondre à différents besoins autour des données contenues dans un « panier ».

Alors, dans une récente discussion, un copain me répond : « pattern visiteur » !

Pattern visiteur : la solution ?

Le pattern visiteur est en effet une alternative à la dérive ci-dessus : il permet d’extraire certains traitements dans des objets séparés.

Mais d’après moi, ce pattern n’est pas la solution, pour la simple et bonne raison qu’il est trop compliqué, trop difficile à comprendre et à appréhender lorsqu’on relit du code. Je ne dis pas ça pour me défendre, car je l’avoue sans hésiter, j’ai beaucoup de mal avec ce pattern. Mais mes observations m’ont montré que bon nombre de développeurs ne le comprennent pas non plus. Je pense qu’il faut un état d’esprit particulier pour le maîtriser, et j’admire ceux pour qui ce pattern est une évidence.

Et je ne parle même pas des tests unitaires avec un tel pattern, je n’ose imaginer, surtout sans le maîtriser …
Toujours est-il qu’avec mon obsession d’une approche pragmatique, il me semble dangereux d’utiliser un pattern lorsqu’une grosse majorité de l’équipe ne le comprend pas. L’équipe doit produire du code maîtrisé par tous, et donc par chacun !

Et alors, comment fait-on ?

PNOO : Une « Programmation Non Orientée Objet » ?

Je ne sais pas comment l’appeler. Je ne sais même pas si cette approche aurait un nom. Je compte sur vous pour m’éclairer si vous avez des informations à ce sujet.

Toujours est-il que pour moi, la solution est de séparer :

• Les objets contenant des données, qu’on peut appeler « beans », objets contenant uniquement des attributs, et éventuellement, des accesseurs. Sans détailler : si l’objet est interne à mon package, la classe est « package », les attributs aussi, pas besoin d’accesseurs ; à contrario, si je développe une librairie, alors mes beans sont plus « classiques », avec des accesseurs, et idéalement, ce sont des objets immutables
• Les objets de traitement, sans attributs de données, uniquement des références aux collaborateurs et éventuellement, des données de réglages ou de contexte. Dans bon nombre de cas, ces « objets de traitements » peuvent être static

Cette approche a le mérite d’être simple, toujours comprise par tous, et facilite les tests unitaires, notamment leur apprentissage :

• Les « beans » ne se testent pas, aucun intérêt, aucun ROI
• Les objets de traitement sont faciles à tester, avec des beans de données en entrée (faciles à préparer) et des beans de données en sortie (faciles à vérifier), et les collaborateurs sont faciles à « mocker »

A noter, évidemment, qu’on va respecter le principe « une classe, un rôle » !

Voilà mon approche, celle que je pratique, mais également que je propose aux équipes avec lesquelles je travaille et qui ont apparemment toujours bien réussi à monter en compétences vers une architecture évolutive et donc agile, en passant bien sûr par l’apprentissage des tests unitaires, en TDD, ça va de soi, ou presque … ;-)

Je sais que cette approche ne plait pas aux « puristes » mais elle a le mérite d’être simple et pragmatique. Et vous ? Comment faites-vous ? Quelles sont vos pratiques d’équipe ?

J’attends donc vos avis, critiques ou adhésions, et commentaires ! Merci