Requirements to Object Models

The Biggest Mistake Beginners Make

Most beginners think:

Classes are containers of data.

Example:

class Customer
{
    string name;
};

class Order
{
    int id;
};

Professionals think differently.

They think:

Objects Have Responsibilities

The Fundamental Principle

Objects exist to:

Manage Information
Perform Behavior

Not merely store data.

Bad:

class Customer
{
public:

    string name;
    string email;
};

Question:

What does Customer do?

Nothing.

It is just a data structure.

Better:

class Customer
{
public:

    void placeOrder();
    void updateProfile();
    void cancelOrder();
};

Now the object has responsibilities.

Object-Oriented Design Starts With Responsibilities

Professional designers ask:

What responsibilities exists?

Before asking:

What classes exist?

Why?

Because classes emerge from responsibilities.

Example:

Requirement:

Customer places order.

Responsibility:

Place Order

Potential Object:

Customer

Requirement:

Payment must be processed.

Responsibility:

Process Payment

Potential object:

PaymentService

Noun Analysis

One of the oldest object discovery techniques.

Idea

Read requirements.

Extract nouns.

Example:

Customer places an order containing products.

Nouns:

Customer
Order
Product

Potential classes:

class Cutomer {}
class Order {}
class Product {}

Very simple.

But only a starting point.

Example: Library System

Requirement:

Members borrow books from the library.

Nouns:

Book
Member
Library

Potential classes:

class Member {};
class Book {};
class Library {};

The Problem With Pure Noun Analysis

Not every noun should become a class.

Requirement:

Customer enters email address.

Nouns:

Customer
Email
Address

Should we create:

class Email {};
class Address {};

Maybe or maybe not, depends on the domain.

This is why professional design goes beyond nound analysis.

Responsiblity-Driven Design

A powerful mindset.

Question:

Who should do this?

Instead of:

What class should exist?

Example:

Requirement:

Calculate order total.

Who owns the information?

Order contains:

Products
Quantities
Prices

Therefore:

class Order
{
public:

    double calculateTotal();
};

Why?

Because Order has the information.

Information Expert Principle

One of the most important OO principles.

Definition:

Assign responsibility to the class that has the necessary information.

Example:

Who calculates order total?

Customer?

No

Payment?

No

Order?

Yes

Order owns:

Items
Prices
Quantities

Therefore:

class Order
{
public:

    double calculateTotal();
};

This principle prevents bad designs.

Example: ATM

Requirement:

Check Account Balance

Who knows balance?

Account

Not:

ATM
Customer
Card

Good design:

class Account
{
public:

    double getBalance();
};

CRC Cards

One of the most useful object design techniques.

CRC stands for:

Class
Responsibilities
Collaborators

Invented to help discover object models.

Each class is represented as:

+---------------------------+
| Class Name                |
+---------------------------+
| Responsibilities          |
+---------------------------+
| Collaborators             |
+---------------------------+

Example: Customer CRC

+--------------------------+
| Customer                 |
+--------------------------+
| Place Order              |
| Update Profile           |
| View Orders              |
+--------------------------+
| Order                    |
+--------------------------+

Example: Order CRC

+--------------------------+
| Order                    |
+--------------------------+
| Add Product              |
| Calculate Total          |
| Track Status             |
+--------------------------+
| Product                  |
| Payment                  |
+--------------------------+

Collaborations

Objects rarely work alone.

Example:

Order Placement

Customer
    |
    v
Order
    |
    v
Payment

Question:

How do objects cooperate?

This is collaboration