OO Analysis and Design

OO Analysis and Design

Before you write a single class, you face a harder problem than coding: deciding what classes should even exist. Object-Oriented Analysis and Design (OOAD) is the disciplined bridge from a fuzzy problem statement ("build a ride-sharing dispatcher") to a set of collaborating objects that model that problem faithfully. It exists because the naive alternative—jumping straight to code driven by the database schema or by whatever screen you're building—produces designs that fight the domain. When requirements shift (and they always do), a domain-faithful model bends; a schema-driven or procedure-driven one snaps.

The core insight of OOAD is that a good software structure mirrors the structure of the problem. If the real world has Riders, Drivers, and Trips that relate in specific ways, your objects should too. Then a change in one real-world concept touches exactly one place in code. This is why interviewers open low-level design rounds with "design a parking lot" rather than "write a linked list"—they're testing whether you can extract structure from ambiguity.

How it works: analysis then design

OOAD splits into two phases with a deliberate wall between them.

• OO Analysis (OOA) asks what: understand the domain, independent of any technology. You gather requirements, identify the key concepts (candidate objects), their responsibilities, and how they relate. The classic heuristic is noun–verb extraction: nouns in the requirements ("a rider requests a trip") become candidate classes; verbs ("request, assign, cancel") become behaviors. The output is a conceptual model—a domain vocabulary, not code.
• OO Design (OOD) asks how: turn that conceptual model into a software model that a machine can run. You assign concrete responsibilities to classes, define interfaces and method signatures, decide relationships (association, aggregation, composition, inheritance), and apply patterns and principles (SOLID, GRASP). The output is class diagrams, sequence diagrams, and skeleton code.

The wall matters: analysis in domain terms keeps you from prematurely baking in a data structure or framework. You defer the question "HashMap or database?" until design, so it doesn't contaminate your understanding of the domain. Two guiding principles run through both phases: assign each responsibility to the object that owns the relevant data (GRASP Information Expert), and model relationships to reflect real lifecycles (a Trip composes its Route; it merely associates with a Driver).

A concrete example

Consider the requirement: "A rider requests a trip; the system assigns an available driver and tracks the trip's status." Noun extraction gives Rider, Trip, Driver, and a coordinator Dispatcher. Verbs (request, assign) become behaviors. Applying Information Expert, the Trip owns its own status transitions; the Dispatcher owns the matching logic because only it sees the pool of drivers.

// Analysis found the concepts; design assigns responsibilities.
enum TripStatus { REQUESTED, ASSIGNED, COMPLETED, CANCELLED }

class Trip {
    private final Rider rider;
    private Driver driver;              // association: set later
    private TripStatus status = TripStatus.REQUESTED;

    Trip(Rider rider) { this.rider = rider; }

    // Information Expert: Trip owns its own state transition.
    void assignTo(Driver d) {
        if (status != TripStatus.REQUESTED)
            throw new IllegalStateException("already handled");
        this.driver = d;
        this.status = TripStatus.ASSIGNED;
    }
}

class Dispatcher {                     // Controller: coordinates the use case
    private final List<Driver> pool;
    Dispatcher(List<Driver> pool) { this.pool = pool; }

    Trip request(Rider rider) {
        Trip trip = new Trip(rider);
        Driver free = pool.stream()
            .filter(Driver::isAvailable)
            .findFirst()
            .orElseThrow(() -> new IllegalStateException("no drivers"));
        trip.assignTo(free);
        return trip;
    }
}

This applies when the problem has a rich domain with meaningful entities and rules—dispatchers, parking lots, elevators, vending machines. Notice the design choices: Trip guards its own invariant (you cannot assign an already-assigned trip), and Dispatcher is a thin coordinator, not a god object holding all logic.

When to use it, and when not

OOAD earns its cost when the domain is behavior-rich and long-lived: complex business rules, evolving requirements, multiple actors. There, the modeling discipline pays back many times over.

• vs. data-driven / anemic design: The common alternative is to model tables and put all logic in "service" classes over dumb data holders. This is faster initially and fine for CRUD apps, but as rules accumulate, logic scatters across services and no object protects its own invariants. OOAD localizes behavior with data instead.
• vs. procedural / transaction-script: A single function per use case is perfectly appropriate for simple scripts, ETL, or genuinely stateless pipelines. Objects add ceremony with no payoff when there's little state or few rules—don't force classes onto a batch job.
• vs. functional decomposition: For data-transformation-heavy work (compilers, analytics), pipelines of pure functions often model the problem better than mutable objects. Choose by asking: is the essence things with state and rules, or transformations of data?

The judgment: OOAD is not free. Over-modeling a trivial problem (a ParkingLotFactoryStrategyManager for a 10-line script) is a real failure mode. Match modeling investment to domain complexity.

The same request as a sequence diagram

The class diagram shows the static structure; the sequence diagram shows the dynamic collaboration for one use case. Follow the message arrows top-to-bottom to see who owns each decision.

• Rider initiates the goal.
• Dispatcher owns matching because it alone sees the driver pool; it asks :Driver.isAvailable().
• Trip is created by the Dispatcher and immediately owns its own status transition via assignTo(driver).
• Trip guards the invariant: if assignTo were called twice, the object itself would throw, not the Dispatcher.

This is the payoff of Information Expert: the Dispatcher does not reach into the Trip's internals to flip a status flag; it sends a message and lets the Trip enforce its own contract. If the matching rules change, only the Dispatcher changes; if the status lifecycle changes, only the Trip changes.

Pitfalls interviewers probe

• God objects: a single Manager/Controller that holds all data and logic. Interviewers watch whether you distribute responsibility (GRASP Information Expert) or centralize it.
• Anemic domain model: classes that are just getters/setters with all logic in services. They'll ask "where does the invariant live?"—the right answer is inside the object that owns the data, as Trip.assignTo guards its own status.
• Confusing association / aggregation / composition: be ready to justify why Trip-to-Driver is an association (independent lifecycles) but Trip-to-Route might be composition (route dies with the trip).
• Analysis paralysis / over-engineering: inventing patterns and abstraction layers before there's a second use case. Interviewers reward starting simple and refactoring toward patterns when a real force appears.
• Skipping clarifying questions: the strongest signal in an OOD round is asking about scope and requirements before naming classes—analysis precedes design.

Key takeaways

• OOAD bridges problem to code: analysis (what—domain concepts, tech-free) then design (how—responsibilities, interfaces, relationships).
• Model the domain, not the schema or the UI, so requirement changes localize to one place.
• Noun→class, verb→behavior is the extraction heuristic; assign each responsibility to the object that owns the data (Information Expert).
• Objects protect their own invariants—avoid god objects and anemic models where logic leaks into services.
• It's a cost-benefit call: use OOAD for behavior-rich, evolving domains; prefer transaction scripts or functional pipelines for simple, stateless, or transformation-heavy work.
• Interview edge: ask clarifying questions first, distribute responsibility, justify relationship types, and start simple—refactor to patterns only when a real force demands it.