Christopher B. Browne's Home Page
cbbrowne@acm.org

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

Builder

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

Prototype

Objects are specified using a prototypical instance

Singleton

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

8.1.2. Structural Patterns

Adapter

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

Bridge

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

Composite

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

Decorator

Attaches additional responsibilities to an object dynamically

Facade

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

Flyweight

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

Proxy

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

Command

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

Interpreter

Defines a language and its interpreter

Iterator

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

Mediator

An object that controls how a set of objects interact

Memento

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

Observer

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

State

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

Strategy

Defines a set of interchangeably usable algorithms

Template Method

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

Visitor

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

Google

If this was useful, let others know by an Affero rating

Contact me at cbbrowne@acm.org