Nouns as Potential Objects

If there's one technique that every object-oriented designer learns early, it's this: nouns in a problem statement are candidate objects. This simple heuristic has guided countless developers from requirements to code, providing a systematic starting point for design.

But like many simple rules, its effective application requires nuance. Not every noun becomes a class. Some nouns represent attributes, others describe roles or states, and some are simply noise. The real skill lies in separating the meaningful from the meaningless—transforming a raw list of nouns into a refined set of domain objects.

This page teaches you that skill.

The noun-to-object mapping isn't arbitrary—it reflects a deep connection between language and software design.

In natural language, nouns represent things—concrete entities like 'customer,' 'invoice,' and 'product,' or abstract concepts like 'payment,' 'reservation,' and 'permission.' These are the subjects and objects of sentences, the entities around which actions revolve.

In object-oriented programming, classes represent things—entities that have identity, state, and behavior. They are the nouns of our code, the building blocks around which we organize logic.

This parallel isn't coincidental. Object-oriented programming was designed to model real-world (and conceptual) domains. The vocabulary of the domain—its nouns—naturally maps to the classes in an OO design.

Historical context:

The noun-extraction technique dates back to the 1980s, popularized by Rebecca Wirfs-Brock in her work on responsibility-driven design and later formalized in methodologies like the Booch Method and UML. It has stood the test of time because it works—not perfectly, but as a reliable starting point.

The technique works because:

1. It's grounded in domain language — The nouns you extract come from how stakeholders describe their business
2. It provides structure — Instead of staring at a blank page, you have concrete candidates to evaluate
3. It's teachable and repeatable — Unlike pure intuition, it can be learned and applied consistently
4. It scales — The same technique works for small features and large systems

Let's formalize the process of extracting nouns from requirements. While it seems straightforward, doing it rigorously ensures you don't miss important candidates.

Step 1: Identify All Nouns

Go through your requirements and mark every noun and noun phrase. Be inclusive at this stage—you'll filter later. Include:

• Common nouns: customer, product, order, payment
• Proper nouns: when they represent types (e.g., 'VIP Member,' 'Priority Shipping')
• Noun phrases: 'shopping cart,' 'delivery address,' 'payment method'
• Gerunds used as things: 'booking' (when it means 'a reservation'), 'shipping' (when it means 'a shipment')
• Abstract nouns: permission, status, category, type

Let's practice with this requirement:

"An online bookstore allows customers to browse books by category, add them to a shopping cart, and checkout using credit cards or gift cards. The store offers discounts for bulk purchases and loyalty points for repeat customers. Customers can track their orders and write reviews for purchased books."

Step 2: Create a Candidate List

Organize your extracted nouns into a table for systematic analysis. For each noun, you'll eventually determine:

• Is it a class, an attribute, or neither?
• If a class, what are its key responsibilities?
• If an attribute, which class does it belong to?

Not all nouns are equal. As you analyze your candidates, you'll find they fall into distinct categories. Understanding these categories helps you make the right design decisions.

The most valuable categories for OO design are:

1. Concrete Entities — These almost always become classes. They have identity (two Customers are different even if they have the same name), state (attributes change over time), and behavior (they do things).

2. Abstract Concepts — These often become classes, especially if they have their own rules and complexity. A Discount isn't just a number—it has conditions, expiration dates, and application logic.

3. Event/Action Nouns — Words like 'payment,' 'reservation,' 'shipment' represent things that happened. In well-designed systems, these are often modeled as classes so they can be tracked, audited, and reasoned about.

Now comes the crucial step: filtering your noun candidates to identify genuine classes. Apply these criteria to each candidate:

Applying these criteria to our bookstore example:

One of the most common decisions during noun analysis is whether something should be a class in its own right or an attribute of another class. This decision has significant design implications.

Consider 'Address' in a customer management system:

• As an attribute: Customer has streetAddress, city, state, zipCode fields
• As a class: Customer has an Address object (or List<Address>)

When should Address be a class?

The golden rule: If it has behavior, make it a class.

An Address that can format itself for display, validate itself, calculate shipping zones, or compare itself to other addresses has behavior—and thus belongs in a class.

A 'price' is usually an attribute (a simple decimal). But if price has complex behaviors—discount calculations, currency conversion, tax inclusion rules—it might become a Money or Price class.

More examples of the attribute-vs-class decision:

Real requirements documents are written by humans, often multiple stakeholders. This means the same concept may appear under different names, and different concepts may accidentally share a name.

Synonyms: Different Words, Same Concept

Consider these appearing in the same requirements:

• customer, buyer, user, client, patron

These might all refer to the same entity—the person who purchases from your system. Recognizing synonyms prevents you from creating redundant classes and aligns your design with a single, consistent vocabulary.

Homonyms: Same Word, Different Concepts

The opposite problem: one word used to mean different things.

Consider 'account':

• Financial account — Where money is tracked (balance, transactions)
• User account — Login credentials and profile (username, password)

These are fundamentally different entities that happen to share a name. In code, you might have:

• UserAccount or LoginAccount — Authentication and identity
• FinancialAccount or BillingAccount — Money management

Detection techniques:

1. Group by responsibility — Sort your nouns by what they're responsible for. Synonyms cluster together; homonyms spread across multiple groups.

2. Ask stakeholders — When you encounter 'order' in different contexts, confirm: Is the 'order' from the warehouse and the 'order' from customer service the same thing?

3. Look at attributes — If two nouns have completely different attributes, they're probably different concepts, even if named similarly.

4. Consider lifecycle — Do the entities go through the same states? A sales order and a work order have different lifecycles—they're different classes.

Some of the most important classes in your design don't appear explicitly in the requirements. They're implied by relationships, actions, or constraints that the requirements describe.

Implicit nouns from verbs:

When you see actions like 'customer places order,' there's an implicit noun: the placement itself. Is there value in capturing when, how, and in what context the order was placed? If yes, you've discovered an implicit class.

Implicit nouns from relationships:

When two entities are related with additional information about that relationship, there's often an implicit join entity.

"Students can enroll in courses. The system tracks their grade and enrollment date."

• Explicit nouns: Student, Course
• Implicit noun: Enrollment (the relationship carrying grade and date)

Without Enrollment as a class, you'd struggle to capture per-course grades for each student.

Implicit nouns from collections:

When requirements describe a collection that needs its own behavior, there's often an implicit collection class.

"The shopping cart should show total price, allow removing items, and suggest related products."

The Cart isn't just a list of items—it has its own behaviors (calculate total, suggest products). It deserves to be a class, not just a List<Product> on Customer.