Il modello di fabbrica è uno schema corretto per la situazione descritta qui?

Question

Il modello di fabbrica è uno schema corretto per la situazione descritta qui?

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

2

Il pattern factory è uno schema corretto quando vogliamo consolidare gli oggetti correlati?

Problema - Nella decoder, Ho un utente-io, sostanzialmente l'interfaccia per controllare il decoder - L'utente-io può essere RCU ie telecomando, frontale - i pulsanti sul set-top box e il posteriore-rcu - questo è usato per testare il gruppo di scatole settop.

Soluzione - Un oggetto factory che controlla se il tipo utente-io è rcu o pannello frontale. Questo oggetto factory creerà il prodotto richiesto. L'oggetto factory ha una dipendenza dall'utente astratto-io. Questo utente-io costringerà ad avere la classe concreta i seguenti metodi: Canale su, Canale giù, Volume su, Volume giù, Accensione / discesa e il tasto numerico (che potrebbe non essere nel pannello frontale). Quindi il pannello frontale non farà nulla sul tasto del codice del metodo premuto.

L'oggetto factory creerà la classe concreta (rcu o fp) e memorizzerà nel puntatore del tipo utente-io.

La classe principale, creerà un oggetto factory, che può essere singleton e avrà gli oggetti correlati con esso.

Posso dire che qui il vantaggio che otterrò è il seguente un. Le classi correlate sono consolidate / organizzate insieme. b. Quando voglio accedere a rcu o fp. Li vedo solo come utente-io, il che è vero per concetto. c. Il FP avrà la funzionalità del led o della luce del flash. Quindi, mentre creo il fp, ho bisogno di creare anche un oggetto LED. Una dipendenza FP sul LED, che posso nascondere all'utente

Svantaggio - 1. Sebbene il pannello frontale non abbia la funzionalità di premere il tasto numerico. Aggiungerò anche il metodo dummy per frontpanel.

java c++ design-patterns

posta user3629119 11.11.2014 - 14:43

fonte

2 risposte

Leggi altre domande sui tag java c++ design-patterns

Architettura: memorizzazione di tutte le proprietà come JsonProperty in NDB? Struttura dati ben adattata per le voci duplicate

score 1 · Answer 1

I prodotti finali che desideri creare sono

1) Unità di controllo remoto

2) Pannello frontale

3) Pulsanti sulla casella di installazione

Quindi, penso che la situazione non sia altamente dinamica. (Potrebbe essere in futuro potrebbe essere necessario aggiungere un altro tipo di nuovo dispositivo.)

così, con Factory Method / Abstract factory ci ritroviamo con una gerarchia di classi creator parallele. Questo approccio alla creazione di oggetti aggiungerebbe inutilmente troppe classi di creativi.

quindi, una piccola variazione sul metodo factory è "Static Factory method" che assicurerà che crei oggetti di classe richiesti in base alle necessità.

E come detto sopra, potresti aver bisogno solo di una "Base Virtuale" che definisce le operazioni generali e il comportamento predefinito. La classe derivata sostituirà ciò che è necessario per questo.

score 0 · Answer 2

Potresti usare una fabbrica, ma hai detto che la factory avrebbe " una dipendenza sull'utente astratto-io ", che sarebbe già stata istanziata.

La fabbrica dovrebbe essere il mezzo con cui viene creato l'utente astratto-io in primo luogo. Se questo è già stato creato, hai già superato il punto in cui la factory sarebbe stata utile.

Succederà qualcosa che determinerà quale user-io dovrebbe essere usato. Questo potrebbe essere un evento UX, un valore di input o una differenza nel segnale IR, qualunque sia. Questo dovrebbe essere ciò di cui la fabbrica ha una dipendenza, se una fabbrica è davvero necessaria.

Tecnicamente ti serve solo una classe astratta o un'interfaccia, in cui l'implementazione FP non supporta tutto. In alternativa, l'interfaccia comune potrebbe includere solo la funzionalità comune delle due implementazioni.

In definitiva solo tu hai abbastanza informazioni per decidere come implementare la soluzione, possiamo solo aiutarti a capire dove alcuni strumenti e modelli possono essere utili.