domanda di progettazione orientata agli oggetti per l'applicazione GUI

Question

ragazzi, sto programmando una GUI per un'applicazione, un contenitore di cd per inserire cd, e attualmente non sono molto chiaro e penso di aver bisogno di aiuto per chiarire la mia comprensione della progettazione orientata agli oggetti .

quindi, in primo luogo, utilizzo il pattern observer per creare classi Model e View astratti e anche i modelli concreti (contenitore cd) e le viste concrete (cd container view). Poi inizio a utilizzare il framework wxWidget per la progettazione e l'aspetto grafico o il layout (CDContainerWidget, da wxPanel) per il contenitore cd e altri gui controlli MainFrame (da wxFrame), ecc ..

così ora ho tre classi: CDContainerModel (contenitore cd), CDContainerView (la classe per il modello di osservatore) e CDContainerWidget (i controlli dell'interfaccia grafica). quindi non sono chiaro su cosa dovrei fare con lo CDContainerView e lo CDContainerWidget?

Penso che CDContainerWidget e CDContainerView abbiano entrambi bisogno di CDContainerModel. Penso a quattro approcci, ma non so quale sia appropriato:

1). associare CDContainerWidget a CDContainerView come variabile membro, quindi inserire CDContainerView nel Main Frame come variabile membro.

class CDContainerView: 
    def __init__: 
    self.gui=CDContainerWidget 

class MainFrame: 
    def __init__: 
    CDContainerView 

2). CDContainerView sottoclasse CDContainerWidget:

class CDContainerView(CDContainerWidget): 

class MainFrame: 

    def __init__: 

    CDContainerView 

3). CDContainerWidget sottoclasse CDContainerView:

class CDContainerWidget(CDContainerView): 

class MainFrame: 
    def __init__: 
    CDContainerWidget 

4). invece di usare CDContainerWidget e CDContainerView, utilizzare solo una singola classe CDContainerBig che sottoclasse la classe astratta View e wxPanel

class CDContainerBig(View, wxPanel) 

La mia domanda è che cosa è la soluzione giusta? Ho letto la pagina wiki del pattern MVC, ma non ne capisco veramente la descrizione e non so come, e mi chiedo anche se è appropriato applicarla al mio problema.

bene, ho messo alcuni commenti aggiuntivi. originariamente, quando inizio a progettare per programmare, non ho pensato molto e ho solo scelto, 2) approccio. ma ora, penso 3) è buono. poiché è ragionevole inserire widget nel widget (CDContainerWidget in MainFrame). ma non ne sono veramente sicuro. Inoltre sembra con schema osservatore, le tre classi sono contorte e awkard. E a volte, mi sembra che questi 4 siano uguali, solo chi include chi o chi invia messaggi a chi. bene, penso che ho davvero bisogno di chiarimenti su questo punto.

Inoltre, sono favorevole a 3) a causa di un punto pratico.Il CDContainerWidget contiene in realtà diversi componenti subwidget (pulsante, casella di input, ecc.) E se si modifica qualcosa come impostare nuovi valori tramite un widget di sottocomponente, quindi per 1), è necessario che CDContainerWidget sia a conoscenza di CDContainerView, per consentire a CDContainerView di notificare altre visualizzazioni. per 2) ancora peggio, CDContainerWidget deve essere a conoscenza del suo CDContainerView childen. per 3) CDContainerWidget è CDContainerView, quindi abbastanza ragionevole. per 4) bene, facile ma senza separazione logica. questo è il mio pensiero, non so se è corretto.

Grazie !!

Answer 1

Ciò che potrebbe rendere questo un po 'più facile per voi perdere l'accoppiamento tra le classi implementerebbe uno schema di slot del segnale con qualcosa come Spiff Signal o uno degli altri moduli segnale/slot disponibili.

Dissociando la logica di comunicazione è possibile liberarsi completamente dalla necessità di moduli per parlare direttamente, ma piuttosto utilizzare il passaggio dei messaggi con i callback.

Answer 2

L'opzione 1 sembra più appropriata. In generale, si dovrebbe evitare l'ereditarietà a meno che il modello lo richieda, o ci sono altri motivi validi per usarlo. L'uso eccessivo dell'eredità renderà il tuo codice molto più strettamente integrato di quanto non debba essere.