KISS
Keep the design as simple as the actual requirements allow. Simplicity is not missing validation: a short direct algorithm with explicit boundaries can be easier to reason about than a configurable framework.
What you’ll understand
- Keep the design as simple as the actual requirements allow. Simplicity is not missing validation: a short direct algorithm with explicit boundaries can be easier to reason about than a configurable framework.
- Use a direct maximum operation and an explicit empty-input branch.
- Evaluate the tradeoff: The simplest design depends on the requirement. If values arrive continuously or ranking is queried repeatedly, a richer data structure may become justified.
Useful first: Classes and Objects
The idea and when to recognize it
Keep the design as simple as the actual requirements allow. Simplicity is not missing validation: a short direct algorithm with explicit boundaries can be easier to reason about than a configurable framework.
- Requirement: A tool needs the largest value in a list, with null for an empty list.
- Change to anticipate: Handle negative values correctly without introducing a stateful ranking service.
- Design goal: Use a direct maximum operation and an explicit empty-input branch.
Start with the concrete problem
A tool needs the largest value in a list, with null for an empty list.
Handle negative values correctly without introducing a stateful ranking service.
| Direct implementation | Revised design |
|---|---|
| Starting the maximum at zero silently assumes every input is nonnegative. | Use a direct maximum operation and an explicit empty-input branch. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | The simplest design depends on the requirement. If values arrive continuously or ranking is queried repeatedly, a richer data structure may become justified. |
Responsibilities and contracts
Use a direct maximum operation and an explicit empty-input branch.
- MaximumQuery: Owns the empty-input contract. Public operations: maximum(values)
- Values: Supplies a finite collection. Public operations: items
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
A configuration lookup can use a map until requirements actually call for inheritance and dynamic rule resolution.
- 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
The simplest design depends on the requirement. If values arrive continuously or ranking is queried repeatedly, a richer data structure may become justified.
Common mistake: Starting the maximum at zero silently assumes every input is nonnegative.
- Explain the choice: Use a direct maximum operation and an explicit empty-input branch.
- Challenge your choice: The simplest design depends on the requirement. If values arrive continuously or ranking is queried repeatedly, a richer data structure may become justified.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…