Mantenere gli oggetti intermedi come campi membri è una buona idea in questo caso?

Mantenere un riferimento agli oggetti intermedi all'interno dell'oggetto costruito mi sembra una violazione del principio SRP . Ad esempio, potresti avere classi NFA , DFA , una classe DFABuilder e un contesto da cui si utilizzano quegli oggetti

• la preoccupazione della classe DFA è quella di rappresentare l'automatismo finito deterministico (NFA simile), non meno, non di più. L'origine da cui è stato creato un DFA non dovrebbe essere rilevante per l'oggetto DFA, semplicemente non è è un problema .

• la preoccupazione di DFABuilder è di convertire un oggetto NFA in un oggetto DFA (si assuma che abbia il metodo pubblico DFA ConvertNFAToDFA(NFA nfa) . Può contenere un riferimento all'oggetto NFA per la sua durata e produrre più oggetti intermedi per questo scopo, ma dopo che la costruzione è terminata, non ci dovrebbe essere bisogno di mantenere l'oggetto DFABuilder o gli oggetti intermedi alife (si presume che non ci sia alcun requisito esplicito per accedere successivamente ai componenti interni del processo di creazione.)

• la preoccupazione del contesto è di fornire un oggetto NFA , chiamare ConvertNFAToDFA e ricevere l'oggetto DFA risultante per un'ulteriore elaborazione.

Quindi, se hai il requisito di riutilizzare l'oggetto NFA nel contesto dopo la costruzione di DFA , mantieni un riferimento a NFA all'ambito contesto . Se non hai il requisito, non tenerlo. Ma in entrambi i casi non dovrebbe essere necessario memorizzare l'oggetto NFA direttamente all'interno di DFA. Se il tuo programma produce più oggetti NFA, oggetti DFA (e altri oggetti correlati) e vuoi tenere traccia di quale oggetto è stato creato da quale altro, puoi prendere in considerazione la creazione di una classe di tuple allegata, per contenere un paio di NFA e un oggetto DFA. Ma mantenere le classi NFA e DFA completamente separate l'una dall'altra rende molto più facile riutilizzarle e testarle.

Se la tua classe sta modellando il processo - cioè, è un oggetto lavoratore a distanza - allora può funzionare bene per mantenere lo stato intermedio come membri. Pensa al pattern Builder, che accumula informazioni di stato su ciò che sta cercando di costruire, e quindi produce l'oggetto - quindi lo lanci Builder.

Uso le classi one-shot in questo modo quando il processo è davvero complicato & ha un sacco di passaggi (che il tuo caso fa). Questo può essere davvero utile per isolare i diversi passaggi.

...

"Devo mantenere un riferimento a ciascun oggetto intermedio come membro dell'oggetto che è stato utilizzato per creare?" Non vorrei. Nel contesto del processo di costruzione, quelli potrebbero essere membri di qualche contesto esterno, ma le classi risultanti dovrebbero essere la cosa stessa. (Una sorta di valore nominale, avere una classe che detiene l'NFA e il DFA viola il principio della responsabilità unica.)