Scribd
Upload
38 views

Last Time: Boundary Object Responsibilities

The document discusses how a boundary object called StaffUI can be informed when application data managed by a control object called BookingSystem changes. It considers two approaches: polling and bidirectional coupling. The best solution is to use the Observer design pattern, where StaffUI implements a BookingObserver interface and registers with BookingSystem as an observer. When data changes, BookingSystem notifies the observer via its update() method. A simple Java implementation is provided as an example.

Uploaded by

studentscorners
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
38 views

Last Time: Boundary Object Responsibilities

The document discusses how a boundary object called StaffUI can be informed when application data managed by a control object called BookingSystem changes. It considers two approaches: polling and bidirectional coupling. The best solution is to use the Observer design pattern, where StaffUI implements a BookingObserver interface and registers with BookingSystem as an observer. When data changes, BookingSystem notifies the observer via its update() method. A simple Java implementation is provided as an example.

Uploaded by

studentscorners
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 16

Last time

Boundary object responsibilities

√ 1. Handling user messages


√ 2. Handling events i.e. mouse
selections
3. Presenting the application data to
the user
Presenting the application data to the user

This occurs when the application data changes

e.g. the currently selected booking has changed, the current


bookings collection has changed, a booking has been transferred
to a different table etc the staffID object needs to update the
display to reflect this change.

how does it know when to do this?

or...

how is it informed that the application data has changed?


Presenting the application data to the user

Current sate of the design model …

<<boundary>> <<control>>
StaffUI BookingSystem

The rest of the


model
Presenting the application data to the user
how is the boundary class informed that the application data has
changed?

Possibilities

•Polling i.e StaffUI could ask, on a regular basis (called the


polling rate), the BookingSystem whether the data has changed.
Potentially this could be expensive in terms of processing time.
•The BookingSystem could tell StaffUI when the data has changed.
This requires the association to be bi-directional, thus increasing the
coupling between the two classes. It also violates the constraints of
the three layered architecture in the sense that the application layer
should be independent of the presentation layer.
Presenting the application data to the user
how is the boundary class informed that the application data has
changed?

StaffUI

violates
<<depends>>

BookingSystem
Presenting the application data to the user
how is the boundary class informed that the application data has
changed?

Fortunately this problem has been solved


before!

A suitable design pattern could be applied


Presenting the application data to the user

an aside …

Design patterns

Design patterns are generic designs for commonly occurring


design problems.

They are available in the literature and are covered in far more detail in
CSE3OAD [Object-Oriented Application Development]

e.g. See “Applying UML and Patterns --- An Introduction to Object-Oriented


Analysis and Design and the Unified Process” 2nd edition Craig Larman, Prentice-
Hall International, Inc (2002)

The Observer design pattern could be applicable here


Presenting the application data to the user
The Observer (Publish-Subscribe) design pattern can be described as
follows (from Larman p. 373)
Context/Problem

Different kinds of subscriber objects are interested in the state


changes or events of a publisher object, and want to react in their
own unique way when the publisher generates an event. We wish to
maintain low coupling between the subscribers and publishers.

In our case there is one subscriber object (StaffUI) and one publisher
object (BookingSystem). The state changes are changes in the
application data e.g. currently selected booking, the set of current
booking etc.
Presenting the application data to the user
The Observer (Publish-Subscribe) design pattern can be described as
follows (from Larman p. 373)

Solution

Define a listener (or observer) interface. Subscribers then implement this


interface. The publisher can register subscribers who are interested in
an event, and notify them when an event occurs.

In our case a BookingObserver interface will be defined which


will be implemented by StaffUI
Presenting the application data to the user
Another aside … Interface Classes

"An Interface is a specialised class declaration that can declare constants and
method declarations, but not method implementations". (Java API)

An interface is a description of behaviour. Classes that implement the interface


must provide the services (methods) described by the interface.

In UML
<<implements>>

SampleClass InterfaceClass

… a realisation
Presenting the application data to the user
Another aside … Interface Classes

"An Interface is a specialised class declaration that can declare constants and
method declarations, but not method implementations". (Java API)

An interface is a description of behaviour. Classes that implement the interface


must provide the services (methods) described by the interface.

In Java

public class SampleClass implements InterfaceClass


{
.......
.......
/* method implementations for the declarations in
InterfaceClass are defined here*/
}
Presenting the application data to the user
So how does it work in the Restaurant system ?

The BookingSystem has a list of


BookingObservers. It also has
the functionality to deal with this
list (i.e can add to it, can notify StaffUI
an observer when something
occurs)

<<implements>>

BookingSystem <<interface>>
BookingObserver

*
Presenting the application data to the user
So how does it work in the Restaurant system ?

When a StaffIU object is


instantiated it would instantiate
a BookingSystem object and
notify it (through addObserver())
that it wishes to be added to the StaffUI
list of BookingObservers. update()

This is
implemented
When the system data <<implements>> by the StaffUI
changes (e.g the current object.
bookings have changed), the
BookingSystem notifies the BookingSystem <<interface>>
BookingObserver
appropriate BookingObserver addObserver()
notfiyObserver() update()
through notifyObserver(), displayBookings() *

which involves the sending of


the update() message.
Presenting the application data to the user
Now for a simple demonstration (in Java) The BookingSystem class

The StaffUI class


import java.util.*;
import java.util.*; public class BookingSystem
public class StaffUI implements BookingObserver
{
{ public boolean updateRequired;

public BookingSystem TheBookingSystem; BookingObserver observers[] = new BookingObserver[1]; //


only want one of them

public StaffUI() // the constructor public BookingSystem() // the constructor


{ {
System.out.println(" StaffInterface object created"); System.out.println(" TheBookingSystem object created");
TheBookingSystem = new BookingSystem(); updateRequired = true;
TheBookingSystem.registerAsObserver(this);
int i; }
for(i=0;i<6;i++)
{TheBookingSystem.change();} public void registerAsObserver(StaffUI ui)
{
} observers[0] = ui;
}

public void change()


// overridding update() in the interface BookingObserver {
public void update() if(updateRequired)
{ { observers[0].update();
System.out.println(" Update method implemented by StaffUI updateRequired = false;}
called"); else
} {updateRequired = true;}
}
}

}
Presenting the application data to the user
Now for a simple demonstration (in Java)
… and finally the interface class, BookingObserver
Here is the main …

import java.util.*;
import javax.swing.*;
public interface BookingObserver
import java.awt.*;
public class InterfacePractice1
{
{
public static void main(String[] args)
{
public void update();
EventQueue.invokeLater(new Runnable()
{
public void run()
}
{
StaffUI StaffInterface = new StaffUI();

}
} ); // end of invoke trying to ensure that the events and apps are in
the same thread

} // main

} // class
Next time …

More on the design model

You might also like