---

The Object Model

The insight of object-oriented programming is to combine state and behavior —data and operations on data—in a high-level unit, an object , and to give it language support. An object is a group of related functions and a data structure that serves those functions. The functions are known as the object’s methods , and the fields of its data structure are its instance variables . The methods wrap around the instance variables and hide them from the rest of the program, as Figure 3-1 illustrates:

Likely, if you’ve ever tackled any kind of difficult programming problem, your design has included groups of functions that work on a particular kind of data—implicit “objects” without the language support. Object-oriented programming makes these function groups explicit and permits you to think in terms of the group, rather than its components. The only way to an object’s data, the only interface, is through its methods.

By combining both state and behavior in a single unit, an object becomes more than either alone; the whole really is greater than the sum of its parts. An object is a kind of self-sufficient “subprogram” with jurisdiction over a specific functional area. It can play a full-fledged modular role within a larger program design.

For example, if you were to write a program that modeled home water usage, you might invent objects to represent the various components of the water-delivery system. One might be a Faucet object that would have methods to start and stop the flow of water, set the rate of flow, return the amount of water consumed in a given period, and so on. To do this work, a Faucet object would need instance variables to keep track of whether the tap is open or shut, how much water is being used, and where the water is coming from.

Clearly, a programmatic Faucet can be smarter than a real one (it’s analogous to a mechanical faucet with lots of gauges and instruments attached). But even a real faucet, like any system component, exhibits both state and behavior. To effectively model a system, you need programming units, like objects, that also combine state and behavior.

A program consists of a network of interconnected objects that call upon each other to solve a part of the puzzle. Each object has a specific role to play in the overall design of the program and is able to communicate with other objects. Objects communicate through messages , requests to perform methods.

The objects in the network won’t all be the same. For example, in addition to Faucets, the program that models water usage might also have Pipe objects that can deliver water to the Faucets and Valve objects to regulate the flow among Pipes. There could be a Building object to coordinate a set of Pipes, Valves, and Faucets, some Appliance objects—corresponding to dishwashers, toilets, and washing machines—that can turn Valves on and off, and maybe some Users to work the Appliances and Faucets. When a Building object is asked how much water is being used, it might call upon each Faucet and Valve to report its current state. When a User starts up an Appliance, the Appliance will need to turn on a Valve to get the water it requires.

Contents:

The Messaging Metaphor
Classes
Mechanisms Of Abstraction
Inheritance
Dynamism

---