Questo è uno dei modelli di progettazione più complicati e apparentemente inutili che ho incontrato. Associa strettamente i componenti in un modo che renderebbe difficile il cambiamento o l'estensibilità.
In questo link, l'esempio mostra una classe di conto bancario il cui comportamento cambia in base al saldo disponibile. Il comportamento è cambiato assegnando tipi completamente nuovi all'oggetto 'stato' dell'account, ad eccezione del fatto che ogni 'stato' è responsabile dell'assegnazione reciproca a un account. Il flusso di controllo non è chiaro; semplicemente chiamando 'account.deposit' finisce per riassegnare i membri interni a nuove classi.
Quando viene inventata una nuova regola (ad esempio includiamo un account "platinum", che ha semplicemente un tasso di interesse più alto); ora dobbiamo modificare 4 classi; 3 x tipi di stato esistenti e l'account originale, oltre a creare un'implementazione completamente nuova di "stato" che deve implementare completamente i comportamenti di un conto bancario, semplicemente per modificare una "regola".
Ci potrebbe essere un buon caso per usare questo modello intenzionalmente, ma non sembra che sia così, per me.
E non vedo come si possa applicare sensibilmente questo schema al concetto di un telecomando. Un telecomando non ha uno stato (a parte forse on / off), invia semplicemente le istruzioni a un altro dispositivo. Quel dispositivo potrebbe avere uno stato (ad es. Il volume è al massimo) nel qual caso una particolare istruzione potrebbe essere ignorata (non può aumentare il volume quando viene raggiunta al massimo), ma si dovrebbe sovraintendere la soluzione cercando di comprimerla in questo schema. p>