إسناد المسؤوليات

Written Explanation

The rule: the class with the information does the job

Ask of any behavior: which class already holds the data needed to do this? Give the job to that class. This is a well-known design guideline; in Craig Larman's GRASP set of principles it is called Information Expert, stated as: assign a responsibility to the class that has the information needed to fulfil it.

A responsibility is something a class is expected to know or to do. Loan knows its due day, so "am I overdue?" is naturally Loan's job. No other class has that information without asking Loan for it.

A useful way to find the owner is to ask the question in the first person, as an object. "Am I overdue?" sounds right from a loan. "Is this loan overdue?" asked by a manager sounds like the manager is going to look inside the loan, which is exactly what the rule wants to avoid.

The anemic alternative

Here is a design that works but puts the job in the wrong place. Loan is a data holder with a getter, and a LoanManager does the calculation.

class Loan {
    private final int dueDay;
    Loan(int dueDay) { this.dueDay = dueDay; }
    int getDueDay() { return dueDay; }
}

class LoanManager {
    int fine(Loan loan, int today) {
        int lateDays = today - loan.getDueDay();
        return lateDays > 0 ? lateDays * 25 : 0;
    }
}

With new LoanManager().fine(new Loan(14), 17) it prints 75. The result is right. The shape is the problem. Martin Fowler calls this style an anemic domain model: the classes have the names of the domain's nouns but almost no behavior, and the logic lives in separate service objects. He objects that this is procedural programming dressed as objects: the data and the behavior that works on it are separated, which is the opposite of what objects are for.

Notice the warning sign in the code: fine reaches into loan with a getter to pull out one value, then does arithmetic on it. When one class keeps asking another for its data to compute something, the computation probably belongs in the other class.

The responsible alternative

Move the arithmetic to the class that owns the due day. Loan now guards its own rule, and callers tell it what they need, as BEG-021 taught.

class Loan {
    static final int FINE_PER_DAY = 25; // cents
    private final Book book;
    private final int dueDay;
    Loan(Book book, int dueDay) { this.book = book; this.dueDay = dueDay; }
    Book book() { return book; }
    boolean isOverdue(int today) { return today > dueDay; }
    int fine(int today) { return isOverdue(today) ? (today - dueDay) * FINE_PER_DAY : 0; }
}

The getter getDueDay() has disappeared. Nobody outside needs the raw due day any more, so dueDay is not exposed. Nothing is shared except the questions a caller may ask. If the fine rule changes, one class changes.

Placing the rest of the library's behaviors

Apply the rule to each job.

The last row shows a second kind of job. Computing something from your own data goes to the owner of the data. Coordinating several objects (check the member, mark the book, create the loan, record it) belongs to a class whose job is to connect them. That is Library. It should call the others and let each make its own decision. It should not make their decisions for them.

The complete small design

import java.util.ArrayList;
import java.util.List;

class Book {
    private final String title;
    private boolean available = true;
    Book(String title) { this.title = title; }
    String title() { return title; }
    boolean isAvailable() { return available; }
    void markLent() {
        if (!available) throw new IllegalStateException(title + " is already lent");
        available = false;
    }
    void markReturned() { available = true; }
}

// Loan as above

class Member {
    static final int MAX_LOANS = 2;
    private final String name;
    private final List<Loan> loans = new ArrayList<>();
    Member(String name) { this.name = name; }
    String name() { return name; }
    boolean canBorrow() { return loans.size() < MAX_LOANS; }
    void addLoan(Loan loan) { loans.add(loan); }
}

class Library {
    Loan lend(Member member, Book book, int today) {
        if (!member.canBorrow()) {
            throw new IllegalStateException(member.name() + " has reached the loan limit");
        }
        book.markLent();
        Loan loan = new Loan(book, today + 14);
        member.addLoan(loan);
        return loan;
    }
}

Running a short main that lends Dune on day 1, asks for the fine on day 18, then lends two more books to the same member:

fine on day 18: 75
Lina has reached the loan limit

The due day is 15, three days late at 25 per day gives 75. The third lend is refused by Member, and Library simply passes on the failure.

One reason to change

Robert C. Martin states the single-responsibility principle as "a class should have only one reason to change". In practice: if the fine rate changes, one class should be affected. If the loan limit changes, one class should be affected. Loan changes when loan rules change, Member when membership rules change, Library when the steps of lending change. In the next lesson we will see what happens when one class has many reasons.

Where the rule has limits

• Two classes hold parts of the information. "Can this member borrow this book?" depends on the member's loans and on whether the book is reference-only. Do not force it into one class: ask each (member.canBorrow(), book.isAvailable()) and let the coordinator combine the answers.
• Not every job belongs in the domain classes. Printing, e-mail, and file saving are not about loans. They get their own classes. The next lesson covers that.
• The rule does not say "put everything in the biggest class". If a class starts collecting jobs that use only a little of its own data, the rule has been stretched too far.