Cercare sempre il modello giusto può a volte essere fuorviante. A volte è necessario combinare alcuni aspetti di diversi modelli. E a volte ti fa concentrare solo sul problema sbagliato.
È lo schema di stato?
Questo non è uno schema di stato, anche se riguarda lo stato dell'oggetto, perché l'intento dello schema di stato è:
Allow an object to alter its behavior when its internal state changes.
Non hai bisogno di uno schema di stato, solo per gestire lo stato di un oggetto! Nella tua narrativa, i lavoratori (altri oggetti) controllano lo stato di un lavoro (oggetto con uno stato), per vedere se possono iniziare la loro attività. Ma tu non dici nulla sulla necessità che il lavoro cambi il suo comportamento.
Nota: potrebbe essere interessante utilizzare lo schema di stato per rappresentare il lavoro, se ogni stato ha un comportamento diverso o se si guadagna per avere un logica di transizione dello stato più complessa.
È lo schema dell'osservatore?
L'intento del tuo pattern è più simile a un pattern di osservatore:
Define a one-to-many dependency between objects so that when one
object changes state, all its dependents are notified and updated
automatically.
Ma sfortunatamente, i tuoi dipendenti stanno facendo esattamente il contrario: sondano lo stato invece di aspettare solo di essere avvisati.
Nota molto importante: forse vale la pena prendere in considerazione l'utilizzo di java Condition per migliorare significativamente la concorrenza, in quanto la condizione è una sorta di modello di osservatore?
È un pattern di memento?
Poiché la tua intenzione è quella di serializzare lo stato, ci si potrebbe chiedere se non si tratti di un modello di memento:
Without violating encapsulation, capture and externalize an object's
internal state so that the object can be restored at a later stage.
Bene, hai l'intento di serializzare lo stato, e certamente, in un'applicazione multithread, vuoi garantire l'incapsulamento corretto dello stato del lavoro. Quindi forse dovresti dare un'occhiata a questo schema per impacchettarlo in modo ordinato.
È pub / sub?
No, non è un Pub / Sub. Un pub / sub è una variante del pattern di osservatore, in cui l'abbonato sottoscrive un editore (esattamente come un osservatore si registrerebbe a un osservabile), ma l'editore non solo notificherà che c'è qualche cambiamento, ma fornirà i dati da trasformati.
Potresti ottenere un pubub, se i lavoratori leggessero il loro lavoro da una coda e il tuo oggetto status controllasse ciò che l'abbonato poteva leggere dalla coda.
Conclusoon
Nel tuo caso, puoi certamente dare un'occhiata a questi schemi e applicare (o trarre ispirazione) da alcuni costrutti. Ma il tuo obiettivo principale dovrebbe essere più sulla progettazione della concorrenza che sul design della classe: dovresti usare un semaforo per dare accesso a una coda? dovresti usare una condizione per ottenere un flusso di controllo più ottimale tra l'attesa dei thread? dovresti cercare una coda senza lucchetto? potrebbe un altro meccanismo di sincronizzazione aiutare?