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:
Clicking on a button at the top of the screen
Pulling down a menu
Moving the mouse across an icon bar
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.
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.
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.
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
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
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
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.
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:
The Bigloo Object System
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.
Write programs starting with a visual presentation of a state diagram, and then automagically generate code in various languages such as C, C++, Java, COBOL, Perl, ...
To have good, safe, object oriented systems, "Talk Only to your immediate friends."