Identifying Objects in Problem Statements

Every software project begins the same way: with requirements. These might come as formal specification documents, user stories scribbled on sticky notes, verbal descriptions from stakeholders, or even a single sentence on a feature request. Yet the journey from these requirements to working object-oriented code remains one of the most challenging leaps in software engineering.

The fundamental question: How do you look at a problem description—often vague, incomplete, and laden with domain jargon—and see the objects that will form the backbone of your solution?

This skill doesn't come naturally. Most developers, when given a new problem, instinctively think about what the code should do—the sequence of operations, the flow of data, the algorithms to apply. This procedural mindset served us well when learning to code, but it's insufficient for building complex, maintainable systems.

Before we can adopt an object-oriented lens, we need to understand what we're moving away from. Most programmers initially learn to think procedurally—breaking problems into sequences of steps, functions that transform inputs to outputs, and flows of control.

Consider this simple requirement:

"The system should allow customers to place orders for products. When an order is placed, the system should calculate the total price including applicable discounts and taxes, then send a confirmation email to the customer."

The procedural approach reads this and immediately thinks:

This is a valid way to think about the problem, but it immediately couples us to a specific flow. What happens when:

• Business rules for discounts become complex (loyalty programs, seasonal sales, bundle deals)?
• Tax calculations vary by jurisdiction and product category?
• Some customers prefer SMS notifications over email?
• We need to support partial orders, backorders, or pre-orders?

The procedural approach leads to increasingly complex conditional logic, God functions that know everything, and tight coupling between unrelated concerns.

The object-oriented approach reads the same requirement and asks different questions:

An object-oriented lens is a mental framework for interpreting problem statements. It's a deliberate way of reading and analyzing requirements that surfaces the objects, relationships, and behaviors hidden within the text.

Think of it like putting on a special pair of glasses. Without them, a requirements document is just text describing what a system should accomplish. With the OO lens, the same text reveals a cast of characters (objects), their attributes (properties), their abilities (methods), and their relationships (associations).

This lens operates through several key principles:

The power of this lens is that it forces you to think about the structure of a problem before thinking about its solution. This upfront investment in understanding pays dividends:

• Clearer communication with stakeholders who speak in domain terms
• More stable designs that align with how the business actually works
• Easier evolution when requirements change (and they always do)
• Natural modularity where changes to one entity don't ripple everywhere

Reading requirements with an OO lens isn't passive. It's an active, analytical process where you engage with the text, question assumptions, and extract structure from prose. Here's a systematic approach:

Let's apply this to a concrete example. Consider this parking lot system requirement:

"The parking lot management system tracks the occupancy of a multi-floor parking garage. Each floor has multiple parking spots of different sizes (compact, regular, large) for different vehicle types (motorcycles, cars, trucks). The system records when vehicles enter and exit, calculates parking fees based on duration, and displays available spots on each floor."

Analysis through the OO lens:

• ParkingLot — The top-level entity containing everything
• Floor — An entity with its own identity (floor number) and collection of spots
• ParkingSpot — An entity with size, current occupant (if any), and location
• Vehicle — An entity with type and license plate; but is Motorcycle/Car/Truck a subclass or an attribute?
• ParkingTicket — Implicit! When a vehicle enters, something must record entry time
• ParkingFeeCalculator — Implicit! Fee calculation is a behavior that might have complex rules

Notice how active reading reveals entities that weren't explicitly stated but are essential for a working system.

A critical skill when reading with an OO lens is distinguishing between domain objects (entities that exist in the problem space) and implementation details (technical constructs that exist only in the solution space).

Domain objects are concepts that stakeholders understand. If you explained your design to a business analyst or end user, they should recognize these entities. Implementation details are internal mechanics that support the domain objects but don't directly map to real-world concepts.

Why does this distinction matter?

When reading requirements, you should focus primarily on domain objects. Implementation details come later, during detailed design and coding. Mixing them up leads to several problems:

1. Polluted domain model — Your core classes become cluttered with database code, network logic, and other infrastructure
2. Fragile design — Changes in technology (switching databases, changing frameworks) cascade through your domain
3. Lost business logic — The rules that define what your system does become buried under how it does it
4. Harder testing — Domain logic becomes untestable without spinning up databases and web servers

The test is simple: If you're explaining your design to a non-technical stakeholder, would they recognize this object? If yes, it's probably a domain object. If they'd look at you puzzled, it's probably an implementation detail.

Domain objects should speak the language of the business:

• Not 'UserDTO' but 'User'
• Not 'TransactionProcessor' but 'PaymentService' or simply 'Payment'
• Not 'DataStore' but the specific concept being stored

Over time, you'll recognize patterns in how requirements are phrased. These patterns reliably signal specific object-oriented structures. Learning to recognize them accelerates your ability to see the OO structure hidden in prose.

Watch for these revealing words:

• 'Different types of...' → Inheritance or strategy pattern
• 'Based on...' → Parameterized behavior, potentially strategies
• 'Can be...' / 'may be...' → Optional attribute or state
• 'At least one...' / 'multiple...' → Cardinality constraints
• 'Only when...' / 'If...' → Business rules, potentially specifications
• 'History of...' / 'previous...' → Audit trail or temporal data
• 'External...' / 'third-party...' → Integration boundary, adapters

Real-world requirements are rarely crisp and complete. They're often vague, contradictory, or silent on crucial details. Reading with an OO lens means not just extracting what's there, but recognizing what's missing and knowing how to proceed.

Types of requirement ambiguity:

How to handle ambiguity:

1. Document your assumptions explicitly. When the requirement says 'customers have addresses,' write down 'Assumed: Customer has multiple addresses with one marked primary.' This creates a paper trail and invites correction.

2. Ask clarifying questions before design. Don't guess when you can ask. Prepare specific, concrete questions: 'Can a product belong to multiple categories?' is better than 'Tell me more about products.'

3. Design for flexibility when truly uncertain. If you genuinely can't determine whether customers have one or many addresses, design for many—it's easier to constrain later than to expand.

4. Create multiple candidate designs. Sometimes ambiguity suggests multiple valid interpretations. Sketch alternatives and present tradeoffs to stakeholders.

5. Use domain experts. The people who will use the system often know things that weren't captured in requirements. A 30-minute conversation with an actual user can resolve hours of speculation.

Let's walk through a complete example of reading requirements with an OO lens. Here's a partial requirement for a library management system:

"The library system manages a collection of books that members can borrow. Each book has a title, author, and ISBN. Members register with the library by providing their name, email, and a valid ID. A member can borrow up to 5 books at a time for a period of 14 days. If books are returned late, a fine of $0.50 per day is charged. The system should track which books are currently available and allow librarians to add new books or remove damaged ones."

Let's apply our active reading approach:

First Pass Analysis:

Core purpose: Managing book lending in a library.

Key entities mentioned explicitly:

• Library (implied as the system)
• Books
• Members
• Librarians (mentioned in context of adding/removing books)

Key processes:

• Member registration
• Book borrowing and returning
• Fine calculation
• Book management (add/remove)

Second Pass — Extracting Objects:

Critical OO Insight:

The requirement says 'books' but likely means two distinct concepts:

1. Book (bibliographic record) — The abstract concept of a book with title/author/ISBN
2. BookCopy — Physical copies that can be borrowed

A library might have 3 copies of 'Clean Code.' The Book is one entity (Clean Code, Robert Martin, ISBN X); the BookCopies are three entities that can be independently borrowed.

Third Pass — Behaviors and Relationships:

Reading requirements with an OO lens is a fundamental skill that improves with deliberate practice. Here's what we've covered:

What's Next:

Now that you understand how to approach requirements with an OO mindset, the next page dives deeper into the core technique: identifying nouns as potential objects. You'll learn systematic methods for extracting candidate classes from any problem statement and how to filter the noise from the signal.