Introduction to Objects and Classes
When a program uses multiple objects, it is not best understood as one monolithic block of instructions.
From Monolith to Zones
When a program uses multiple objects, it is not best understood as one monolithic block of instructions. A more useful mental model is a collection of semi-independent zones. Each zone has code that describes how it behaves and data that records what it currently contains. The zones coordinate by calling methods, exchanging data, and returning results.
A zone is a self-contained unit that combines code, represented by methods, and data, represented by attributes, with well-defined interactions with other zones and the external world.
Inside One Object
In the zone model, each object is a zone. Its attributes hold the values that belong to that particular object. Its methods provide the code that the object can call to perform work on those values. This joins the how of a program, its instructions, with the what, its stored state.
The diagram separates the two parts without disconnecting them. Methods are the instructions, while attributes are the object's stored state. A method can use the object's attributes, change them, or produce a result for another zone. The model therefore helps you ask two practical design questions: what data does this object need to hold, and what code does it need to provide?
Shared Code, Separate State
Two Parser Objects
Imagine creating two objects from the same parser class.
- 1Identify the shared part
Both objects have access to the code defined in the class. The class definition supplies the methods that describe how a parser behaves.
- 2Identify the separate part
Each parser object maintains its own data zone. The values stored in one parser's attributes are separate from the values stored in the other parser's attributes.
- 3Trace a method call
When a method is called on one parser object, the shared class code is used with that particular object's data. The other parser object keeps its own state.
Objects created from the same class can share one code zone while maintaining separate data zones.
| Part | Meaning | Relationship across same-class objects |
|---|---|---|
| Methods | Instructions describing how the object behaves | Shared through the class code zone |
| Attributes | Values representing the object's stored state | Maintained separately by each object |
The zone model separates an object's behavior from its particular stored state.
This relationship is one of the central ideas in the model. Writing the instructions once allows the same class code to work with many different data sets. Each object can therefore operate independently even though the objects use the same methods.
Boundaries and Requests
A zone is not isolated from everything else. It interacts with other zones and with the external world through well-defined boundaries. Other parts of the program do not need to know every detail inside the zone. They request behavior through the object's available methods, pass data when needed, and receive results.
A Multi-Zone Flow
Extracting Links from a Web Page
Trace how several object zones can cooperate to extract links from a web page.
- 1Fetch
A fetcher zone retrieves the page's HTML text.
- 2Pass
The fetcher zone passes the HTML text to a parser zone.
- 3Parse
The parser zone processes the HTML content and extracts link data.
- 4Store
The parser zone passes the extracted link data to a collection zone that stores and manages it.
The zones combine focused responsibilities: fetching, parsing, and managing the extracted links.
This flow is not a single straight block of instructions. Control moves between zones. One zone calls on another, passes data, and receives a result. A receiving zone can then use that result to update its own data or call another zone. Each zone remains responsible for its own code and data, while the complete program accomplishes a larger task.
Mistakes in Zone Thinking
Common mistake Treating the whole program as one monolithic block
What it looks likeLooking only at the complete task instead of separating fetching, parsing, and collection responsibilities
Why it failsThis hides where data flows and makes it harder to decide which object should handle a task.
Do this insteadIdentify the semi-independent zones, then describe each zone's code, data, and interactions.
Common mistake Assuming objects from the same class have identical data
What it looks likeConcluding that two parser objects must maintain the same internal state because they use the same class
Why it failsObjects of the same class share the class code zone but maintain separate data zones.
Do this insteadSeparate the shared methods from the attributes belonging to each individual object.
Common mistake Confusing methods with attributes
What it looks likeDescribing an object's instructions as though they were the values stored in the object
Why it failsMethods represent code and attributes represent data. They play different roles in the zone model.
Do this insteadAsk whether a detail explains how the object behaves or what state the object currently contains.
Common mistake Treating the zone model as a literal memory diagram
What it looks likeAssuming that every conceptual zone must correspond to one exact physical memory region
Why it failsThe source presents zones as a conceptual tool for design and reasoning, not a literal description of memory.
Do this insteadUse zones to discuss responsibilities, state, and interactions.
Practice the Model
Imagine a program with three zones: one retrieves information, one processes it, and one stores the results. Describe the code and data of each zone, then trace the request and data flow from the first zone to the last.
Hints
- For each zone, name the responsibility it owns.
- Separate the methods that describe how the zone works from the attributes that hold its state.
- Identify what data is passed between zones and what result is returned.
When designing an object-oriented program, ask three questions for every proposed zone: What data must it hold? What methods must it provide? How will it interact with other zones? If one zone becomes too large or tries to do too much, the zone model suggests splitting it into more focused zones.
The Zone Model
- 1An object can be viewed as a zone containing methods, which represent code, and attributes, which represent data.
- 2Objects created from the same class share the class code zone while maintaining separate data zones.
- 3Zones interact through well-defined boundaries as methods are called, data is passed, and results are returned.
- 4The zone model helps you reason about responsibilities and program structure; it is not a literal description of memory.
- 5A well-designed zone has a focused responsibility and coordinates with other zones to accomplish a larger task.
Key Takeaways
- An object-oriented program can be understood as cooperating zones rather than one monolithic block.
- Each object zone combines code in the form of methods with data in the form of attributes.
- Multiple objects of the same class share code while keeping separate state.
- Control moves between zones through method calls, passed data, and returned results.
- The zone model supports design reasoning about responsibilities and boundaries, not literal memory layout.