Spécifier l'implémentation au lieu de l'interface

27 septembre 2023

TL;DR

Expliciter l'implémentation par ce qui la différencie d'une autre implem ex: BffMetierService qui est l'implem et son interface est MetierService

Contributeurs

Suxue Li, Julie Brunetto, Guillaume Moizan, Gauthier Fiorentino, Dorian De Rosa

Statut

Accepté

Contexte

Côté front, on a des services qui sont abstraites par des interfaces. Le nommage des implémentations et des interfaces ont été challengé en revue.

Une proposition était d'expliciter l'interface en le préfixant d'un I (ex : IMetierService).

Une autre est d'expliciter les implems et non pas les interfaces, citation de Clean Code :

These are sometimes a special case for encodings. For example, say you are building an ABSTRACT FACTORY for the creation of shapes. This factory will be an interface and will be implemented by a concrete class. What should you name them? IShapeFactory and ShapeFactory? I prefer to leave interfaces unadorned. The preceding I, so common in today’s legacy wads, is a distraction at best and too much information at worst. I don’t want my users knowing that I’m handing them an interface. I just want them to know that it’s a ShapeFactory. So if I must encode either the interface or the implementation, I choose the implementation. Calling it ShapeFactoryImp, or even the hideous CShapeFactory, is preferable to encoding the interface.

Décision

Suite aux discussions et votes, nous nous avons décidé d'appliquer la proposition 2. C'est-à-dire expliciter l'implémentation par ce qui la différencie d'une autre implem ex: BffMetierService, et son interface se nommera MetierService.

Conséquences

Un nommage uniforme sur le projet.

Autres pistes explorées

• Nommer la classe MetierServiceImpl et l'interface MetierService
• Nommer la classe MetierService et l'interface IMetierService