CODEWITHSUNDEEP
user-interfacemodel-view-controllerdesign-patternsmvvmmvp
choxsword
choxsword

Reputation: 3359

Can Model use interfaces to communicate with View in MVC?

In classic MVC pattern, the model communicate with view through notify events.

But it seems that defining some basic interfaces for views, and making the model communicate with view through interfaces, would also be feasible and could still decouple the model and concrete view.

However, I've never heard about any MV* pattern using interface between view and model. Is there any obstacles for communicating in such way?

Upvotes: 2

Views: 766

Answers (1)

Christophe
Christophe

Reputation: 73446

How does MVC work?

First of all, MVC is an architectural pattern: It describes the main parts of a system, their responsibilities and how they interact. It does not impose any specific implementation.

The original MVC for example was designed in 1979 by OOP pioneers in a Smalltalk context. In this dynamically typed language, there are no interfaces: objects communicate with other objects sending them messages, without even being sure that the receiver can deal with the messages.

Views have the responsibility to display some content of a model. But it would be very inefficient for the view to query continuously the model to see what changed. So, MVC uses a push model: the view can query the model to display some content, but the model broadcast to the view that changes happened and that it's worth to consider refreshing the display.

Different views may show different content. Let's suppose that the model is the digital twin of a car. One view could just show the speed, as it would appear on a dashboard. The other view could ignore the speed, and just draw the car in 3D. To avoid that models has to know all the inner details of every possible kind of views, the broadcast is kept minimalistic.

Observers and notification

The notify() message is this exaclty this kind of minimalistic communication.

GoF popularized design patterns and started their book with decomposing the different features of MVC into different independent patterns. The subscribe/notify relationship between view and model was mapped to the observer pattern. Since their design were very suitable for strongly typed languages, the notify()/update() became very popular.

The pattern works as follows:

  • Very different observers ("views") of a model ("subject") all use the same interface that defines the methods that are common to all the views. In GoF, they use an abstract Observer class. In many modern languages, however, the tendency is to replace the abstract class with an interface.
  • The observers (views) subscribe/register to a subject (model), which keep track of all the registered objects.
  • Whenever some change happen in the model, the model triggers a broadcast informing all its observers that something has changed (notify()/update()), without telling precisely what.

Alternatives?

Interfaces are like empty shells that hide what might be within. They are by themselves not sufficient to define a comprehensive solution; they are just a part of the puzzle:

  • If you use a language with explicit interfaces such as Java (interface) or Swift (protocol), once the interface defined, you need to defined classes that implement them.
  • If you use a language with implicit interfaces, such as C++ or JavaScript, you already have the implementation, but you still need to find a way for the model to inform all its views.

In both cases, having the interface allows the model and the view to understand each-other. But for an MVC broadcast to happen, the model needs to know whom to inform of changes, and the views have to know whom to listen to.

So you will end-up with something similar to the observer.
Now the traditional observer pattern is not the only possible solution. You could think of:

  • a more specific interface: the observing view would not have a single method to be informed that something has changed, but specific methods that also tell what has changed (e.g. onSpeed(), onShape()). Views can react more efficiently. THe only problem is that views are forced to implement methods that they are absoluetly not interested in (i.e. no interface segregation)
  • a more intelligent notification: the model would give some hint about what was modified in the model. It could for example be a list of changed model objects that would be provided via notify()
  • a more granular subscription: instead of subscribing to a full model, the views could subscribe to known model components. But this would me much more complex.
  • a pub/sub event based design: the model would publish specific change events (e.g. "change speed", "change shape") in a queue (perhaps even with additional informations. The views could subscribe to the queue, ignore the change events that are not relevant, and process the remaining ones.

Upvotes: 1

Related Questions