Ho iniziato a leggere su Context design pattern. Ecco quello che ho capito dal testo:Puoi spiegare il modello di progettazione del contesto?
si dispone di una mappa che contiene tutte le variabili
si passa intorno a chi ne ha bisogno, in modo che non sarà necessario inviare tutte le variabili come parametri del metodo
L'ho "capito"?
Un oggetto di contesto fornisce accesso a dati e funzioni condivisi.
Può essere un elegante e flessibile sostituto:
The ACCU provides a more detailed description.
Se volete un esempio reale mondo del modello di contesto in Java, selezionare Google Android API's.
Quando si utilizza il modello di contesto, è necessario prestare attenzione al valore dependency graph. (Questo è il motivo per cui KaptajnKold lo chiama anti-pattern.)
Per limitare dipendenze non necessarie, utilizzare diversi contesti per scopi diversi. Mantieni i tuoi contesti il più semplici possibile e usa la composizione o l'ereditarietà per aggiungere complessità quando necessario.
L'ho "capito"?
Mi dispiace dirlo, non proprio.
L'obiettivo di Context Object è non di passare un sacco di parametri ai metodi implicitamente, come un mezzo per by-passando tipizzazione forte e l'incapsulamento. L'obiettivo è archiviare i dati con scope in modo generale, ma gestito, indipendentemente dai protocolli e dalla tecnologia di presentazione. I dati memorizzati all'interno di un ambito sono per natura condivisi, possono essere ancora strutturati e sono intrinsecamente diversi dai parametri one-off passati a un metodo.
Il modello oggetto contesto è stato introdotto per la prima volta nel Core J2EE Patterns 2nd Ed. La parte "Contesto" fa riferimento al fatto che l'oggetto contiene dati nel contesto di uno scope
(come application/session/request/conversation/flash).
Lo scopo è quello di separare, per quanto possibile, i dati dell'applicazione e la logica dalle classi specifiche di protocollo/presentazione-tecnologia come HttpSession e HttpRequest.
modello di attuazione
In Context Object, i dati destinati ad essere applicati/sessione/richiesta/altro campo di applicazione non è messo direttamente in ServletContext/HttpSession/HttpRequest/altra classe specifiche del protocollo. Invece, i dati sono memorizzati in una classe wrapper POJO, che quindi risiede nello ServletRequest/HttpSession/HttpRequest/altro.
L'oggetto contesto può memorizzare i dati in una mappa, ma non è necessario: è possibile memorizzare i dati in qualsiasi struttura/formato rilevante per il programma.
Un'applicazione può utilizzare una classe Context Object per ambito o più classi che suddividono i dati in modo ordinato, evitando un eccessivo bloat di classe e promuovendo la separazione dei problemi.
L'oggetto di contesto viene utilizzato dalle classi di presentazione in primo piano (Visualizzazioni, Front Controller, Dispatcher). Questi oggetti client di presentazione chiamano contextObject.get per recuperare i dati dell'ambito memorizzati e contextObject.put per archiviare i dati del contesto con ambito.
Non viene passato alla logica business/integrazione. Non è usato come mezzo per passare una moltitudine di parametri in oggetti business, passando da una forte digitazione. I livelli di business e di integrazione sono affiancati da delegati aziendali, servizi applicativi &/o facciate di sessione che utilizzano specifici parametri fortemente tipizzati.
Motivo Vantaggi
ServletContext o HttpRequestCommenti
Citando KaptajnKold: Penso che avete ottenuto. Tuttavia, penso anche che sia più un anti-modello da evitare. Scopri perché here.
I commenti si riferiscono alla versione non corretta di Oggetto contesto. Contesto L'oggetto stesso non è un anti-modello.
Mi ricorda l'API Win 32, in cui hai creato un oggetto enorme per una singola chiamata di metodo e l'ho passato come parametro, che IMO era un anti-pattern. Molte delle proprietà erano rilevanti solo per quella chiamata al metodo singolo, vale a dire la dimensione della finestra e la posizione per una finestra. Le proprietà di un oggetto di contesto non dovrebbero essere così di breve durata e dovrebbero essere pertinenti e comuni nell'intero ambito corrente. Alcune proprietà come la finestra radice/genitore sarebbero valide informazioni contestuali. Speriamo che questo aiuti le persone a pensare e valutare se stanno abusando del modello o meno. Non è certamente una scienza esatta. – AaronLS
Una classe che utilizza il contesto per inizializzare. Considera questo codice
public class BuildTagHandler extends TagHandler {
public BuildTagHandler(ServiceContext context) { // constructor
this.tagDAO = context.getTagDAO();
this.buildDAO = context.getBuildDAO();
}
Utilizzerai il contesto per costruire la tua classe. Nel file contesto, non si avranno implementazioni, ma molti di questi oggetti DAO
È possibile interpretarlo come un motivo di facciata o un'interfaccia enorme copre tutte le voci.
Vedere anche: [qual è il modello di progettazione oggetto del contesto?] (Http://stackoverflow.com/questions/771983/what-is-context-object-design-pattern) – emallove
Penso che la risposta alla glen-migliore dovrebbe essere quello giusto (63 vs 7 voti). –