Come spiegare a qualcuno che una struttura dati non dovrebbe disegnare da sola, spiegando la separazione delle preoccupazioni?

Question

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

Ad esempio, diciamo che si ottiene una struttura dati che contiene un set di record dal "database" e si desidera visualizzare tale record in un componente dell'interfaccia utente all'interno dell'applicazione.

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

E quindi in base a questa logica, il set di record 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 tua interfaccia utente, avrai un vero casino sulle tue mani; dovrai estendere un'altra classe per ciascun componente dell'interfaccia utente che esegui il rendering dalla classe base del tuo set di record;

Sono ben consapevole della "pulizia" del pattern MVC (e con ciò intendo dire che non confondete i vostri dati (il Modello) con l'interfaccia utente (la vista) o le azioni che si svolgono sui dati (il controller più o meno ... okay, in realtà l'API non dovrebbe davvero gestirlo ... e il controller dovrebbe fare solo il minor numero di chiamate ad esso che può, indicandogli quale vista visualizzare)) Ma è sicuramente molto più pulito rispetto all'utilizzo di strutture dati per il rendering dei componenti dell'interfaccia utente!

C'è qualche altro consiglio che potrei spedire a parte l'esempio sopra? Capisco che quando si impara OOP per la prima volta si passa attraverso "un palcoscenico" in cui si desidera solo estendere tutto.

Seguito da una fase in cui si pensa che i modelli di progettazione sono la soluzione di ogni singolo problema ... che non è del tutto corretto ... thanks Jeff.

Esiste un modo per spingere delicatamente questo ragazzo nella giusta direzione? Avete altri esempi che potrebbero aiutare a spiegare il mio punto a lui?

Answer 1

Hai sentito parlare di Martin Fowler?

Separating User Interface Code

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 creare un tipo generico di interfaccia che lo trovi a metà strada, ma il componente dell'interfaccia utente dovrebbe occuparsene per il resto.

Answer 2

Questo si riduce alle responsabilità funzionali e non funzionali. Che cosa fa la struttura dati e come viene visualizzata sono due cose completamente separate - essenzialmente la radice del pattern MVC.

C'è anche una nozione di dipendenze circolari qui. Dato che l'interfaccia utente deve conoscere le strutture dati, se consenti alle strutture dati di dipendere dall'interfaccia utente, hai una bella palla di fango.

Answer 3

Generalmente sul punto di disaccoppiamento:

1. Non solo può esserci diversi componenti dell'interfaccia utente rendendo la stessa struttura dati. Potresti anche avere interfacce utente completamente diverse (Web, applicazioni desktop, ...) Ora, potresti creare sottoclasse Person con WebPerson e DesktopPerson(questo suona già sbagliato, non è vero? La denominazione non riguarda semplicemente il tipo di Persona: si tratta di qualcos'altro).

2. Ogni interfaccia utente può lavorare su diversi tipi di persone, ad es. Teacher e Student. Quindi 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 per utilizzare il campo dati aggiuntivo "salario" (e assumiamo un'unica ereditarietà), deve implementare "drawAddressFields()" ancora una volta!

Così forse l'argomento di "questo causerà molto più lavoro" contribuirà a creare qualche motivazione :-)

BTW, porterà automaticamente alla creazione di qualche delegato che implementa il codice di drawAddressField(), che si evolverà quindi nella creazione di un componente che fa il disegno separatamente dalla struttura dei dati.