“Mocker” une dépendance statique

Les objets statiques sont souvent utilisés pour mutualiser rapidement l’implémentation d’un comportement ou plus rarement pour partager des instances d’objets entre plusieurs classes. L’utilisation d’objets statiques peut être un choix d’architecture maitrisé. Dans ce cas, on a la possibilité de modifier l’implémentation des objets statiques ainsi que des objets consommateurs. Dans d’autres cas, l’utilisation d’objets…

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

Domain-Driven Design en 5 min

Cet article est un aide mémoire sur le Domain-Driven Design (DDD), il ne vise pas à expliquer le DDD mais simplement à rappeler les concepts clés. Certains termes sont laissés volontairement en anglais en particulier lorsque leur traduction n’est pas très claire en français ou lorsque que le terme français n’est pas très utilisé. Sommaire…

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