Christopher B. Browne's Home Page

8. Object Oriented and Event Driven Programming

In modern GUI/interactive environments, programs must be written in substantially different fashion to the old "run-the-program" fashion.

GUIed programs typically are created using event-driven systems where all sorts of "events" can result in (processing being done). This might include:

In a WIMP (Windowed Interface with Mouse Pointer) system, the user can, with a flick of the wrist, change the "system state" in any of these ways in a fashion that enforces allowing "random access" to almost any part of the system at all times.

One of the fundamental ways in which this tends to be expressed is via object oriented programming. The idea of OOP is to encapsulate data and processing methods together, which is useful here in that the system can be informed that an event has occurred, and then manage this by asking a method to act on the relevant piece of data. The "master thread" does not necessarily need to know anything about the underlying data; responsibility is encapsulated in the methods.

The early applications of object oriented programming included event-driven systems such as simulations and graphical user interfaces; those represent, to this day, the areas in which OOP techniques are most effective.

More recently, object oriented techniques have been increasingly applied to transaction processing systems using object oriented database systems. In networked applications, it is sensible to break down processes into "business transactions" that may be represented using objects. Transaction Processing Monitors provide ways of managing database updates using such objects; one of the common ways of describing these kinds of objects is CORBA.

8.1. Object Oriented Patterns

I am somewhat dubious of some of the the beliefs in the "object oriented" world. There's a little too much dogmatism, and the bold assumption that using OOP changes "everything" for the better. Even when the designs can be equally well described using a non-object oriented "notation."

There's actually a literature about the opposite: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis

However, the notion of Patterns does appear to have merit. I would suggest the thought that not all of these patterns are inherently object oriented; they may simply be "sensible design patterns." In any case, there are some ideas that can be usefully considered when doing system design.

8.1.1. Creational Patterns

Abstract Factory

An abstract factory provides an interface for creating families of related objects without specifying concrete classes


A builder separates the construction of a complex object from its representation so that the same construction process can create different representations.

Factory Method

This defines an interface for creating objects, allowing subclasses to decide which classes to instantiate


Objects are specified using a prototypical instance


This pattern ensures that a class has only one instance, providing a global point of access to the instance

8.1.2. Structural Patterns


This patterns converts the interface of one class into an interface expected by another class


This decouples an abstraction from its implementation so the two can vary independently


Objects are composed into tree structures, and clients are permitted to treat both individual objects and compositions in a uniform fashion


Attaches additional responsibilities to an object dynamically


Defines an additional interface to a subsystem that is easier to use than the "real" interface


Uses sharing of "servers" to support large numbers of clients efficiently


Provides a surrogate to provide access to an object

8.1.3. Behavioral Patterns

Chain of Responsibility

Avoids coupling a request sender directly to the receiver by giving multiple objects the opportunity to handle the request


Requests are encapsulated as objects to allow clients to be parametrized with different requests


Defines a language and its interpreter


Allows access to elements of an aggregate object sequentially without exposing the underlying object structure


An object that controls how a set of objects interact


Captures and externalizes an object's internal state so it can later be restored


Defines a many-to-one relationship so that when one object changes state, others are notified and updated automatically


Allows an object to change its behavior when its internal state changes


Defines a set of interchangeably usable algorithms

Template Method

Defines an algorithm skeleton in one operation, and defers some steps to subclasses


Represents an operation to be performed on the elements of the structure without changing the classes on which it operates.

8.2. CLOS - CLOS - Common Lisp Object System

Common LISP embeds an object-oriented programming language called the CLOS - Common Lisp Object System.

It may be characterized as a way of providing genericity, and as it can dispatch methods based on the types of multiple arguments, it supports what is called multimethods that encourages code sharing between methods.

Implementations for other languages include:

It is commonly implemented using the MOP (Meta Object Protocol). See also MOP (Meta Object Protocol) Links and the Cetus OO Links CLOS Link Page.

8.3. Object Oriented - The Cons

While there is a whole lot of "hype" concerning the merits of object oriented techniques, there are also a few dissenting opinions. I would be one of the dissenters; I have never been particularly impressed by the claims of OO programming, particularly in the (typical) C++-based implementations.

I believe that OO is merely one of many possible programming techniques, and that the attempts to map everything onto OO is at least somewhat misguided.

I do not expect people to agree fully with my lack of approval, and I do not stand wholeheartedly with the following authors that also have some problems with OO; their theses are nonetheless worth seeing at least to see some alternative techniques that are of some merit.

8.4. Pattern Languages

8.5. Other Object Orientedness

Contact me at