Come modellare una macchina a stati in questo caso

each message to be sent or received goes through several states

Se ogni messaggio ha il proprio stato, allora sì, dovrebbe contenere la macchina di stato per poter reagire al suo ambiente in base al suo stato attuale.

Utilizzo della terminologia GoF :

• Il tuo messaggio sarebbe Context
• Il messaggio sarebbe proprietario di un abstract State per composizione
• Le operazioni dipendenti dallo stato verranno inoltrate da Context allo stato attivo concreto

Lo schema di progettazione dello stato consente di aprire chi definisce la transizione di stato. In genere potrebbe essere il Context (cioè il messaggio) che coinvolge una macchina a stati, ma un approccio più flessibile previsto in GoF è di rinviare questa responsabilità allo stato stesso.

Tuttavia, se si dispone di un numero enorme di messaggi attivi che condividono alcuni stati, potrebbe essere un overhead avere ciascuno istanziare la propria macchina di stato. In questo caso, potresti prendere in considerazione la possibilità di combinare lo schema di progettazione dello stato con il schema dei pesi volanti .

Sono d'accordo con il commento di @ FrankHileman sulla terminologia dei messaggi come stato confuso e uso non standard del concetto di messaggi.

I messaggi, quasi per definizione, sono immutabili e passano tra due o più di una sorta di entità (mutabile), come gli attori.

Sarebbero gli attori che seguono le macchine di stato, dati i messaggi, per determinare cosa fare dopo. Ogni attore può avere la propria (diversa) macchina statale. Il numero di attori ha a che fare con il tuo dominio.

Anche se a volte potremmo essere in grado di modellare tutti gli stati di tutti gli attori in un modello non è necessario farlo, e sarebbe probabilmente più semplice avere macchine a stati indipendenti associate a attori diversi.

Suggerirei di associare a ciascun attore solo gli stati e la macchina a stati di cui ciascuno a sua volta ha bisogno, piuttosto che disporre di un oggetto StateMachine globale.

In generale è meglio distribuire le responsabilità tra le parti responsabili (cioè gli attori) piuttosto che raccogliere un aspetto o una preoccupazione trasversale di tutte le responsabilità (ad esempio la macchina degli stati / stato) in un unico luogo / entità globale. Questo tende a ridurre l'accoppiamento supportando Principio di Responsabilità Unica (SRP) ; vogliamo che le entità di dominio abbiano una responsabilità di dominio.

Mentre la centralizzazione tende ad aumentare l'accoppiamento, rendendo più difficile apportare modifiche indipendenti, l'indipendenza è l'obiettivo principale a sostegno della manutenzione a lungo termine.

Questo non vuol dire che la centralizzazione delle preoccupazioni trasversali non abbia alcuni vantaggi, ma si traduca in un costo di manutenzione e talvolta aumenta anche altre complessità introducendo un'entità aggiuntiva orientata all'implementazione piuttosto che orientata al dominio.

L'introduzione di un'entità separata con responsabilità centralizzata per una preoccupazione funzionale che attraversa diversi attori supporta SRP in un senso molto indiretto; tuttavia, dovremmo parlare di SRP per quanto riguarda una responsabilità di livello inferiore, una responsabilità di implementazione interna, piuttosto che una responsabilità a livello di dominio. Considero questo design più debole con un accoppiamento più strong.