17Fermer19
deleted2Le 06/08/2017 à 14:37
Tiens, je découvre un truc génial en programmant ça...
J'ai décrit ma machine et ses défauts avec des états :
	Les états
	=========

La machine connait trois états :
- démarrée
- en marche générale
- en marche automatique

* Démarrée
	>	on lit les sondes de température : bac, débulleuse, four et tête volumétrique
	>	le contacteur de puissance est coupé

* En marche générale
	>	le contacteur de puissance est enclenché
	>	on chauffe les éléments nécessaires à la marche automatique : bac, débulleuse, four et tête volumétrique

* En marche automatique
	>	tout fonctionne à la demande


	Les défauts
	===========

Il y a deux classes de défauts :
- les défauts critiques
	>	problèmes graves pour la machine ou les personnes
	>	ils coupent la marche automatique et la marche générale (et donc la puissance)
- les défauts fonctionnels
	> tous les défauts empêchant le fonctionnement correct de la machine
	> ils coupent la marche automatique si elle est enclenchée


Les défauts ne sont scrutés que lorsque c'est nécessaire. 
Tous les défauts, critiques ou généraux, doivent être acquittés.
Sauf que le concept d'état, ça a l'air très théorisé encore une fois.

Ce qui fait que dans un code du genre :
GestionMarcheGenerale()
{
    gestion1();

    if (pas en defaut) {
        gestion2();
    }
    if (pas en defaut) {
        gestion3();
    }
}
on est susceptible de lever un défaut dans gestion1().
En levant ce défaut, on est descendu d'un mode. Donc on doit se garder d'exécuter gestion2/3, sous peine de les exécuter dans un mode incohérent.

On écrira plutôt :
GestionMarcheGenerale()
{
    gestion1();
    gestion2();
    gestion3();
}
Si gestion 1 lève un défaut, on active juste un flag ou un numéro de défaut.
Et en fin de cycle, on regarde si un défaut a été levé. S'il l'a été, on ferme le gestionnaire de marche générale, et on met la machine en défaut proprement.
Au cycle suivant, on appellera tout simplement pas GestionMarcheGenerale().

En fait, les états de la machine sont une sorte de pile, on passe d'un étager à l'autre en fonction des entrées utilisateurs ou des défauts, à un moment précis, et surtout pas au milieu du flow d'exécution.

Ca a pour immense avantage de simplifier le code, parce qu'il est toujours exécuté dans un état cohérent ! Ca fait énormément de contrôles en moins, et bien moins de noeuds au cerveau pour anticiper les corner cases

Bon, évidemment, ça ne doit pas pouvoir marcher toujours. Je pense à une machine qui a besoin du succès d'une action pour exécuter la suivante (ce qui n'est pas mon cas ici).
C'est peut-être pour ça que dans la nouvelle version du logiciel, ils ont ajouté la gestion des exceptions.


• Folco retourne pianoter, toujours de plus en plus content de son automate love