MVC/MVP Design Pattern Questions

[Hubert Mayr]

Hello,

I played with the demo application provided by wxPython

and came across the MVC example. I see the advantage when

having such a simple logic but I'm asking myself how such

a pattern could be adapted to an, let's say, editor application.

I understand that the View part is the frame with its

menu, toolbar and statusbar.

But is a styled text control (stc) the controller in such a scenario?

Whenever one cuts text within the stc, the toolbar and menu 

needs to reflect this action by enabling some buttons and disabling others.

Assume the user interacts with the editor, e.g. by pressing control+a,

the cut symbol (scissor) needs to be enabled. At this point,

only the stc knows that text has been selected so the stc

would set the property in the model that scissor is enabled and

model would send the event, right?

Or is it needed to have another instance between the stc and model

to fulfill the MVC design pattern?

What would be the benefit?

If one decides to replace the control with another one,

you still have to code the communication to the controller, don't you?

So, you could also code the communication to the model, couldn't you?

Do I miss something?

Are there any good examples available which could be used to study MVC and other patterns?

Thank you

Hubert

[Tim Roberts]

Hubert Mayr wrote:
>
> I played with the demo application provided by wxPython
> and came across the MVC example. I see the advantage when
> having such a simple logic but I'm asking myself how such
> a pattern could be adapted to an, let's say, editor application.
>
> I understand that the View part is the frame with its
> menu, toolbar and statusbar.
>
> But is a styled text control (stc) the controller in such a scenario?

It depends. If you are allowing the STC to hold the master version of
your document, then it is essentially acting as model, view, AND controller.

The model holds the data. For an editor, the data is the characters in
the document. If you have your own string buffer containing the
document, then that would be the model, but if the STC holds the only
copy, then it is acting as the mode. It's obviously acting as view,
since it is presenting the UI. And because it is updating the UI based
on changes in the document text, it is also acting as a controller.

MVC is a very useful paradigm, but remember that it's only a guideline.
There are many applications where the lines between them are extremely
fuzzy, especially for small applications.

> Whenever one cuts text within the stc, the toolbar and menu
> needs to reflect this action by enabling some buttons and disabling
> others.

In that case, you have a controller, and STC has a controller. STC's
controller is notifying yours so that you may signal changes in your view.

> Or is it needed to have another instance between the stc and model
> to fulfill the MVC design pattern?

Only if it make encapsulation clearer, or enhances your ability to
change to a different view. If it makes things muddier, then don't
worry about religious purity to the model. It's supposed to make things
easier.

> If one decides to replace the control with another one,
> you still have to code the communication to the controller, don't you?
> So, you could also code the communication to the model, couldn't you?

Sure. Often times, the model doesn't actually have any code at all --
it's just a collection of data structures. The controller interprets
the data structures to tell the view how to update itself.

> Are there any good examples available which could be used to study MVC
> and other patterns?

There are lots of good examples on the web. Microsoft also espouses an
MVVM pattern (model - view - viewmodel), which is somewhat similar.

Do remember, however, that these patterns are intended only as
guidelines. There is good justification for separating the presentation
of a piece of data from the representation of that piece of data, and
that's primarily what MVC is about. If you're doing a very large
application, adherence to the pattern makes it much easier to implement
remote control and COM control, for example (since that can hook
straight into the controller without going through the view), but in
many small applications, it's just not worth the overhead.

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Hubert Mayr]

Thank you very much for the answer.

As a novice programmer I was under the impression

that design patterns are more like APIs, I mean, something

which forces you to have exactly those components a pattern describes

to get the result the pattern promises.

But if there are "guidelines" only, I take it as good advises which

can be ignored if it makes it more complicated then expected.

Thank you

Hubert

[James Scholes]

Hubert Mayr wrote:
> As a novice programmer I was under the impression
> that design patterns are more like APIs, I mean, something
> which forces you to have exactly those components a pattern describes
> to get the result the pattern promises.

Have a look at this excellent post from Matthew Jones. He's a web
developer, but what he says applies just as well to desktop or any other
type of development.

https://www.exceptionnotfound.net/software-design-patterns-are-not-goals-they-are-tools/

There are many posts, usually tutorials, out there which will tell you
to create a class called Controller, one called Model, and one called
View. But there are just as many, if not more, examples of creating
better, domain-specific abstractions. For example, the media player
Quod Libet, which is written in Python, uses an abstraction called
"librarian" for music library management. You read the name of the
concept, and you instantly have a pretty good idea what that part of the
system is responsible for. Whether the librarian is a controller,
mediator, presenter, adapter, coordinator or whatever other buzzword you
want to use doesn't matter.
--
James Scholes
http://twitter.com/JamesScholes

[Hubert Mayr]

Thank you very much for your insight, especially for mentioning the quod libet project.

To see how experts solving the problems should help me understanding the concepts better.

As Tim Roberts already said, I guess design patterns should be treated as tools and not as strict orders.

They can be helpful to solve problems but they shouldn't be used as the only possible way to solve it.

I agree to the statements from Matthew Jones in regards that design patterns could be cumbersome

when starting developing applications, especially when being a novice programmer because

a) you aren't experienced enough to understand your own program logic completely to see when you can gain advantage of a pattern and

b) if you are aware of design pattern you try to use it as much as possible and then you may make things worse (because of a)  :-)

Luckily python is such a great programming language that gives you always the feeling you know what to do :-D

Thank you

Hubert