Designing Objects with Single Responsibility
A zone is a self-contained unit combining code (methods) and data (attributes) with well-defined interactions with other zones and the external world.
From Monolith to Zones
A program that uses multiple objects is not one monolithic block of instructions. It can be understood as several semi-independent zones working together. Each zone combines code, represented by methods, with data, represented by attributes. Designing objects with single responsibility means giving each zone one well-defined job and making its interactions with other zones clear.
A useful design question is: What data does this object need, what code does it need to provide, and how should it interact with other objects?
Inside One Object
Think of one object as a self-contained zone. Its attributes hold the data that belongs to that particular object. Its methods provide the code that operates on or uses that data. In this model, data is the what: the values held by the object. Methods are the how: the instructions the object can use to work with those values.
Shared Instructions, Separate State
When several objects come from the same class, they share the code zone defined by that class, but they maintain separate data zones. The instructions are written once, while each object keeps its own attribute values and can operate independently. This distinction helps explain how one design can support multiple objects without giving those objects identical state.
Sharing code does not mean sharing object state. Objects of the same class can use the same methods while maintaining separate data zones.
Following Data Across Boundaries
Objects cooperate through boundaries rather than by exposing every internal detail. Control moves when one zone calls a method on another. Data can be passed into that interaction, the receiving zone can use its own code and data, and a result can be returned. This gives each object room to manage its own responsibility while still contributing to a larger task.
When defining a zone, make its responsibility and its interactions explicit. Ask what information it receives, what data it owns, what work its methods perform, and what result it provides to another zone.
A Link-Extraction Pipeline
Separating Web Page Responsibilities
How could a program extract links from web pages without placing every task in one monolithic block?
Fetching: A fetcher zone retrieves the web page and produces HTML text.
Parsing: A parser zone receives the HTML text and processes it to extract link data.
Managing: A collection zone receives the extracted links and stores or manages them.
Coordinating: The overall program coordinates the zones by passing results from the fetcher to the parser and from the parser to the collection.
Each zone has a focused responsibility, yet the zones cooperate to accomplish the larger task of extracting and managing links.
The control flow is not a single straight line inside one zone. It moves between zones. One zone calls another, passes data, receives a result, and then may use that result to continue the task. The zones remain distinct because each one manages its own code and data.
Recognizing Responsibility Drift
Treating the whole program as one undivided block of instructions
This makes it harder to reason about where data flows and which object should handle each task.
Fix:
Identify the distinct zones involved and give each one a focused responsibility.Assuming objects of the same class have the same data
Objects of the same class share the code zone but maintain separate data zones.
Fix:
Reason about class methods as shared instructions and each object as having its own attribute values.Making one zone responsible for too many tasks
A zone that tries to do too much becomes harder to understand, test, and modify.
Fix:
Split the work into multiple, more focused zones with clear interactions.Treating the zone model as a literal memory diagram
The zone model is a conceptual tool for understanding program structure, not a literal description of memory.
Fix:
Use zones to reason about responsibilities, code, data, and interactions.
Design Review Questions
Consider a program that fetches a web page, parses its HTML, and manages the extracted links. Identify the responsibility of each zone, the data passed from one zone to the next, and one reason the zones should not all be combined into a single object.
Hints
- Start with the three zones described in the worked example.
- Trace the output of the fetcher into the parser, then the parser into the collection.
- Relate separation of responsibilities to understandability, testing, and modification.
What do you think happens?
A fetcher zone passes HTML text to a parser zone. What should the parser zone primarily do next?
Reveal answer
Answer: Process the HTML text and pass extracted link data onward
The parser zone has the focused responsibility of processing HTML content. The source example describes the fetcher, parser, and collection zones as separate pieces that exchange results through their interactions.
Design Takeaways
- An object can be understood as a zone combining methods, which provide code, and attributes, which hold data.
- Objects of the same class can share one code zone while maintaining separate data zones.
- Objects communicate by calling methods, passing data, and returning results through well-defined interactions.
- Assigning each zone one well-defined responsibility helps make a program easier to understand, test, and modify.
- The zone model is a conceptual tool for reasoning about structure and responsibilities, not a literal description of memory.
Key Takeaways
- A single-responsibility object is a focused zone that combines its own data with the methods that work with that data.
- Multiple objects can cooperate without becoming one monolithic block of instructions.
- Clear boundaries let objects receive data, perform their responsibility, and return results.
- Objects of the same class share code but keep separate state.
- The zone model helps expose when an object has become too large or is trying to do too much.