Qui di seguito descrivo cosa sto cercando di fare e come penso che lo farò. Quello che spero è che esista un modello di design per l'utilizzo di un oggetto per configurarne un altro. Ciò mi consentirebbe di avere una buona generica classe Job
piuttosto che una lista sempre crescente di sottoclassi di Job
.
Se esiste un tale schema di progettazione, come si chiama e come applicarlo al mio caso d'uso? Sto usando il framework Symfony e sto lavorando in PHP.
Una parte della mia applicazione è un elenco Task
per le attività dell'utente. UtenteA crea Task $task1
e viene visualizzato nell'elenco Task
. UtenteB accetta $task1
che cambia lo stato dell'attività in "accettato"; UserB
inizia $task1
che cambia lo stato dell'attività in "avviato"; ecc. Ho implementato la precedente come macchina a stati e funziona bene.
Tuttavia, ogni Task
trasporta Payload
. Il Payload
ha 2 proprietà:
-
Payload$sop
è un oggetto SOP che contiene informazioni di configurazione. -
Payload$inputvars
è una matrice di vars di input fornita daTask
creator.
e un metodo:
-
makeJob(SOP $sop = null, $inputvars = null)
, un metodo factory che crea un oggettoJob
configurato secondo l'oggettoSOP
. Questo è il punto "e la magia succede" nel mio codice.
Quando $task1->status
cambia in "avviato", viene chiamato $task1->payload->makeJob()
e viene creata una nuova Job $job
. UtenteB interagirà con un modulo per immettere i campi richiesti dal SOP
che ha prodotto $job
. Quando UtenteB modifica $job->status
in "completato", anche lo stato di $task1
verrà modificato in "completato".
Quindi, questo è un modo ragionevole per ridurre la sottoclasse di Job
? Esiste un modo più efficiente, dato il gran numero di possibili sottoclassi di Job
(stiamo parlando di centinaia qui).