Is OO Really So Different? 

There are many differences between object oriented development and traditional, procedural development. Let's start with a simplified distinction. Procedural development is usually pursued by techniques such as functional decomposition with step-wise refinement, where the system being developed is described in terms of what it does. For example, a procedural Order Entry system would be decomposed into functions such as: OpenCustomerFile( ), ConstructOrder( ), ShipOrder( ), CancelOrder( ), QueryOrderStatus( ), etc. Isolated modeling techniques such as Data Flow Diagrams (DFDs) are developed to show the data that passes into and out of each function, and from the DFDs a data model is constructed describing the data on which these functions operate and how that data is stored. The data model then becomes the centerpiece of the system’s description as well as a major constraint on new functionality in the system.

Object oriented development does not so much describe what’s being done, rather it focuses on what it is being done to. In an object oriented or component-based Order Entry system, we start with the "things" (we call them classes) that carry out the goals of an Order Entry system: Orders, Shipments, Customers, Accounts, etc. First, we describe the responsibilities associated with these classes: for example, a Shipment class is responsible for knowing or determining the current status of any Order which has been prepared by the company’s Fulfillment organization, and it is also responsible for arranging the correct mode of shipment (e.g., UPS Ground, FedEx Overnight Air, Slow Boat, etc.) for a given Order. Using integrated modeling techniques such as class diagrams, interaction diagrams and statechart diagrams, the class designer determines what functionality is needed to support these class-specific responsibilities. From these operations the class designer then determines what data should be owned by the class in order to support the class’s operations. All of the data and functionality related to shipping an order is in the Shipment class, not in (usually) global functions and data structures floating around in the memory space.

The emphasis placed on models in object oriented development is a paramount distinction between this software approach and that of procedural development. In the structured, procedural world we design solutions to a problem—a specific problem, e.g., rating an insurance policy, or tracking account statuses. In the object world we build models of systems which solve many problems. Ivar Jacobson, a leading thinker in the object world, said "System development is model building."¹ These models are the system: initially the models describe the business problems to be solved, then they evolve into models of the particular technical solution we have chosen. An appropriate metaphor is to view the models initially as strategic views of what things are needed, then that these strategic models are transformed into tactical implementations of how the solution will be achieved.

Because structured techniques have been used for so long, and because we are all so familiar with them, another important contrast is often overlooked. Structured techniques propagate the separation of program and data that was one of the defining characteristics of the von Neumann architecture which led to the development of modern computers.

The data-flow and data-structure design techniques from the '70's and '80's have a goal of deriving the program functionality (both procedure and structure) from the data handled by the program. Functional decomposition, as an analysis and design technique, inverts this approach somewhat, but still is founded upon the structure of the data handled by the hierarchical input-process-output (H-I-P-O) decomposition trees that this technique yields.

The object oriented approach differs significantly in two major areas.

First, object-oriented thinking reverses the program/data split of structured techniques. In fact, the whole concept of an object providing encapsulation (automatically join together data and the functions which operate on that data) and information hiding (separating interface from implementation) is a wholesale rebellion against the separation of function from data. In objects we want to meaningfully integrate function and data. And by meaningfully, we mean a semantic relation, not the often merely syntactic relation found in structured techniques. In the object world the data are really needed only to support the behavior and responsibilities of the objects. In fact, since the data are normally private, it is quite common to not address the data formats, etc. until late in analysis or early in design.

Second, in object-oriented analysis and design we have no H-I-P-O hierarchies—in fact, we have no "main", or top-most, object as we have a "main", or top-most, procedure in structured techniques. Object models are "flat". It is not possible to determine which object drives the application, because in objects no single object should drive anything beyond its local sphere of influence.

Object oriented development is different from procedural development, and requires different skills and a different way of thinking. It can be painful to attempt the transition, but no more painful than organizations felt during the change from file-/network-server systems to client/server systems. The benefits of object oriented development come from careful planning, timely preparation, and easing into this new world in a controlled manner, and by giving thoughtful consideration to the recommendations of those who have blazed the trail earlier.

¹ Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1990, pg. 113.