Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

CodeBlock of GUI

<< < (2/3) > >>

TDragon:
Nice essay.

The M-V-C design pattern, like any design pattern, is a tool to be used if helpful and discarded if not. Consider the cost of using it on Code::Blocks. I estimate that 70% of C::B classes incorporate both wxWidgets GUI elements and data structures. To apply M-V-C, each of these classes would need to be split apart into at least two separate classes: one for the data structure, one for the GUI. We now have 70% more classes, and (at a guess) 20-30% more LoC to be compiled. Then we add the runtime expenses to the tally -- 10% of these new classes might give the compiler a clue to better optimizations, but the other 90% will at best come at no additional cost, and at worst actually come at a higher cost, through increased stack usage (minor) and increased dynamic allocations (major). Is there more? You bet. C::B's developers now have to keep track of 2-3 times as many relevant classes for each concept.

In combining the data structure with the single GUI element that is responsible for it, C::B usually benefits.

wwolf:
Do not take me wrong, but I think that what you have said is only guesswork.  Unless you measure, you don't know.

Also pls. take it into account that understanding 20 complex classes is more of a burden than understanding (even) 40 simple ones.  Not to mention that if the GUIs choice of OO-for-everything does not infect the Model code, you may actually end up using design techniques (such as templates) that reduce the number of classes. :)

My 20+ years of experience in the field tells me the above.  I know that not only design complications come from mixing more responsibilities into a class, but it (unfortunately very) effectively raises the bar for new designers to join in.  Suppose I could contribute in the Model part.  Today I am not able to do that, because the Model part is mixed with the GUI, where I have no confidence.  Also, comes in testability.  Mixing GUI into Model makes unit testing close to impossible.

I feel that I am not going to convince you, but just let's make one more point and then we can agree to disagree. :)  You have mentioned that 10% of the code may get faster while 90% slower.  Even if that is the case what matters is: which one?  90% of the execution of a program is spent in 10% of its code.  (90-10 rule, sometimes 20-80 rule.)  In a GUI environment that 10% of the code (that provides your speed) is in the Model part - not in the GUI.  Of course, I am not talking about 3D and rendering applications, which are 99% GUI. :)

stefanos_:
wwolf, can you please explain to me what do you mean by saying Model?

I have searched for this through Google and I haven't found anything that explains its meaning. Only a project named C++ Model Developer (CMD) http://stinet.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=ADA433836 has something about Model if that's the case.

wwolf:
That is one part of the MVC pattern.  View, Model, Controller.  In a quick an dirty description: Model is the data we want to show.  View is the part that does the showing, it is the GUI.  Of course, it does not only show, you may also edit (change the Model) using it.  The Controller is the element that makes the connection between (possibly many different) Views and their Models.  See the WikiPedia article about it: http://en.wikipedia.org/wiki/Model-view-controller

JGM:

--- Quote from: wwolf on August 25, 2007, 02:33:57 am ---See the WikiPedia article about it: http://en.wikipedia.org/wiki/Model-view-controller

--- End quote ---

Interesting, I will try to implement that kind of design on a program that I'm working on.

Navigation

[0] Message Index

[#] Next page

[*] Previous page