pregunta de diseño orientado a objetos para la aplicación gui

Question

chicos, estoy programando una GUI para una aplicación, un contenedor de CD para insertar cd, y actualmente no estoy muy claro y creo que necesito ayuda para aclarar mi comprensión sobre el diseño orientado a objetos .

así que, primero, utilizo el patrón de observador para construir clases abstractas Modelo y Vista y también los modelos concretos (contenedor cd) y vistas concretas (vista contenedor cd). Entonces comienzo a utilizar el marco wxwidget para diseñar y aspecto gráfico o el diseño (CDContainerWidget, desde wxPanel) para el contenedor de CD y otros controles Unidad central interfaz gráfica de usuario (de wxFrame), etc ..

así que ahora tengo tres clases: CDContainerModel (contenedor cd), CDContainerView (la clase para patrón de observador) y CDContainerWidget (los controles gui). entonces no estoy tan claro sobre lo que debo hacer con CDContainerView y CDContainerWidget?

Creo que CDContainerWidget y CDContainerView necesitan CDContainerModel. Pienso en cuatro enfoques, pero no sé cuál es apropiado:

1). asocie CDContainerWidget a CDContainerView como una variable miembro, luego coloque CDContainerView en Main Frame como una variable miembro.

class CDContainerView: 
    def __init__: 
    self.gui=CDContainerWidget 

class MainFrame: 
    def __init__: 
    CDContainerView 

2). CDContainerView subclase CDContainerWidget:

class CDContainerView(CDContainerWidget): 

class MainFrame: 

    def __init__: 

    CDContainerView 

3). CDContainerWidget subclase CDContainerView:

class CDContainerWidget(CDContainerView): 

class MainFrame: 
    def __init__: 
    CDContainerWidget 

4). en lugar de utilizar CDContainerWidget y CDContainerView, utilizar sólo una sola clase CDContainerBig qué subclase de la clase abstracta Ver y wxPanel

class CDContainerBig(View, wxPanel) 

Mi pregunta es ¿cuál es la solución correcta? He leído la página wiki del patrón MVC, pero realmente no entiendo su descripción y no sé cómo y también me pregunto si es apropiado aplicarlo a mi problema.

Bueno, he puesto algunos comentarios adicionales. originalmente, cuando empiezo a diseñar para programar, no pensé mucho y simplemente elegí, 2) abordar. pero ahora, creo que 3) es bueno. ya que es razonable poner el widget en el widget (CDContainerWidget en MainFrame). pero no estoy realmente seguro También parece que con el patrón de observador, las tres clases son retorcidas y awkard. Y a veces, me parece que estos 4 tal vez son lo mismo, solo quién incluye quién o quién envía mensajes a quién. Bueno, creo que realmente necesito una aclaración sobre este punto.

Además, estoy a favor de 3) debido a un punto práctico. CDContainerWidget en realidad contiene varios componentes de subwidget (botón, cuadro de entrada, etc.) y si cambiamos algo así como establecer nuevos valores a través de un widget de subcomponente, para 1), necesitamos CDContainerWidget para estar al tanto de CDContainerView, para permitir que CDContainerView notifique otras vistas. para 2) lo que es peor, CDContainerWidget debe tener en cuenta su childen CDContainerView. para 3) CDContainerWidget en sí mismo es CDContainerView, por lo que es bastante razonable. para 4) bueno, fácil pero ninguna separación lógica. este es mi propio pensamiento, no sé si es correcto.

Gracias!

Answer 1

Lo que podría hacer que esto sea más fácil para ti, el acoplamiento entre clases estaría implementando un patrón de ranura de señal con algo como Spiff Signal, o uno de los otros módulos de señal/ranura disponible.

Al desacoplar la lógica de comunicación puede liberarse por completo de la necesidad de módulos para hablar directamente sino que utilizan el paso de mensajes con las devoluciones de llamada.

Answer 2

La opción 1 parece ser la más adecuada. En general, debe evitar la herencia a menos que el patrón lo requiera, o hay alguna otra razón convincente para usarla. El uso excesivo de la herencia hará que su código esté mucho más integrado de lo que debe ser.