Fork me on GitHub

About

Vous êtes sur le weblog de JN Avila

Pages

Add some pages here, or start a new chapter.

Tag Cloud

Archives

Categories

Links

Alpinux
Aroblog
Hayabousa
Le blog de Raphy Stoller
le blog de Belu
stellamatutina
Da BOop
JS Zone
Irresponsable !
Blablog
Mistress Doom Bazar
Le monde de Cornelius
Why-Note

Search

Latest Comments

Stéphan (un petit ajout à …): C’est çà la célébrité…
JN (Mes dernières lec…): Il faudra que tu attendes que j‘écrive un billet. Pour ce qui est de “sustainabilité”, ben c’est so…
Mathieu (Mes dernières lec…): Tiens, “sustainabilité”, c’est quoi le mot en vrai français pour dire ça ? “Durabilité”, “soutenabili…
Mathieu (Mes dernières lec…): Houlà, t’en as trop dit ! Balance !!!
JN (Mes dernières lec…): Et encore, je ne te parle pas de ce que je lis en ce moment…
Mathieu (Dernière lecture …): “Tous les habitants des pays développés sont dans une certaines mesure des enfants du pétrole. Le fai…

Stuff

Powered by PivotX - 2.3.3 
XML: RSS Feed 
XML: Atom Feed 

If statement considered harmful

Sunday 17 April 2011 at 4:25 pm

Derrière ce titre un brin provocateur, une réflexion simple : on apprend à l'école dans les  bases de programmation le concept de flux d'exécution conditionnel. Le problème avec cette approche est qu'elle occulte le plus souvent le besoin pour une bonne architecture de logiciel, sujet qui est rarement traité dans les cours d'informatique. La faiblesse d'architecture multiplie les tests, menant le plus souvent au syndrome « code spaghetti ».

Cette situation est encore plus crispante avec les technologies objet. Le polymorphisme a pour vocation à remplacer les tests par une résolution dynamique des méthodes à appeler. L'utilisation de if avec des fonctions d'introspection de type "isInstance" sont une absurdité qui devrait frapper ceux qui l'écrivent et me hérissent au plus au point. Un polymorphisme bien pensé permet d'éliminer totalement des ensembles de "if" ou "case" en formalisant à la manière objet le fait qu'un ensemble de comportements correspondent à un cas d'utilisation et doivent donc appartenir à une même entité représentant ce cas d'utilisation. Si on ne suit pas ce précept, on ne peut pas suivre le précept objet « opened for extension, closed for modification » car il apparaît souvent qu'un test à un endroit en appelle d'autres lors des évolutions du logiciel.

Je vois cependant deux déviations majeures à cette règle : la gestion des stimuli externes à l'application et l'exécution des règles métier de l'application, ce qui peut englober en partie l'exception précédente.

Pour la première exception, je ne vois pas comment réaliser l'analyse des entrées de l'application, qui sont par nature non maîtrisées sans effectivement les tester. Cependant, ces tests devraient se cantonner à la phase d'analyse la plus proche des informations brutes d'entrée et sont déjà le plus souvent implémentés dans des bibliothèques d'interface (parseurs, gestion réseau, lecture de configuration, etc). 

Pour les règles métier, c'est après tout ce qui constitue l'objet de l'application. Pour qu'une application vérifie si une température est inférieure à un seuil donné, on doit lui faire faire le test. Avec l'application de cette règle, on peut être sur qu'un test effectué dans le code doit pouvoir être relié à une spécification de règle métier.

À part cela, comme dit la pub, pour tout le reste, il y a le polymorphisme.

Linkdump

» Google s'amuse

à ouvrir dans chrome ou chromium une recheche qui parle d'elle-même

  No comments |