Identifying Objects & Classes

Finding Objects in the Problem Domain

The first step in OO analysis is identifying the objects and classes that exist in your problem domain. This means reading through requirements, talking to stakeholders, and looking at the real-world processes you're trying to model. Objects are the "nouns" in your system — the things that have state and behavior.

A good starting point is to scan requirements documents for nouns. Nouns often represent potential classes, while verbs often represent operations. But not every noun becomes a class — you need to filter for things that are relevant to the system and have distinct behavior or state.

Requirements Example:
"Students register for courses. Each course has a maximum capacity.
 Instructors assign grades. The system sends email notifications."

Nouns → Potential Classes:
  Student ✓    (has state: name, ID; behavior: register, drop)
  Course ✓     (has state: capacity, schedule; behavior: enroll, cancel)
  Instructor ✓ (has state: name, department; behavior: assign grade)
  Grade ✓      (maybe an attribute, not a full class)
  System ✗     (too vague)
  Email ✗      (implementation detail, not a domain concept)

Verbs → Potential Operations:
  register   → Student.register(course)
  assign     → Instructor.assignGrade(student, grade)
  send       → NotificationService.sendEmail()

Techniques for Identifying Objects

Several techniques help you systematically discover objects and classes:

1. Noun Phrase Analysis
   ─────────────────────
   Scan requirements for noun phrases.
   "A patient books an appointment with a doctor"
   → Patient, Appointment, Doctor

2. Event Analysis
   ──────────────
   List events that occur in the system.
   "A customer places an order, receives confirmation,
    and can track shipment"
   → Order, Confirmation, Shipment

3. Responsibility Analysis
   ────────────────────────
   Ask: "What responsibilities does the system have?"
   "The system must manage inventory, process payments,
    and generate reports"
   → Inventory, PaymentProcessor, ReportGenerator

4. CRC Cards (Class-Responsibility-Collaborator)
   ──────────────────────────────────────────────
   Create index cards with:
   • Class name
   • Responsibilities (what it does)
   • Collaborators (what it works with)

┌─────────────────────────────────────┐
│ Class: Order                        │
├─────────────────────────────────────┤
│ Responsibilities:                   │
│  • Track order status               │
│  • Calculate total price            │
│  • Apply discounts                  │
│  • Generate invoice                 │
│                                     │
│ Collaborators:                      │
│  • Customer                         │
│  • OrderItem                        │
│  • PaymentProcessor                 │
│  • InventoryManager                 │
└─────────────────────────────────────┘

Filtering Candidates

Not every noun becomes a class. Apply these filters to decide what stays:

Keep as a Class if:
  ✓ It has attributes that need to be stored
  ✓ It has behavior (methods) beyond simple getters/setters
  ✓ It represents a real-world entity or concept
  ✓ Multiple instances will exist
  ✓ It interacts with other objects

Discard if:
  ✗ It's a primitive value (just use a string or number)
  ✗ It's a duplicate of an existing class
  ✗ It has no behavior and few attributes (consider making it an attribute)
  ✗ It's an implementation detail (database connection, logger)
  ✗ It's a verb (that's a method, not a class)

For example, in a library system, "book title" is just a string attribute of Book — not its own class. But "Book" is definitely a class because it has state (title, author, ISBN, availability) and behavior (checkOut, return, reserve).

Example: Hospital Management System

Let's walk through identifying objects for a hospital system:

Problem Statement:
"The hospital manages patients, doctors, and appointments.
 Patients have medical records. Doctors work in departments.
 The system schedules surgeries and manages billing."

Step 1: Extract nouns
  Patient, Doctor, Appointment, Medical Record, Department,
  Surgery, Bill, Hospital, System

Step 2: Filter and refine
  ✓ Patient      — has records, books appointments
  ✓ Doctor       — has specialties, works in departments
  ✓ Appointment  — connects patient and doctor
  ✓ MedicalRecord — stores patient history
  ✓ Department   — organizes doctors and rooms
  ✓ Surgery      — scheduled procedure with team
  ✓ Bill         — tracks costs and payments
  ✗ Hospital     — too broad (the whole system, not a class)
  ✗ System       — too vague

Step 3: Define relationships
  Patient ──has──▶ MedicalRecord
  Doctor  ──belongs to──▶ Department
  Appointment ──involves──▶ Patient, Doctor
  Surgery ──scheduled by──▶ Doctor, involves──▶ Patient
  Bill ──generated for──▶ Patient, includes──▶ Services

Pitfalls to Avoid

Common mistakes when identifying objects:

1. God Object
   ────────────
   Making one class do everything.
   "System" or "Manager" that handles all operations.
   → Break it into smaller, focused classes.

2. Anemic Domain Model
   ────────────────────
   Classes that are just data containers with no behavior.
   All logic lives in service classes.
   → Move behavior into the objects that own the data.

3. Analysis Paralysis
   ────────────────────
   Spending too much time trying to find the "perfect" model.
   → Start with a good-enough model and refine as you learn more.

4. Over-engineering
   ──────────────────
   Creating classes for every little concept.
   → Keep it simple. Only create classes that add clear value.