Eviter d’effectuer des “casts” avec Bridge et Visiteur

Lorsqu’on intervient sur du code existant, la plupart du temps, on manipule des objets sous leur forme générique, par l’intermédiaire de classes abstraites ou d’interfaces. Dans la majorité des cas, les membres exposés par la classe abstraite ou par l’interface suffisent à utiliser l’objet en faisant appel à des fonctions ou des données membres. Toutefois,…

Continuer à lire

Principe de développement DRY (Don’t Repeat Yourself)

DRY pour “Don’t Repeat Yourself” est un principe de programmation visant à exercer les développeurs à reconnaître des duplications puis de trouver le moyen de les supprimer. Ces duplications peuvent se produire évidemment dans le code mais aussi à tout niveau de l’application comme par exemple dans son architecture, dans les tests unitaires ou dans…

Continuer à lire

Quelques blogs intéressants

Pour avoir des informations mises à jour toutes les semaines sur la technologie .NET en général: https://blogs.msdn.microsoft.com/dotnet/ Blogs sur la technologie .NET en général Scott Hanselman: http://www.hanselman.com/blog/ Jon Skeet: https://codeblog.jonskeet.uk/ Phil Haacked: http://haacked.com/ Rick Strahl: https://weblog.west-wind.com/ Stephen Cleary: http://blog.stephencleary.com/ Oren Eini: https://ayende.com/blog/ Software Craftsmanship Sandro Mancuso: http://codurance.com/blog/author/sandro-mancuso/ Jeff Sutherland: https://www.scruminc.com/scrum-blog/ Blog Arolla: http://www.arolla.fr/blog/ Blog Octo:…

Continuer à lire

Design pattern: Service Locator

Objectif: Proposer une implémentation simple de l’inversion de contrôle Justification Lorsqu’un objet doit utiliser une compétence implémentée dans un autre objet, la première approche est d’instancier cet autre objet et de l’utiliser au moyen de ces membres publiques. Par exemple, si on prends la classe suivante: public class ConsumingObject { private ConsumedObject consumedObject; public ConsumingClass()…

Continuer à lire

Design pattern: Façade

Objectif: Simplifie l’interface d’une ou plusieurs classes Justification Problème Lorsqu’une interface doit être consommée par une classe cliente, il est courant de vouloir simplifier cette interface: – pour cacher la complexité de l’implémentation interne et présenter une interface simple à utiliser, – simplifier l’appel à beaucoup d’objets internes en ne proposant qu’une interface unique, –…

Continuer à lire

Design pattern: Adapter

Objectif: Convertir l’interface d’une ou plusieurs classes pour qu’elle soit adaptée à un ou plusieurs clients. Justifications Problèmes Le besoin de présenter différemment un objet à une autre classe qui le consomme peut se justifier par plusieurs raisons: – On veut présenter un objet plus adapté aux besoins de la classe cliente, de façon à…

Continuer à lire

Design pattern: Visiteur

Objectif: Permettre d’appliquer des comportements spécifiques à un ou plusieurs objets et être sûr que tous les types d’objets sont pris en compte Justification Problèmes On possède une liste hétérogère d’objets, par exemple une liste de véhicules: voiture, moto, etc… On souhaite appliquer des comportements sur ces objets comme: – "ajouter des passagers", – "ajouter…

Continuer à lire

Design pattern: Décorateur

Objectif: Rajouter dynamiquement une ou plusieurs compétences à une classe sans en modifier l’implémentation. Justification Problèmes On souhaite ajouter un ou plusieurs comportements à une classe déjà implémentée. La méthode la plus simple est d’intervenir dans cette classe et de rajouter les comportements voulus directement. Cependant plusieurs raisons peuvent motiver le choix de ne pas…

Continuer à lire