Accoppiamento in contratti OOP: molti semplici valori di pochi oggetti complessi come argomenti?

Question

Accoppiamento in contratti OOP: molti semplici valori di pochi oggetti complessi come argomenti?

#1 da (1 voti)

0

Quando si progetta un'applicazione basata su OOP, si dovrebbe preferire il trasferimento di informazioni tra oggetti tramite oggetti complessi che fanno un sacco di lavoro di gestione, o dovrei prima recuperare i dati dall'oggetto holding e passare molti argomenti nella chiamata ?

Prendi, ad esempio, un'applicazione che fa econometria di timeseries e ha bisogno di trasferire un elenco di date come disponibile nel set di dati. Usando il primo approccio, consegnerei un handle all'intero oggetto dataset, che a sua volta contiene un oggetto-calendario, che contiene oggetti data. Tutti questi oggetti gestiscono diverse parti della funzionalità data, assegni di vacanza, ecc. All'interno dell'oggetto ricevente, la chiamata sarebbe in qualche modo simile a questa:

xlDate = MyDataset.MyCalendar.MyDate.convertToXlsFormat()

Mentre, ovviamente, ciò accadrebbe prima nell'altro caso, e xlDate sarebbe semplicemente un argomento.

Ora vedo che, in generale, l'accoppiamento stretto è cattivo e questo sembra un po 'stretto. Tuttavia, scrivo software scientifico, quindi i miei utenti sono sempre programmatori che di solito estendono il programma. Per loro, avere tutte le maniglie disponibili significa meno cambiamenti e meno di cui preoccuparsi.

Pensa a una situazione in cui avresti bisogno di prezzi azionari di ieri anziché di oggi. Nella prima situazione, un programmatore potrebbe facilmente adattare la funzione originale e sostituirla (dato che è possibile memorizzare funzioni in variabili in Matlab, che possono essere fatte da un file di configurazione), mentre nel secondo, avrebbe bisogno di aggiungere un controlla il flusso verso la funzione chiamante, e quindi aumenta la 'portata della responsabilità', se vuoi chiamarla così, il programmatore ha bisogno di un modello mentale più grande della sua funzione specifica.

Ho pensato anche a un wrapper, ma penso che sia solo il peggiore di entrambi: un oggetto enorme consegnato al wrapper, e la tua funzione originale si estende anche al wrapper. Non vedo i benefici qui.

Quindi: quanto è grande la dimensione e quanto profonda la nidificazione è troppo profonda?

object-oriented

posta phi 26.11.2014 - 12:00

fonte

1 risposta

Leggi altre domande sui tag object-oriented

Query sull'utilizzo del costruttore predefinito 'Window ()' da java.awt Trovare gli stessi numeri in una matrice

score 1 · Answer 1

Alcuni direbbero che anche chiamare il metodo di un altro oggetto è troppo profondo. Nel tuo caso, non dovresti avventurarti più lontano di MyDataset per tutto ciò che ti serve in quel metodo. Il fatto che tu abbia bisogno di spostarti più lontano è un'indicazione che il tuo metodo si sta estendendo oltre la portata di ciò che dovrebbe essere permesso di fare e minimizzare l'accoppiamento.

Se si utilizza MyDataset solo per ottenere MyCalendar, la correzione dovrebbe essere abbastanza ovvia: rimuovere la dipendenza non necessaria da MyDataset e semplicemente passare invece l'istanza MyCalendar.

Tuttavia, la tua classe potrebbe anche aver bisogno di un'istanza di MyDataset e MyCalendar. Ciò non significa che dovresti chiamare MyDataset.MyCalendar. Per risolvere questo problema, potresti fare una delle tante cose:

Sposta le funzionalità richieste di MyCalendar in MyDataset (non consigliato se non ha senso, e in questo caso sicuramente non lo fa)
Crea una funzione in MyDataset in cui le chiamate eseguono quella funzionalità per te (modello di facciata) (non consigliato per gli stessi motivi di cui sopra).
Trasforma l'istanza MyCalendar nel metodo (consigliato, solo se hai bisogno di MyCalendar per quella particolare funzione).
Trasforma l'istanza MyCalendar in costruttore, in altre parole un campo classe (consigliato, solo se MyCalendar è utilizzato in tutta la classe). Per facilitare questo con il tuo codice, potresti fornire un costruttore alternativo senza l'istanza MyCalendar passata, che assegna il valore del tuo campo di MyCalendar dall'istanza di MyDataset passato.

Se hai bisogno che una data sia in un determinato formato, ti incoraggio a resistere all'impulso di formattarlo all'interno della tua funzione. Questo è per due importanti motivi:

La tua funzione non dovrebbe fare qualcosa di diverso da quello che dovrebbe fare. Se ha bisogno di una data in un certo formato, dovrebbe già essere un argomento nel formato corretto passato alla tua funzione. Sposta il lavoro fuori dalla tua funzione e lo semplifica.
In questo modo si modularizza il codice e si semplifica. Il convertitore può essere nella sua classe. L'effetto finale è l'opposto dell'accoppiamento. Stai rimuovendo il codice, per quanto banale, che non si riferisce a ciò che dovrebbe fare quella classe e quindi eliminando il codice duplicato e mantenendolo facile da mantenere.

Mi sembra chiaro che tu sappia che l'accoppiamento è sbagliato, ma volevo solo indicare alcuni modi in cui cerco di affrontare il problema e spero di averti dato un paio di modi per ridurre e persino eliminare l'accoppiamento nel tuo codice.