Article vraiment très bien proposé ici par @Sebsauvage.
On se rapproche très fortement de ce que propose David West dans Object Thinking (livre qui a 20 ans déjà) et Yegor Bugayenko dans Elegant Objects (livre qui doit fêter ses 8/9 ans). Je me permets de compléter la solution de la pratique n° 3.
L'auteur propose d'encapsuler la hauteur dans une entité, ce qui nous donne :
// Primitive contenue dans un objet (aussi appelé Value Object)
class ArticleHeight {
private value: number;
constructor(value: number) {
if (value < 10) {
throw new HeightCanNotBeLessThanTen();
}
if (value > 100) {
throw new HeightCanNotBeGreaterThan100();
}
this.value = value;
}
}
// passage de notre ArticleHeight dans le constructor
class Article {
private height: ArticleHeight;
constructor(height: ArticleHeight) {
this.height = height;
}
}
// eh voilou !
class AddArticleUsecase {
execute({ height }) {
//...
const article = new Article(new ArticleHeight(height));
//...
}
}
Pas moi. Je propose que la classe Article
s'attende à recevoir en paramètre une interface Height
dont l'une des implémentations possible soit une ArticleHeight
mais qui pourrait très bien être une valeur venant d'une BDD au moyen d'une HeightFromBdd
(pas le meilleur nom, mais c'est pour représenter l'idée).
Ceci casse le couplage entre deux classes concrètes et subséquemment facilite les mocks/stubs durant les tests dont l'auteur ne parle pas.
Ce qui nous donne
// Primitive contenue dans un objet (aussi appelé Value Object)
interface Height {
value(): number
}
class ArticleHeight implements Height {
private value: number;
constructor(value: number) {
if (value < 10) {
throw new TooShortLength("Un article doit faire au minium 10 lignes");
}
if (value > 100) {
throw new TooLongLength("Un article ne peut faire plus de 100 lignes");
}
this.value = value;
}
value(): number {
return this.value;
}
}
class Article {
private height: Height;
constructor(height: Height) {
this.height = height;
}
}
class AddArticleUsecase {
execute({ height }) {
//...
const article = new Article(new ArticleHeight(height));
//...
}
}
Et sur le même modèle, si votre classe expose une méthode publique, c'est qu'elle est imposée par une interface, dans tous les autres cas de figure les méthodes qui ne viennent pas d'interfaces doivent être privées.
Ce serait la 10ème règle que j'ajouterais à l'article.
Les observateurs auront aussi remarqué que j'ai changé les exceptions. Il ne vaut pas confondre nom de l'exception et contexte dans lequel une erreur été levée. D'où l'importance d'un message qui exprime la raison d'une erreur et le nom de l'exception qui exprime le type d'erreur remontée.