Week 4. Publisher – Subscriber relationships. OOP and the User Interface. MVC pattern principles.

Publisher – Subscriber Relationships

In object-oriented programming we want to implement the logic of data processing through objects, that as we know consist of attributes and methods. So, how could we implement the logic on the base of those two things? Apparently methods are to implement some algorithms, but what is the thing to initiate algorithms? The answer to this question is hidden in the following statement: Object Oriented Programming is known as “Event Driven Programming”.

This definition means the approach when the decision of doing or not doing some activity/ operation must be done on the base of the events taking place at each particular moment.

A given object has its life cycle that starts from object instantiating and stops when the object is destroyed. Between start and stop, object is going through the chain of states. According to the UML, a state is “a condition or situation during the life of an object during which it satisfies some conditions, performs some activity, or waits for some event”. Object State is physically implemented by the set of values of the object attributes pertinent to some particular moment of time. For example the object Employee may be in the states of approbatory, full time, retired, etc. Being implemented into the software the object states reveal themselves through the values of attributes.

Thus we see that the object transformation is taking place through the state changes. What is the trigger of changes? That is Event.

Events may happen as end user’s action like selection of some particular activity. For example selecting the activity from GUI. Events trigger some algorithm that results in changing the object (system) states. New state in its turn can be the trigger for another operation and other data changes happen. Events and State Changes appear to be the main triggers of operations. The object that is currently in control has to recognize the events or state changes and then as the reaction to those changes, or events, to implement some operations or to move the control to another object.

From the above discussion we see the importance to intercept events or to recognize state changes. The technique of working with events and states includes the following:

-Events Listeners – special methods that are included into the object to intercept end user’s events, such as Check Box marking or click a button

-State Change Notification – special method that is to notify another object about the state changed

-Register for state change notification – special method that is to register a given object interests in state change notification

If objects are in need to transit information about events or state changes to the other objects, there is a Publisher – Subscriber relationship between the objects.

The relationship patterns are illustrated below:

Publisher/ Subscriber relationship – Event Service

Publisher Subscriber

The pattern allows an object (Event interceptor) to register its interest in EventGenerator. Whenever the EventGenerator generates an event, it will push the event to Event interceptor.

The Observer pattern

Publisher Subscriber

The Observer pattern allows an object (the observer) to register its interest in another object (the observable). Whenever the observable wants to notify its observers of a change, it will call an update() method on each observer

Later we’ll learn more about Publisher – Subscriber relationship and Observer pattern implementation.

OOP and GUI design. MVC principals

The process of designing GUI is fundamentally no different than the process of designing and programming any other aspect of your system. We must apply the same OO principles that we would apply to any other part of the system. The system often requires many different user interfaces. Also user interfaces can become a moving target. Systems mature over time as new features are added or changes are done to improve existing activities. In response, the developers need constantly update the user interface. System maintenance becomes expensive and expenses have the tendency to growing unless some special design solution is implemented. This solution can be described as “Decoupling user’s interface from the rest parts of the system”. Its practical implementation is known as Model-View-Controller (MVC) pattern.

In this pattern:

Model – entity objects, represents the system

View – represents user’s interface, displays the model

Controller – intercepts User’s event and makes the decision about the method to call.

The Model

The model is responsible for providing

  • Access to the system’s core functionality
  • Access to the system’s state information
  • A state change notification system

MVC pattern is built on the base of Publisher – Subscriber relationships. It comes out through:

The model is the layer that manages the core behaviour and state of the system. It responds to queries about its state from the view and controller.

The controller is the layer that interprets user input. In response to the user input, the controller may command the model or to the view to change or perform some actions.

In either case, the model is completely unaware that a view or controller is making a method call. The only connection that a model maintains to them is through the state change notification system.

If a view or controller is interested in state change notification, it will register itself with the model. When the model changes its state, it will go through the list of registered objects (listeners or observers) and inform each object of the state change.

The View

The view is responsible for

  • Displaying the model to the user
  • Registering with the model for state change notification
  • Retrieving state information from the model

The Controller

The controller is responsible for

  • Intercepting user events from the view
  • Interpreting the event and calling the proper methods on the model or the view
  • Registering with the model for state change notification, if interested

MVC pattern first of all links three principal kinds of behaviour: Consumer (View) – Manager (Controller) – Supplier (Model). In the real system the pattern may be expended by the following:

  • View does not necessarily relate to the screen. It may be other output data format
  • Model may provide state change notification not only to view or controller, but also to other objects inside the model
  • Control functions may be extended beyond a Controller attached to a view. Additional level of controls may appear, such as Front Controller for example. It also can use Publisher – Subscriber relationships with Model, View or other Controllers.

Important rule is to design the object with its responsibility in mind. View and Controller must not implement business logic. Controller and Model must not display. Model must not intercept or interpret user events.