Modelli di design: estrai i tipi di istanza in diversi bucket

Question

Modelli di design: estrai i tipi di istanza in diversi bucket

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

2

Ho la seguente gerarchia di tipi:

interface I:
    ----+class B implements I
    ----+class C implements I
    ----+class D implements I

Ho un'altra classe Consumer1 che supporta tipi C e D ma non B (nei suoi vari metodi) e una classe Consumer2 che supporta il tipo B . Ho il controllo totale su Consumer1 e Consumer2 , quindi posso scegliere come implementarli. Ora, in fase di esecuzione, mi aspetto che i miei chiamanti mi forniscano una raccolta di I s e deciderò internamente se indirizzarli a Consumer1 o Consumer2 .

Ora, un pessimo modo non-OOP è di fare un controllo di if instanceof su tutto il posto e fare casino. Un'alternativa è registrare una classe di supporto Map<Class<?>, Class<?>> che deve contenere {{B,Consumer2}, {C,Consumer1}, {D,Consumer1}} . È pessimo come il precedente perché dovrò eseguire il cast degli oggetti dopo aver capito se inviarli a Consumer1 o Consumer2 .

Una seconda alternativa consiste nell'applicare un modello Visitor che risolverebbe questo piuttosto ordinatamente, ma impedisce che la mia interfaccia venga ulteriormente estesa (a meno che non modifico il visitatore). C'è un'alternativa più ordinata?

design-patterns

posta Apoorv Khurasia 01.04.2013 - 05:25

fonte

3 risposte

Leggi altre domande sui tag design-patterns

Qual è lo scopo della separazione dei percorsi in singoli moduli con Node.js ed Express? Nasconde la complessità dei client API unendo le risorse a una pratica corretta?

score 1 · Answer 1

Penso che Chain of responsibility sia la soluzione migliore per questo problema. Ciò lo renderà opportunamente estensibile, mentre incapsulerà le eventuali chiamate instanceof nel consumatore stesso.

Da aggiungere a questo. Non penso che usare instanceof sia sbagliato. Ha solo bisogno di essere correttamente incapsulato, proprio come in questo caso.

score 0 · Answer 2

Considera il modello di visitatore aciclico . Permette di estendere la gerarchia senza necessariamente influenzare tutti i visitatori (solo quelli che devono visitare tutti gli oggetti, che non sembrano essere presenti nella progettazione).

In alternativa, penso che non sia un problema avere i controlli di tipo nel consumatore stesso, dal momento che saranno interessati a controllare solo i tipi con cui lavorano (non così diversi dai visitatori aciclici). Quindi potresti spedire I s a tutti i consumatori e solo quelli che si interessano veramente al tipo di runtime faranno qualcosa con loro, o potresti farlo in uno stile di catena di responsabilità, come già suggerito nei commenti di John Cartwright.

score 0 · Answer 3

0

Perché i consumatori non sono in grado di svolgere il loro lavoro solo con l'interfaccia I? I consumatori dovrebbero richiedere istanze di I, non fare affidamento su specifiche di B, C o D.

risposta data 16.06.2013 - 23:36

fonte