¿Por qué se considera una práctica recomendada empaquetar el código del programa y el código de la interfaz gráfica en diferentes clases?

El concepto al que se refiere tu profesor es algo que se llama Separación de preocupaciones.

Para ilustrarlo en su contexto, si completa su programa y luego decide que quiere portarlo a Android; tendrá que volver a escribir mucho más código que si hubiera mantenido la lógica de cuadrícula por separado.

Un control de interfaz solo debe preocuparse por dibujar lo que se dice, la lógica de cuadrícula solo debe preocuparse por lo que está en la cuadrícula, no cómo dibujarlo.

¿Esto ayuda?

Para que sea más fácil cambiar tu código . ¿Qué pasa si mañana no quieres usar una cuadrícula sino una lista? Cuando su GUI está separada de su lógica, es fácil de hacer.

Además, escribirás un código que es más reutilizable . Si su GUI no contiene su código técnico, también puede reutilizarlo. Crea una cuadrícula elegante con todas las opciones una vez y puedes usarla en otros proyectos. Mezclar su GUI y código técnico evitará que haga esto.

También te da un código que es más fácil de leer. Si su cuadrícula solo hace la funcionalidad GUI, es más fácil de entender o cambiar su código.

El enfoque general de la programación orientada a objetos a una separación de preocupaciones , donde el código se divide en tareas lógicas. Inicialmente, esto puede parecer más trabajo. Pero a medida que su proyecto crece, facilita el seguimiento y la administración de su código.

Por esa razón, probablemente sería mejor separar el código que es responsable de mostrar una cuadrícula y el código que trata los datos que se pueden mostrar en esa cuadrícula.

Cuando se aplica la separación de preocupaciones a la estructura de una aplicación, el resultado es arquitectura multinivel (o arquitectura N-Tier) enlace .

Para aprovechar las otras respuestas y darte un ejemplo, deberías permitirte inyectar tu lógica / datos en tu grilla o viceversa.

El control de la cuadrícula puede exponer un método Render o un método DataBind .

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

o

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

Luego, su unidad lógica puede tomar el control de cuadrícula y vincularlo con un objeto de datos o llamar manualmente el render con el objeto de datos cada vez que algo cambie.

Su GridLogic también debe tener una referencia al GridControl para que pueda enlazarse a cualquier entrada / evento que suceda.

La idea detrás del enlace de datos es que su control de cuadrícula observa los datos en busca de cualquier cambio y se vuelve a representar, mientras que al exponer una función de renderización significa que su unidad lógica reproduce manualmente el control.

De cualquier manera, dividir su lógica y cuadrícula de esta manera le permite cambiar una de la otra más fácilmente sin romper nada. También puedes escribir un nuevo control como ListControl para mostrar tus datos como una lista en lugar de una cuadrícula sin tener que volver a escribir toda tu lógica.

Recomiendo encarecidamente que eche un vistazo a arquitectura MVC .

Es un refinamiento del concepto que ha mencionado (separación del código del programa y la interfaz gráfica). MVC significa Model-View-Controller. Aquí el modelo es los datos, la vista es el código de la interfaz gráfica y el controlador es el código que procesa los datos.

De esta manera has creado tres partes de tu programa. Cada parte se puede reemplazar sin requerir cambios en las otras dos partes.

Depende de los tipos de cambios futuros que pueda esperar que ocurran. Lo que desea minimizar es el número de cambios de código manuales necesarios para implementar correctamente cada cambio funcional único.

Donde MVC gana es si los cambios se limitan a la parte V, o "Ver".

En mi experiencia, es mucho más probable que los cambios afecten las tres partes, por lo que es mejor que no estén separados por no . Para mostrar lo que quiero decir, hace tiempo que utilizo una técnica que desarrollé llamada Diálogos dinámicos , en el que se ingresa en el código fuente un nuevo requisito, como "permitir al usuario editar el nombre, y cuando haya completado la ejecución de XYZ" como un único bloque de texto:

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

en lugar de múltiples ediciones separadas, para especificar que existe el campo de edición, para crear un identificador único para ello, para vincularlo a la variable del modelo y para vincularlo con el controlador de eventos de foco perdido.

Si vas a ese enlace, verás un ejemplo más complejo.

Básicamente, la idea es convertir el código en un idioma específico del dominio, a fin de minimizar el número de ediciones para lograr el propósito. La razón por la que desea hacerlo no es solo para reducir el esfuerzo, pero para reducir la oportunidad de introducir errores, olvidando o codificando incorrectamente una o más de las ediciones. También reduce el tamaño del código fuente en aproximadamente un orden de magnitud.

No es gratis. Introduce una curva de aprendizaje de una sola vez para el programador.

La interfaz gráfica depende del sistema, mientras que el núcleo del juego es un algoritmo totalmente independiente del sistema en el que se ejecuta. Mantener las dos aplicaciones hará que el programa sea más fácil de mantener, probar y depurar porque los cambios en un subsistema no afectan la forma en que funciona el otro. Incluso si no te importa la portabilidad, apuesto a que te preocupas por la solidez y la capacidad de mantenimiento de tu programa.