How Objects Communicate: Calling Methods and Passing Data
In the zone model, an object is a self-contained unit that combines methods, which provide executable instructions, with attributes, which hold data.
From Monolith to Zones
A program that uses multiple objects is not one monolithic block of instructions. It is better understood as several semi-independent zones working together. Each zone has a responsibility, contains code and data, and communicates with other zones through defined interactions.
In the zone model, an object is a self-contained unit that combines methods, which provide executable instructions, with attributes, which hold data.
Shared Instructions, Separate State
When a class creates an object, that object becomes a new zone. The object has its own data in its attributes and access to the methods defined by the class. Multiple objects created from the same class share one code zone, but they maintain separate data zones. The instructions are written once, while each object can operate with its own internal state.
Crossing an Object Boundary
Objects communicate through well-defined boundaries. One zone can call a method provided by another zone, pass data to that method, and receive a result. The receiving zone executes its own instructions and works with its own data. The calling zone can then use the result, update its own data, or communicate with another zone.
When designing a zone, ask three questions: What data does this zone need to hold? What methods does it need to provide? How will it interact with other zones?
A Three-Zone Trace
Extracting Links from a Web Page
Trace how three object zones can cooperate to extract links from a web page.
- 1Fetching
A fetcher zone retrieves the web page's HTML text.
- 2Passing
The fetcher zone passes the HTML text to a parser zone.
- 3Parsing
The parser zone processes the HTML and extracts link data.
- 4Storing
The parser zone passes the extracted link data to a collection zone that stores and manages it.
The zones accomplish one larger task together while each remains responsible for its own code and data.
This trace shows why a multi-object program does not have to follow one uninterrupted path inside one zone. Control moves from the fetcher to the parser and then to the collection zone as methods are called and data is exchanged.
External Inputs and Outputs
A zone can also interact with the external world through a defined boundary. In the web-page example, the fetching zone obtains HTML text from outside the program. That information crosses into the program, moves between object zones, and becomes extracted link data managed by another zone. The important idea is that each zone handles its own responsibility while coordinating through exchanged data.
Mistakes Beginners Make
Common mistake Treating the program as one monolithic block
What it looks likeLooking only at the full task instead of identifying which zone fetches, parses, or stores information.
Why it failsThis makes it difficult to reason about where data flows and which object should handle a task.
Do this insteadSeparate the program into zones and identify each zone's responsibility, methods, and data.
Common mistake Assuming objects from the same class have identical data
What it looks likeAssuming that two objects sharing a class's methods must also share the same attribute values.
Why it failsObjects of the same class share code but maintain separate data zones.
Do this insteadTrack the methods as shared class code and the attributes as data belonging to each individual object.
Common mistake Treating the zone model as a literal memory diagram
What it looks likeInterpreting a drawn zone as a claim about the program's exact memory layout.
Why it failsThe zone model is a conceptual tool for design and reasoning, not a literal description of memory.
Do this insteadUse zones to discuss responsibilities, code, data, boundaries, and interactions.
Common mistake Giving one zone too many responsibilities
What it looks likeDesigning one zone that fetches information, parses it, and manages all resulting data.
Why it failsA zone that tries to do too much becomes harder to understand, test, and modify.
Do this insteadUse the zone model to identify opportunities for multiple, more focused zones.
Practice the Trace
Imagine a program with three zones: an input zone receives information from the external world, a processing zone transforms that information, and a storage zone keeps the result. Describe the order of method calls and identify what data crosses each boundary.
Hints
- Begin with the zone that interacts with the external world.
- Name the data passed from the input zone to the processing zone.
- Explain what result the processing zone passes to the storage zone.
- 1An object is a zone that combines methods and attributes.
- 2Objects communicate by calling methods, passing data, and returning results.
- 3Objects from the same class can share code while keeping separate data.
- 4External information can enter through one zone and move through other zones via defined interactions.
- 5The zone model helps reveal responsibilities and suggests when a large zone should be split into more focused zones.
Key Takeaways
- Object-oriented programs can be understood as cooperating zones rather than one monolithic instruction block.
- Each object combines executable methods with stored attribute data.
- A method call moves control across a boundary, may carry data into the receiving zone, and can return a result.
- Objects created from the same class share code while maintaining separate data.
- The zone model is a design and reasoning tool for assigning clear responsibilities and tracing data flow.