¿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?

15

Entonces, mi profesor me dice que es muy importante no encapsular el código del programa y el código de la interfaz gráfica en las mismas clases, pero mantenerlos completamente independientes. Actualmente estoy escribiendo un juego de iphone con una cuadrícula en él. Para mí tiene mucho más sentido Crear tanto la cuadrícula gráfica como el código técnico en la misma clase "Cuadrícula". ¿Será que otro programador frunce el ceño sobre esto? ¿Es realmente muy importante mantener la interfaz gráfica y el código independientes? ¿Qué problemas surgirán si no lo hago?

¡Gracias!

EDITAR: gracias chicos! ¿Estaría bien para mí escribir el proyecto primero y luego copiar el código para formar la separación del diseño de las preocupaciones? Sé que esto puede derrotar totalmente el propósito, pero al igual que la práctica ... ¿Para que la próxima vez pueda aplicar este patrón de diseño desde el principio?

    
pregunta John 06.05.2011 - 13:37
fuente

8 respuestas

17

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?

    
respondido por el Russ Clarke 06.05.2011 - 13:41
fuente
4

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.

    
respondido por el Carra 06.05.2011 - 14:40
fuente
3

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.

    
respondido por el Jonathan Wood 06.05.2011 - 13:41
fuente
1

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 .

    
respondido por el StuperUser 06.05.2011 - 14:33
fuente
0

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.

    
respondido por el Raynos 06.05.2011 - 13:50
fuente
0

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.

    
respondido por el DPD 06.05.2011 - 15:13
fuente
0

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.

    
respondido por el Mike Dunlavey 06.05.2011 - 16:01
fuente
0

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.

    
respondido por el Gus 06.05.2011 - 16:39
fuente

Lea otras preguntas en las etiquetas