views:

179

answers:

2

Hello, guys, I am programming a GUI for an application, a cd container to insert cd, and currently I am not very clear and I think I need some help to clarify my understanding about object oriented design.

so, first, I use observer pattern to build abstract Model and View classes and also the concrete models(cd container) and concrete views(cd container view). Then I start to use the wxwidget framework to design and graphical appearance or layout (CDContainerWidget, from wxPanel) for the cd container and other gui controls MainFrame(from wxFrame), etc..

so now I have three classes: CDContainerModel (cd container), CDContainerView (the class for observer pattern), and CDContainerWidget (the gui controls). then I become not that clear about what I should do with the CDContainerView and CDContainerWidget?

I think CDContainerWidget and CDContainerView both need CDContainerModel. I think about four approaches, but do not know which one is approriate:

1). associate CDContainerWidget into CDContainerView as a member variable, then put the CDContainerView into the Main Frame as a member variable.

class CDContainerView:
  def __init__:
     self.gui=CDContainerWidget

class MainFrame:
  def __init__:
     CDContainerView

2). CDContainerView subclass CDContainerWidget:

class CDContainerView(CDContainerWidget):

class MainFrame:

   def __init__:

     CDContainerView

3). CDContainerWidget subclass CDContainerView:

class CDContainerWidget(CDContainerView):

class MainFrame:
  def __init__:
     CDContainerWidget

4). instead of using CDContainerWidget and CDContainerView, use only a single class CDContainerBig which subclass the abstract class View and wxPanel

class CDContainerBig(View, wxPanel)

My question is what is the right solution? I have read the wiki page of MVC pattern, but I do not really understand its descrption and do not know how and also wonder if it is approriate to apply it to my problem.

well, I put some additional comments. originally, when i start to design to program, I did not think much and just choose, 2) approach. but now, I think 3) is good. since it is reasonable to put widget in widget(CDContainerWidget into MainFrame). but I am not really sure. Also it seems with observer pattern, the three classes are twisted and awkard. And sometimes, it appears to me that these 4 maybe are the same, just who includes who, or who sends messages to who. well, I think I really need clarification on this point.

Also, I am in favour of 3) because of a practical point.The CDContainerWidget actually contains several subwidget components (button, input box, etc.) and if we change something like set new values via a subcomponent widget, then for 1), we need CDContainerWidget to be aware of CDContainerView, to let CDContainerView to notify other views. for 2) even worse, CDContainerWidget has to be aware of its childen CDContainerView. for 3) CDContainerWidget itself is CDContainerView, so quite reasonable. for 4) well, easy but no logic separation. this is my own thought, do not know if it is correct.

Thanks!!

+1  A: 

Option 1 seems most appropriate. In general, you should avoid inheritance unless the pattern calls for it, or there's some other compelling reason to use it. Overuse of inheritance will make your code a lot more tightly integrated than it has to be.

p-static
Hi, p-static, thank you for your answer. Could you please be more detailed why 1) most appropriate. What you said is just "delegation is better than inheritance", nothing else, and this is a general design rule, but not specific to my question. Honestly, I am not that convinced.
pepero
Well, in my experience you don't want to have a dependency on GUI code in any other part of your program that doesn't require it (like the View class) - I've done this on a few projects, and always regretted it not long after. So that eliminates 2) and 4). 3) actually does seem like a reasonable solution; my only problem with it is my bias against inheritance. :)
p-static
@p-static : (+1 to everything you said). "bias against inheritance" is always better than an irrational desire to put inheritance everywhere.
Raveline
+1  A: 

What might make this a bit easier for you to shed the coupling between classes would be implementing a signal slot pattern with something like Spiff Signal, or one of the other signal/slot modules available.

By decoupling the communication logic you can free yourself entirely of the need for modules to talk directly but rather use message passing with callbacks.

synthesizerpatel