Blog de Rochdi Chakroun

Matthieu Mezil, artiste de l’objet, est parti pour son article L’objet, c’est beau du besoin suivant:

• Prendre un fichier en entrée, effectuer un traitement sur celui-ci puis sauvegarder les modifications dans un fichier de sortie.
• Par défaut, il propose deux types de traitements : l’inversion des caractères ligne par ligne et la numérotation des lignes.
• De plus, il veut que les traitements soient composables à l’infini et qu’ils puissent être utilisés indépendant de la notion de fichiers.

L’article traite plusieurs problématiques comme le threading, la gestion d’erreurs … Je vais m’intéresser juste à la première partie : l’acte de création du « chef-d’œuvre ».

L’artiste propose d’organiser sa solution en 2 couches UI et Business, déjà ce choix artistique me pose problème … pourquoi deux couches ? Pourquoi pas une seule ? Pourquoi pas 5 ?
Enfaite on connaît tous la réponse, mais on a tendance à concevoir nos applications en n-couche par habitude / respect des bonnes pratiques. Ce reflexe acquis (chez d’autres développeurs c’est même un reflexe inné) peut parfois nuire à la santé de la solution.

Dans notre cas, la problématique posée est assez simple par rapport à la complexité des projets réels, le choix de plusieurs couches dans cet exemple n’est dû aux contrainte de maintanabilité / scalabilité / extensibilité … Mais probablement pour consolider la structure de la solution : J’aurai préféré si Matthieu partait d’une seule couche, un seul centre fort qui encapsule plusieurs sous-centres (centres latents + centres faibles) : UI / interface avec l’infra (manipulation des fichiers) / Traitement des données ) et qu’en avançant dans son analyse il faisait évoluer sa solution en passant les centres latents en centre forts et en éliminant les centres faibles … Par exemple l’application au début se limite à une application client lourd et petite à petit un nouveau centre celui du traitement apparaît et on l’externalise dans une couche à part.

De nos deux couche business / UI Matthieu a fait un zoom X 1000, et on se retrouve en train de discuter d’une interface IStringsTransform ! Moi, j’ai eu le vertige… On est passé d’un level of scale de l’ordre de l’assembly à celui d’une interface ! comme si un architecte te présente la structure des étages de ta futur maison et juste après il enchaine avec l’emplacement du divan dans ton salon.
Autre soucis avec le Zooming, l’artiste fait référence aux designs patterns. Les design patterns c’est bien mais se focalisent sur une partie du système: Avec un zoom réglé au niveau objet, on risque donc de perdre de vue la solution globale.

Ce que j’aurai aimé trouver dans l’article, c’est une explication plus détaillé de l’approche, une analogie avec le monde réel peut être.
Dans notre cas, on a un fichier et des transformations qu’on peut composer séquentiellement. Ca ressemble à mettre une capsule Nespresso dans la machine, demander une transformation (café court / moyen / et long) en appuyant sur la commande adéquate :crazy:. On a donc des commandes qui référencent les transformations et un invoker a qui l’utilisateur associe à la demande une commande, la commande à son tour va s’appuyer sur la transformation pour satisfaire la requête du client:

Pour l'utilisation:

            ILineTransformation lineNumberTransformation = new LineNumberTransformation();
            TransformCommand lineNumberTransformCommand = new TransformCommand(lineNumberTransformation);
            ILineTransformation reverseCharLineTransformation = new ReverseCharLineTransformation();
            TransformCommand reverseTransformCommand = new TransformCommand(reverseCharLineTransformation);
            TransformationRemote remote = new TransformationRemote();
            remote.CurrentCommand = reverseTransformCommand;
            var resultWithReverse = remote.Zapping(input);
            remote.CurrentCommand = lineNumberTransformCommand;
            var resultWithLineNumber = remote.Zapping(input);