Come valutare se un'orchestrazione è il modello di progettazione appropriato per un dato problema?

Question

Come valutare se un'orchestrazione è il modello di progettazione appropriato per un dato problema?

#1 da (5 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Dì che stai facendo una revisione del codice e ti trovi di fronte a un modello di orchestrazione:

class OrchestrationClass {
  private Configuration _configuration;
  private DataStore1 _dataStore1;
  private EfficientComputationService _service;
  private ResultPrettifier _formatter;

  public DoSomething () {
     with (data = _dataStore1.LoadForConfiguration(_configuration)) {
        return _formatter.PrettyPrint(_service.Process(data));
     }
  }
}

In quali circostanze viene considerato un pattern / anti-pattern valido (e in che modo l'anti-pattern deve essere ripulito / refactored)?

Per contesto:

Di recente è apparso in una revisione del codice e diverse persone hanno menzionato il pattern / anti-pattern. Le ricerche sulla letteratura dei modelli standard, la ricerca su Google correlata e la scansione di post di blog / wiki hanno tutte portato a menzioni indirette. Il che mi porta a credere che questo pattern / anti-pattern non abbia ancora avuto un trattamento formale (o, se lo è, non è ancora online). Quindi, la domanda è qui, dove qualcuno più esperto o più letto potrebbe essere in grado di rispondere (o fornire un riferimento)

object-oriented refactoring design-patterns orchestration

posta blueberryfields 15.03.2014 - 21:39

fonte

3 risposte

Leggi altre domande sui tag object-oriented refactoring design-patterns orchestration

Possiamo dire che Java o C # hanno alberi ereditari unificati? Perché codice aggiuntivo e complessità quando modello di dati e interazione sono semplici è considerato uno svantaggio nel modello MVC

score 5 · Answer 1

Se per orchestrazione intendi prendere 2 parti e usarle per svolgere 1 compito più grande ... questo è chiamato programmazione dove vivo. Forse "astrazione" se ti senti vivace.

Intendo seriamente, questa è una programmazione orientata agli oggetti di base. Non è speciale e non ha bisogno di un nome di fantasia.

score 1 · Answer 2

Di solito parlo di Orchestration nel contesto dei servizi RESTful. Cioè, forniamo servizi RESTful che danno accesso diretto a varie risorse. Ma ci sono alcune squadre là fuori che, per una ragione o per l'altra, non sono in grado di gestirlo. Quindi forniamo un livello di orchestrazione in cima, dove leghiamo insieme le chiamate di risorse che ci aspettiamo che facciano.

(Questa idea è un po 'controverso, perché come previsto, quando sono stato in una squadra che lo ha fatto, a causa della politica il livello di orchestrazione ha semplicemente divorato e nascosto completamente lo strato REST.)

Ad eccezione di un'idea generale, non ho mai sentito che l'orchestrazione in quanto tale non si presenti nella progettazione dell'applicazione. In un certo senso, è una conseguenza del design modulare e poco complesso. Ad un certo punto, hai per tirare insieme i pezzi di basso livello.

Per me è una questione se si introduce uno strato di astrazione tra il livello main () o API e il livello logico. L'orchestrazione in cima? (Ad esempio, nel tuo metodo main () o nelle classi del gestore di app web) O se passi ad un livello di astrazione tra main () e gli operai?

Di solito lo faccio, perché mi piace fingere che la logica dell'applicazione sia disaccoppiata dall'implementazione dell'API. Ma non so se c'è un nome formale per questo, o regole intorno ad esso.

score 0 · Answer 3

Il tuo codice sembra un esempio del concetto "Single Level of Abstraction" (nota che intenzionalmente non uso la parola "pattern" qui), che è una buona pratica in circostanze normali. L'idea di questo concetto è di avere lo stesso livello di astrazione per tutte le istruzioni all'interno di un metodo.