Perchè è considerata una buona pratica confezionare il codice del programma e il codice dell'interfaccia grafica in classi diverse?

Il concetto cui si riferisce il tuo insegnante è qualcosa chiamato Separation of Concerns.

Per illustrarlo nel tuo contesto, se completi il tuo programma e poi decidi di portarlo su Android; dovrai riscrivere molto più codice che se avessi separato la logica della griglia.

Un controllo dell'interfaccia dovrebbe riguardare solo il disegno di ciò che viene detto, la logica della griglia dovrebbe riguardare solo ciò che è nella griglia, non come disegnarlo.

Questo aiuto?

Per renderlo più facile cambiare il tuo codice . E se domani non volessi usare una griglia ma una lista? Quando la tua GUI è separata dalla tua logica è facile da fare.

Inoltre, scriverai il codice più riutilizzabile . Se la tua GUI non contiene il tuo codice tecnico, puoi anche riutilizzarlo. Crea una griglia fantasia con tutte le opzioni una volta e puoi usarla in altri progetti. Mescolando la tua GUI e il codice tecnico ti impedirai di farlo.

Ti dà anche il codice che è più facile da leggere. Se la tua rete funziona solo con la GUI, è più facile da capire o cambia il tuo codice.

L'approccio generale della programmazione orientata agli oggetti a una separazione delle preoccupazioni , in cui il codice viene separato in attività logiche. Inizialmente, questo può sembrare più lavoro. Ma con la crescita del tuo progetto, è più facile monitorare e gestire il tuo codice.

Per questo motivo, sarebbe probabilmente meglio separare il codice responsabile della visualizzazione di una griglia e di un codice che tratta i dati che potrebbero essere visualizzati in quella griglia.

Quando Separation of Concerns viene applicato a una struttura di applicazione, il risultato è architettura multilivello (o architettura N-Tier) link .

Per costruire sulle altre risposte e darti un esempio, dovresti in qualche modo permetterti di iniettare la tua logica / dati nella tua griglia o viceversa.

Il controllo della griglia può esporre un metodo Render o un metodo DataBind .

class GridControl
{
    public Render(GridData data) { ... }
}

o

class GridControl
{
    public DataBind(GridData data) { ... }
}

Quindi la tua unità logica può prendere GridControl e associarvi un oggetto dati o chiamare manualmente il rendering con l'oggetto dati ogni volta che qualcosa cambia.

Il tuo GridLogic dovrebbe anche avere un riferimento a GridControl in modo che possa legarsi a qualsiasi input / evento che si verifica.

L'idea alla base del collegamento dei dati è che il tuo controllo di griglia controlla i dati per eventuali modifiche e si ricompone dove, mentre esponendo una funzione di rendering, la tua unità logica restituisce manualmente il controllo.

In entrambi i casi, suddividere la tua logica e la griglia in questo modo ti consente di cambiare più facilmente uno degli altri senza rompere nulla. Puoi anche scrivere un nuovo controllo come ListControl per mostrare i tuoi dati come una lista invece di una griglia senza dover riscrivere tutta la tua logica.

Raccomando vivamente di dare un'occhiata a architettura MVC .

È una raffinatezza del concetto che hai menzionato (separazione del codice del programma e dell'interfaccia grafica). MVC è l'acronimo di Model-View-Controller. Qui il modello è il dato, View è il codice dell'interfaccia grafica e COntroller è il codice che elabora i dati.

In questo modo hai creato tre parti del tuo programma. Ogni parte può essere sostituita senza richiedere modifiche nelle altre due parti.

Dipende dal tipo di cambiamenti futuri che ci si può aspettare che si verifichino. Quello che vuoi minimizzare è il numero di modifiche al codice manuale necessarie per implementare correttamente ogni singola modifica funzionale.

Dove vince MVC è se le modifiche sono confinate alla parte V, o "Visualizza".

Nella mia esperienza, è molto più probabile che i cambiamenti riguardino tutte e tre le parti, quindi è meglio se sono non separati. Per mostrare cosa intendo, ho utilizzato a lungo una tecnica che ho sviluppato chiamata Dialoghi dinamici , in cui un nuovo requisito, come "consenti all'utente di modificare il nome e quando completo esegui XYZ", viene inserito nel codice sorgente come un singolo blocco di testo:

if(deTextEdit(&sName)){
  // do XYZ
}

invece di più modifiche separate, per specificare che il campo di modifica esiste, per creare un identificativo univoco per esso, per associarlo alla variabile del modello e per collegarlo al gestore di eventi con fuoco perso.

Se vai a quel link vedrai un esempio più complesso.

Fondamentalmente l'idea è di trasformare il codice in un linguaggio specifico del dominio, in modo da minimizzare il numero di modifiche per raggiungere lo scopo. Il motivo per cui vuoi farlo non è solo quello di ridurre lo sforzo, ma per ridurre l'opportunità di introdurre bug, dimenticando o codificando erroneamente una o più modifiche. Riduce anche la dimensione del codice sorgente di circa un ordine di grandezza.

Non è gratuito. Introduce una curva di apprendimento una tantum per il programmatore.

L'interfaccia grafica dipende dal sistema, mentre il core del gioco è un algoritmo totalmente indipendente dal sistema su cui gira. Mantenere i due appartamenti renderà il programma più facile da mantenere, testare ed eseguire il debug perché le modifiche in un sottosistema non influiscono sul modo in cui l'altro funziona. Anche se non ti interessa la portabilità, scommetto che ti interessi per robustezza e manutenibilità del tuo programma.