Come spiegare a qualcuno che una struttura di dati non deve trarre in sé, spiegando separazione degli interessi?

Question

Ho un altro programmatore che sto cercando di spiegare perché è che un componente di interfaccia utente non dovrebbe essere anche una-struttura di dati.

Per esempio dire che si ottiene una struttura di dati che contiene un record impostato dal "database", e si desidera visualizzare il record-set in un componente dell'interfaccia utente all'interno dell'applicazione.

Secondo questo programmatore (che rimarrà senza nome, è giovane e io gli sto insegnando ...), dovremmo sottoclasse la struttura di dati in una classe che trarrà il componente dell'interfaccia utente all'interno della nostra applicazione !!!!! !

E così secondo questa logica, il record-set dovrebbe gestire il disegno dell'interfaccia utente.

****** Responsabile Desk *****

So che chiedere un record-set per disegnare in se è sbagliato, perché, se si desidera rendere la stessa struttura di dati su più di un tipo di componente sulla vostra interfaccia utente, si stanno per avere un vero e proprio pasticcio sul vostro mani; avrete bisogno di estendere un'altra classe per ogni componente dell'interfaccia utente che si esegue il rendering dalla classe base del record-set;

Sono ben consapevole della "pulizia" del del pattern MVC (e che quello che voglio dire è di non confondere i dati (il modello) con l'interfaccia utente (la vista) o le azioni che si posizionare sui dati (il controller più o meno ... ok non proprio l'API in realtà dovrebbe gestire tale ... e il controller dovrebbe solo fare il minor numero di chiamate ad esso, come si può, dicendogli che vista al rendering)), ma è certamente alot più pulita rispetto all'utilizzo di strutture dati per rendere i componenti dell'interfaccia utente!

C'è qualche altro consiglio ho potuto inviare il suo modo diverso da quello dell'esempio di cui sopra? Capisco che quando si impara prima OOP si passa attraverso "una fase" in cui si Dove vogliono solo per estendere tutto.

seguito da una fase in cui si pensa che Design Patterns sono la soluzione ogni singolo problema ... che non è del tutto corretto o ... grazie Jeff .

C'è un modo che io possa spingere delicatamente questo ragazzo nella giusta direzione? Avete altri esempi che potrebbero aiutare a spiegare il mio punto a lui?

Answer 1

Avete sentito parlare di Martin Fowler?

separazione dell'interfaccia utente Codice

In ogni caso, se si vuole andare oltre in quella direzione di aggiungere rendere metodi ai suoi controlli di dati, avere lo sguardo al "accoppiamento lasco". Va bene per creare un certo tipo generico di interfaccia che lo porta a metà strada, ma la componente di interfaccia utente dovrebbe prendere il resto del modo.

Answer 2

Questo riduce a funzionale vs responsabilità non funzionali. Ciò che la struttura dei dati fa e come è visualizzata sono due cose completamente separate -. Essenzialmente la radice del pattern MVC

C'è anche una nozione di dipendenze circolari qui. Dal momento che l'interfaccia utente deve conoscere le strutture di dati, se si consente alle strutture di dati per poi dipendono l'interfaccia utente, che hai te stesso ottenuto un bel po 'palla di fango.

Answer 3

Generalmente sul punto di disaccoppiamento:

1. Non solo ci può essere diversi componenti dell'interfaccia utente rendendo la stessa struttura di dati. Si può anche avere completamente diverso interfacce utente (web, applicazioni desktop, ...) Ora, naturalmente, si potrebbe creare una sottoclasse Person con WebPerson e DesktopPerson (questo suona già sbagliato, non è vero? La denominazione non è semplicemente circa il tipo di persona -. si tratta di qualcos'altro)

2. Ogni utente potrebbe lavorare su diversi tipi di persone, ad esempio, Teacher e Student. Così otteniamo WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher e DesktopStudent.

Ora diciamo, WebPerson definisce le "drawAddressFields ()" metodo per disegnare una versione web dei campi di indirizzo. Ma dal momento che WebTeacher deve derivare da Teacher di utilizzare il campo di dati supplementari "salario" (e supponiamo ereditarietà singola), è necessario attuare "drawAddressFields ()", ancora una volta!

Quindi, forse l'argomento di "questo farà sì che molto più lavoro" contribuirà a creare un po 'di motivazione: -)

A proposito, verrà automaticamente portare alla creazione di qualche delegato che implementa il codice di drawAddressField (), che poi evolvere verso la creazione di un componente che fa il disegno separatamente dalla struttura di dati.