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

Injection de dépendances en utilisant Unity en 10 min

L’intérêt de l’injection de dépendances est de permettre: – une meilleure maintenabilité, – de mettre en place plus facilement une méthode TDD (Test Driven Development), – d’être plus flexible (plus facile de s’adapter à une nouvelle implémentation), – d’être plus extensible (ajout plus facile de nouvelles fonctionnalités), – supporter le "late binding" (inclure des modules…

Continuer à lire

Principe de développement orienté-objet SOLID

L’acronyme signifie: – Single responsability principle (SRP°: responsabilité unique, – Open/close principle (OCP): principe ouvert/fermé, – Liskov substitution principle (LSP): substitution de Liskov, – Interface segragation principle (ISP): ségrégation des interfaces, – Dependency inversion principle (DIP): inversion des dépendances. Responsabilité unique Une classe doit avoir une et seulement une seule raison de changer. Principe ouvert/fermé…

Continuer à lire