Software Design

Durant mon travail, j’ai rencontré des dépendances circulaires dans une application sur laquelle je suis intervenue. Dans sa plus simple forme, il s’agit de deux classes qui dépendent l’une de l’autre. Ceci est, selon moi, un problème pour plusieurs raisons. L’objectif de cet article est de montrer ce qu’est une dépendance circulaire, en quoi cela peut poser problème, et comment les éliminer.

CQRS, ou Command Query Responsibility Segregation, est une architecture où la partie Command (écriture) et la partie Query (lecture) du système sont séparées.

J’ai eu la chance d’assister récemment à une présentation de Tomasz Jaskula nommée Recettes CQRS, pour bien cuisiner son architecture. Je l’ai beaucoup appréciée, notamment car on voit les différentes étapes pour arriver à une architecture CQRS / Event Sourcing / DDD à partir d’une architecture N-Tiers “classique”.

L’objectif de cet article est de présenter ma compréhension et mon avis sur le CQRS en particulier.

Les tests automatisés servent à vérifier le bon comportement d’un objet (ou d’un ensemble d’objets), indépendamment de la manière dont ce comportement est implémenté. Le comportement d’un objet est décrit par son API publique (constructeurs, constantes et méthodes publiques). Les tests ne devraient donc utiliser que cette API.

Les méthodes privées (et protected) ne faisant pas partie de l’API publique d’un objet, elles ne devraient pas être appelées directement par le code de test.

Cet article a pour objectif de montrer comment réagir lorsqu’il paraît nécessaire de tester une méthode privée.

L’héritage est une composante très importante des langages orientés objet tels que Java. Cependant, il doit être utilisé à bon escient afin de respecter les bonnes pratiques de programmation.

Il m’est arrivé de rencontrer des cas où l’héritage était utilisé afin de ne pas dupliquer du code. Le but de cet article est d’illustrer une telle utilisation, d’analyser ses inconvénients et de montrer une manière possible de la corriger.