Design Patterns

1
Design Patterns

• Part two

2
Structural Patterns

• Concerned with how classes and objects are
  composed to form larger structures
• Structural class patterns use inheritance to
  compose interfaces or implementations.
• Structural object patterns describe ways to
  compose objects creating new functionality.

3
The Façade Pattern

• Provides a single interface into a subsystem.
• Used to separate or simplify the subsystem in the
  program.
• Used in UIs to separate a GUI from the underlying
  business logic

4
Façade Use When

• A simple interface into a complex subsystem is
  required.
• A subsystems details are not or should not be
  required knowledge for other components.
• Subsystems should be compartmentalized,
  decoupling the system from the black box. This
  allows for easier changes within the isolated
  subsystem, as long as the API for the system
  isnt altered
• Layering of subsystems is required

5
Façade - Benefits

• Shields clients from subsystem components.
• Promotes a weak coupling between subsystems,
  allows subsystem change without affecting
  clients.
• This pattern helps simplify complex or circular
  subsystems for outside users.
• Possible compile time reduction, as not all
  components may need to be recompiled.

6
Façade Example

• You want to make a platform-independent front end
  to a database
• Database runs on any target system
• Front end is (almost always) platform dependent
• Create a façade API to program the GUI to
• Moving to a new platform means reimplementing the
  GUI, but not the API or the back end code

7
Implementation Points

• Subsystem coupling can be reduced if the façade
  is an abstract class, and concrete classes
  implement the subsystem itself. This prevents
  clients from knowing details about which
  subsystem is used.
• Also, consider the use of interfaces in Java
• Judicious use of public and private classes and
  methods can help provide subsystem independence
  and encapsulation. (Consider the use of package
  security in Java)

8
The Proxy Pattern

• The Proxy provides a surrogate or placeholder,
  often to control access to it.
• There are four general categories of proxy.
• Used when there needs to be a more versatile
  reference to an object, or when it is not
  practical or desired to reference the original.
• Example large image that eats a lot of memory

9
Proxy Categories

• Remote Proxy Local representative for objects in
  different spaces.
• Virtual Proxy Creates expensive objects on
  demand.
• Protection Proxy Controls access, can be similar
  to a Façade.
• Smart Reference Various value adds, such as
  object loading, tracking instances, object or
  database locking.

10
Proxy Benefits

• Remote proxy can hide resident details.
• Virtual proxy creates expensive objects on
  demand, rather than all at startup.
• Example dialog boxes
• Protection and Smart Proxies can allow
  housekeeping an other tasks to be encapsulated.

11
Proxy Example

• Your program must be ready to display a large
  number of graphical images, but not all of them
  can be seen by the user at one time. A virtual
  proxy could be used to load the image only when
  needed by the user, so that the time to open the
  application is not slowed by image loading.

12
Behavioral Patterns

• Concerned with algorithms and the assignment of
  object responsibilities.
• Describe not just the patterns of objects but how
  they communicate.
• Behavioral class patterns use inheritance to
  distribute behavior to classes.
• Behavioral object patterns use object composition
  rather than inheritance. Often, this describe
  how a group of objects cooperate to perform a
  task and what objects need to know about which
  others.

13
The Command Pattern

• Encapsulates a request as an object.

14
Command Use When

• Useful to issue requests without knowing details
  about the operation or recipient.
• Objects can be parameterized by an action to
  perform.
• A framework executes a generic command, and the
  command object is extended to do the application
  specific method.

15
Command Benefits

• Command allows the calling object to be separate
  from the one that can perform it.
• Commands can be assembled together to form more
  complex commands. An example of this is the
  MacroCommand, which will not be discussed here.
• Adding new commands is easy, and existing classes
  wont have to change.

16
Command - Benefits

• Support can be added for operations undo and
  redo.
• Security can be enhanced by logging user actions
  through centralized Command objects.

17
Command Example

• The application you are working on must support a
  log of all user activity for security purposes.
  To do this, you use a central command object
  which will be able to determine what actions a
  user has taken and can then log them or do
  whatever actions are required.

18
Implementation Points

• Consider command object intelligence. It can be
  a simple object between a requestor and a
  recipient.
• For undo/redo, consider what parameters and
  information must be stored.
• If using C, templates may be used if commands
  arent undoable and dont require arguments.
• Try to limit the number of undoable commands it
  bug the user.

19
The Observer Pattern

• Defines a one-to-many dependency or communication
  flow between objects. When one object is
  updated, all dependents are notified
  automatically.
• This is one of the most important patterns in GUI
  development, as it abstracts the notion of the
  callback
• Some event occurs (user clicks a button) and
  something else is notified (function is called)

20
Observer Use When

• An abstraction has two aspects, one dependent on
  the other. Encapsulating these pieces in
  separate objects lets you vary and reuse them
  independently.
• A change to one object requires changing others
  the number to be changed may be dynamic or
  unknown.
• An object should be able to notify others without
  making assumptions about what the objects are.

21
Observer - Benefits

• Abstracts the coupling between the notifying
  object and observers. All the notifying object
  knows is it has a group of observing objects to
  send a message to.
• Good object oriented programming, where a message
  is sent, but each objects action is independent.
• Support for broadcast communication. Objects can
  register or deregister as needed, and the
  notifying object only has to know which objects
  currently need notification.

22
Observer - Drawbacks

• Care must be taken to ensure that messages sent
  to observers dont themselves trigger more
  messages to be sent, causing an operation to
  become an infinite loop.

23
Observer Example 1

• A user presses the File-gtLoad menu item. An
  application object called FileLoader is notified
  (or observes the press) and goes about loading a
  file.

24
Observer Example 2

• A company that makes medical monitors needs a way
  to display data to nurses and physicians so they
  can ascertain a patients condition quickly and
  completely. By using an observer, when new data
  is added to the database, notifications can be
  sent to multiple observers, say the monitor at
  the patients bedside, the nurses station and
  the physician who happens to be monitoring the
  patient live in their office at the same time.

25
Implementation Points

• How to map notifying objects to observers. Often
  down with a simple connection function call
• Observers may have to know what object is sending
  the notification, especially if it registers as a
  listener to more than one notifying object.
• Similarly, it may also be more efficient to send
  data each observer rather than sending an update
  message and having each observer retrieve it.

26

• A consideration of who triggers the update is
  very important. Objects can be responsible for
  sending the notification, but if the code is
  forgotten at the client, or a bug prevents it
  from being sent, then the update is never
  broadcast.

• Deleting an observer should not result in a
  dangling pointer in the notifying object. A way
  to deal with this could be to make each item an
  observer of the other so references can be
  removed when it is deleted.

27

• Push and Pull Models of Implementation.
• One extreme is the push, which pushes data to
  each observer, without knowing if it needs it or
  not. This may broadcast more information to
  observers than they need to know, and make code
  reuse more difficult.
• Most GUI toolkits do this
• The pull model sends a relatively simple message,
  which may require each observer to then request
  potentially identical information. This may hide
  communication and implementation better, but may
  result in a more inefficient model.

28
References

• Design Patterns, Gamma, Helm, Johnson and
  Vlissides, Addison-Wesley, 1995