S’entraîner et vérifier sa compréhension

import assert from "node:assert/strict";

class Creature {
	readonly nom: string;
	#energie = 100;

	constructor(nom: string) {
		this.nom = nom;
	}

	get energie(): number {
		return this.#energie;
	}

	sePresenter(): string {
		return `Je m'appelle ${this.nom}.`;
	}
}

const grenouille = new Creature("René");
const poisson = new Creature("Mina");
assert.equal(grenouille.sePresenter(), "Je m'appelle René.");
assert.equal(poisson.sePresenter(), "Je m'appelle Mina.");
assert.equal(grenouille.energie, 100);
assert.equal(poisson.energie, 100);
assert.notEqual(grenouille, poisson);

Le constructeur copie son paramètre dans this.nom. Chaque new initialise aussi son propre champ #energie. L’accès grenouille.energie appelle le getter, sans donner accès au champ privé. readonly empêche les réaffectations du nom dans le code TypeScript vérifié, sans constituer une protection de sécurité à l’exécution.

Les deux objets sont distincts parce qu’on a exécuté deux fois new. Avec const poisson = grenouille, les deux variables désigneraient au contraire le même objet. Changer le nom de la variable ne crée pas une nouvelle créature.

import assert from "node:assert/strict";

class Creature {
	static readonly energieMax = 100;
	readonly nom: string;
	#energie = Creature.energieMax;

	constructor(nom: string) {
		this.nom = nom;
	}

	get energie(): number {
		return this.#energie;
	}

	sePresenter(): string {
		return `Je m'appelle ${this.nom}.`;
	}

	avancer(): boolean {
		if (this.#energie < 10) return false;
		this.#energie -= 10;
		return true;
	}

	seReposer(): void {
		this.#energie = Math.min(Creature.energieMax, this.#energie + 20);
	}
}

const grenouille = new Creature("René");
const poisson = new Creature("Mina");
for (let pas = 0; pas < 10; pas++) {
	assert.equal(grenouille.avancer(), true);
}
assert.equal(grenouille.energie, 0);
assert.equal(grenouille.avancer(), false);
assert.equal(grenouille.energie, 0);
assert.equal(poisson.energie, 100);

grenouille.seReposer();
assert.equal(grenouille.energie, 20);
for (let repos = 0; repos < 5; repos++) grenouille.seReposer();
assert.equal(grenouille.energie, 100);
grenouille.seReposer();
assert.equal(grenouille.energie, 100);

Le contrôle précède la soustraction. Il laisse donc l’objet intact quand l’énergie est insuffisante. Math.min choisit la plus petite valeur entre le maximum et l’énergie augmentée, ce qui empêche le repos de dépasser 100.

#energie est propre à chaque instance, alors que energieMax est un membre static consulté sur la classe. Comme la classe ne propose aucun setter d’énergie, le code extérieur doit passer par les deux opérations prévues pour la modifier. Ces contrôles suffisent aux actions définies ici, qui ne reçoivent pas de quantité extérieure. Si on ajoute un gain d’énergie fourni par l’utilisateur, il faudra valider cette nouvelle entrée.

import assert from "node:assert/strict";

interface Deplacable {
	avancer(): boolean;
}

class Creature implements Deplacable {
	static readonly energieMax = 100;
	readonly nom: string;
	#energie = Creature.energieMax;

	constructor(nom: string) {
		this.nom = nom;
	}

	get energie(): number {
		return this.#energie;
	}

	sePresenter(): string {
		return `Je m'appelle ${this.nom}.`;
	}

	avancer(): boolean {
		if (this.#energie < 10) return false;
		this.#energie -= 10;
		return true;
	}

	seReposer(): void {
		this.#energie = Math.min(Creature.energieMax, this.#energie + 20);
	}
}

class Mare {
	#habitants: Deplacable[];

	constructor(habitants: Deplacable[]) {
		this.#habitants = [...habitants];
	}

	faireUnTour(): number {
		let deplacements = 0;
		for (const habitant of this.#habitants) {
			if (habitant.avancer()) deplacements += 1;
		}
		return deplacements;
	}
}

class Nenuphar {
	avancer(): boolean {
		return false;
	}
}

const grenouille = new Creature("René");
const poisson = new Creature("Mina");
const nenuphar = new Nenuphar();
const habitants = [grenouille, poisson, nenuphar];
const mare = new Mare(habitants);
habitants.length = 0;

assert.equal(mare.faireUnTour(), 2);
assert.equal(grenouille.energie, 90);
assert.equal(poisson.energie, 90);
for (let tour = 0; tour < 9; tour++) assert.equal(mare.faireUnTour(), 2);
assert.equal(grenouille.energie, 0);
assert.equal(poisson.energie, 0);
assert.equal(mare.faireUnTour(), 0);
grenouille.seReposer();
assert.equal(mare.faireUnTour(), 1);
assert.equal(grenouille.energie, 10);

La mare utilise seulement le résultat d’avancer(). Elle n’a donc besoin ni du nom ni du getter d’énergie. implements Deplacable vérifie la classe Creature, mais n’y ajoute aucune méthode. La classe Nenuphar ne déclare pas implements Deplacable, mais ses instances satisfont aussi l’interface par leur structure. Elle n’a pas besoin d’hériter de Creature pour collaborer avec la mare.

Le constructeur copie le tableau des habitants. Modifier le tableau fourni après la construction ne change donc pas la liste interne. Les créatures elles-mêmes restent partagées, ce qui permet de constater leur nouvelle énergie après un tour. On retrouve ici la distinction entre copier un tableau et copier ses objets.

Les habitants avancent l’un après l’autre dans cette simulation, qui ne traite ni météo ni événements. Elle permet de vérifier que la mare utilise le même contrat avec des objets différents. L’interface décrit les types attendus, tandis que les explications et les assertions précisent le comportement à respecter.

Le paramètre reçoit le texte pendant l’appel au constructeur. L’affectation this.nom = nom conserve ce texte dans une propriété de l’objet créé. Après le constructeur, la méthode peut le retrouver par this.nom. Le second new crée un autre objet, initialisé avec Mina. L’appel poisson.sePresenter() utilise cet objet comme this, donc il ne lit pas le nom de René.

alias === original vaut true, car les deux variables désignent le même objet. copie === original vaut false, car la décomposition a créé un nouvel objet. Modifier alias.quantite modifie donc aussi ce que l’on lit par original.quantite, tandis que modifier le nombre copie.quantite ne modifie pas l’original.

const empêche de réaffecter la variable, sans figer l’objet. La copie reste superficielle, car elle ne recrée pas les objets imbriqués. Si une propriété contient un tableau, l’objet original et sa copie peuvent donc encore partager ce tableau. Pour obtenir true avec ===, il suffit que les deux variables désignent le même objet, comme alias et original.

L’invariant est rompu, même si le champ est caché. L’opération publique accepte une valeur interdite et la conserve. Il faut valider chaque modification possible ou ne proposer que les actions qui maintiennent la règle, comme avancer() et seReposer().

private réserve l’accès dans le code TypeScript vérifié, puis disparaît du JavaScript exécuté. #energie contrôle aussi l’accès au champ à l’exécution. Aucun des deux ne corrige un setter qui accepte une énergie négative. La protection d’accès et la validation des actions remplissent deux rôles différents.

Le robot peut satisfaire Deplacable sans hériter de Creature. L’interface exprime ce dont la mare a besoin, tandis que implements vérifie la présence de la méthode et la compatibilité de ses types. Il n’en fournit pas le code.

Un héritage ou une classe abstraite peut convenir quand les sous-classes doivent réellement partager un état et du code. Ici, imposer les données des créatures au robot n’aide pas la mare. Il faut surtout conserver le contrat d’avancer(), y compris le sens du résultat et les effets d’un refus.

Une condition peut suffire à ce besoin. Elle garde les deux cas près du calcul et reste facile à vérifier. La présence d’un if ne signale pas, à elle seule, un défaut de conception.

Passer un objet de tarif devient intéressant lorsque plusieurs règles doivent être choisies indépendamment de la réservation, comparées ou remplacées dans les tests. La séance Strategy étudie ce changement précis.

Une fabrique peut regrouper la création et la configuration du fournisseur. L’appelant demande alors un objet prêt à utiliser sans reproduire les détails de sa construction. Une stratégie porte le calcul interchangeable, par exemple un objet TarifSolidaire dont la méthode appliquer transforme un prix en montant.

Si un seul fournisseur se construit en une ligne à un seul endroit, un appel direct peut suffire. Si une fonction avec une condition suffit à choisir entre deux objets à créer, elle peut déjà jouer le rôle d’une fabrique. La séance Factory distingue cette forme du Factory Method GoF. Aucune de ces décisions n’impose une hiérarchie de classes.

Le code qui retire la vue doit aussi retirer son abonnement. Dans la séance Observer, il appelle la méthode de désabonnement avec l’observateur de cette vue. Retirer le HTML ne supprime pas la référence conservée par le mécanisme d’événements. On vérifie donc qu’après le désabonnement, les événements suivants ne déclenchent plus la réaction de cette vue.

Une réservation enregistrée et un courriel envoyé sont deux résultats distincts. Dans notre séance Observer, on garde l’erreur de réaction séparément et on poursuit les autres notifications. Au début de l’envoi d’un événement, le programme copie la liste des abonnés. Un désabonnement pendant cet envoi ne change donc pas cette copie. L’abonné peut encore recevoir l’événement en cours, mais ne recevra plus les suivants.

La méthode existe, mais sa promesse n’est plus tenue. L’appelant qui pouvait annuler toute réservation active doit maintenant reconnaître la sous-classe et contourner le refus. Le remplacement rompt donc le contrat donné dans la question.

La correction du principe de Liskov réserve le contrat d’annulation aux objets capables de le tenir et garde la consultation accessible aux autres réservations. Si l’annulation peut normalement échouer, le contrat doit annoncer ses conditions et ses résultats dès le départ. Une erreur prévue par un contrat n’est pas automatiquement une violation de Liskov.