Classes and Objects
A class defines behavior and construction rules; an object is one identity with its own current state. Two objects built from one class need not share their mutable fields.
What you’ll understand
- A class defines behavior and construction rules; an object is one identity with its own current state. Two objects built from one class need not share their mutable fields.
- Initialize each cart’s item list in its constructor so mutation belongs to one instance.
- Evaluate the tradeoff: Objects help group state with operations, but a small immutable value may only need a plain record. Use a class when identity or protected state transitions matter.
The idea and when to recognize it
A class defines behavior and construction rules; an object is one identity with its own current state. Two objects built from one class need not share their mutable fields.
- Requirement: A store needs two independent carts. Adding an item to one customer’s cart must not change the other customer’s purchase.
- Change to anticipate: Create a second cart and add a different number of items to each while preserving independent totals.
- Design goal: Initialize each cart’s item list in its constructor so mutation belongs to one instance.
Start with the concrete problem
A store needs two independent carts. Adding an item to one customer’s cart must not change the other customer’s purchase.
Create a second cart and add a different number of items to each while preserving independent totals.
| Direct implementation | Revised design |
|---|---|
| Putting a mutable item list on a shared class or module makes all customers appear to own the same cart. | Initialize each cart’s item list in its constructor so mutation belongs to one instance. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Objects help group state with operations, but a small immutable value may only need a plain record. Use a class when identity or protected state transitions matter. |
Responsibilities and contracts
Initialize each cart’s item list in its constructor so mutation belongs to one instance.
- Cart: Owns one customer’s line items. Public operations: add(value), total()
- Store: Creates independent carts. Public operations: new Cart()
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
Each game player can own an independent inventory even when every player uses the same Player class.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Objects help group state with operations, but a small immutable value may only need a plain record. Use a class when identity or protected state transitions matter.
Common mistake: Putting a mutable item list on a shared class or module makes all customers appear to own the same cart.
- Explain the choice: Initialize each cart’s item list in its constructor so mutation belongs to one instance.
- Challenge your choice: Objects help group state with operations, but a small immutable value may only need a plain record. Use a class when identity or protected state transitions matter.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…