Gerarchia parallela di classe / interfaccia con il motivo di progettazione della facciata?

Question

Gerarchia parallela di classe / interfaccia con il motivo di progettazione della facciata?

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

3

Circa un terzo del mio codice è racchiuso all'interno di una classe Facade. Nota che questa non è una classe "Dio", ma in realtà rappresenta una singola cosa (chiamata Line ). Naturalmente, delega le responsabilità al sottosistema dietro di esso.

Quello che succede è che due delle classi del sottosistema ( Output e Timeline ) hanno tutti i loro metodi duplicati nella classe Line , che effettivamente rende Line sia un Output che un% codice%. Sembra ragionevole creare interfacce di Timeline e Output , in modo che la classe Timeline possa implementarle entrambe. Allo stesso tempo, sono preoccupato di creare strutture parallele di classe e di interfaccia.

Vedete, ci sono diversi tipi di linee Line , AudioLine , che usano tutti lo stesso tipo di VideoLine , ma diversi tipi di Timeline ( Output e AudioOutput , rispettivamente). Questo significherebbe che dovrei creare anche VideoOutput e AudioOutputInterface . Quindi non solo dovrei avere una gerarchia di classi parallele, ma ci sarebbe anche una gerarchia di interfaccia parallela.

C'è qualche soluzione a questo difetto di progettazione?

Ecco un'immagine della struttura di base (meno la classe Timeline, benché sappia che ogni linea ha una linea temporale):

NOTA:misonoappenaresocontochelaparola"linea" in VideoOutputInterface potrebbe essere simile a quella di una funzione simile alla classe Timeline . Non lo fanno, solo per chiarire.

object-oriented design programming-practices java design-patterns

posta sinθ 07.08.2013 - 19:33

fonte

3 risposte

Leggi altre domande sui tag object-oriented design programming-practices java design-patterns

Strategia di test unitario per chiamate di metodo stratificate (o derivate) Come serializzare e deserializzare l'espressione lambda in F #?

score 1 · Answer 1

What ends up happening is that two of the subsystem classes (Output and Timeline) have all of their methods duplicated in the Line class, which effectively makes Line both an Output and a Timeline.

La frase sopra sembra un cattivo design.

Mi aspetto che la maggior parte dei metodi in una classe di facciata invochino più classi di sottosistemi o almeno più metodi in una singola classe di sottosistema.

Se la tua facciata sta eseguendo molte deleghe semplici (ad esempio, il metodo di facciata doSomething chiama semplicemente un'altra classe ' doSomething ), probabilmente dovresti refactoring.

Specificamente, se una classe delegata non interagisce con il resto del sottosistema, probabilmente il client dovrebbe probabilmente interagire direttamente con il delegato, invece che attraverso la facciata.

score 1 · Answer 2

Alcuni dei tuoi clienti sono interessati principalmente a Line come una timeline, e altri sono interessati principalmente da Output? In tal caso, prendi in considerazione lo sprouting di classi o interfacce da Line che si frappongono tra esso e i client, ognuna di queste nuove classi avvolge un puntatore a una riga e astrae l'implementazione mentre mette a fuoco l'API.

All'inizio, sembra una facciata per una facciata, ma apre nuovi orizzonti di refactoring. Puoi tirare i metodi da Line alle nuove classi. Potresti scoprire nuove classi di supporto che puoi estrarre. Forse anche una delle tue classi di implementazione apparirà qui.

score 0 · Answer 3

Sono davvero d'accordo con entrambe le altre risposte. Il problema principale qui è che Line ha più responsabilità. Stai cadendo nell'errore di credere che le classi corrispondano a una "cosa", quando in realtà una classe dovrebbe corrispondere a una "responsabilità".

Detto questo, è certamente possibile per una classe avere la sola responsabilità di "fornire una facciata unica che deleghi a diverse altre classi per semplificare il codice cliente". Sembra che potrebbe essere quello che stai descrivendo; dipende se Line ha un proprio comportamento, oltre alla delega. Di solito non lo faccio, perché non trovo ingombrante che il codice del client parli con diversi oggetti, ma questo può essere attribuito alle preferenze personali.

It seems to make sense to make Output and Timeline interfaces, so that the Line class can implement them both. At the same time, I'm worried about creating parallel class and interface structures.

Che cosa ti motiva a farlo? C'è qualche bisogno di quel cambiamento, o è solo che pensi che sarebbe "più giusto"? Se quest'ultimo, vorrei lasciare il tuo codice così com'è. Il codice di lavoro è il re.