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

Nathalia (Fin de vacances): Tiens, tu blogues perso maintenant ?
DBF (Mes dernières lec…): Plus léger et en phase avec l’actu www.decitre.fr/livres/star -wars-l.. Joyeux Noël, JNA.
JN (Real humans and c…): C’est en anglais parce que je voulais en faire une réponse à l’article initial.
Frérot (Real humans and c…): Waowww, You’ve gone deep into the episodes… By the way, like you, I was kind of fond of “Real Human…
Cami (Les joies de l'in…): Bonjour! Si vous êtes intéressés de traduire logiciels pour Internet, pour PC, pour mobiles ou tout a…
Mathieu (Pas sérieux): …. je vois passer les avions avec bandeaux publicitaires au-dessus des plages depuis la fenêtre de mo…

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 |