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