Real-World OOP Examples

Model the nouns that the business actually reasons about and give each one the behaviour that belongs to it alone. Here a Book owns its title and price, and a Catalogue owns the collection and the operations on that collection: adding, counting, valuing and finding. The catalogue is the object that knows what a library is for, and it does not leak its internal list to callers.

public class Main {
    public static void main(String[] args) {
        Catalogue catalogue = new Catalogue();
        catalogue.add(new Book("Effective Java", 45.0));
        catalogue.add(new Book("Clean Code", 38.5));
        System.out.println(catalogue.count());
        System.out.println(catalogue.totalValue());
        System.out.println(catalogue.find("Clean Code"));
    }
}

class Catalogue {
    private final java.util.List<Book> books = new java.util.ArrayList<>();
    void add(Book book) { books.add(book); }
    int count() { return books.size(); }
    double totalValue() {
        double sum = 0;
        for (Book b : books) { sum += b.price(); }
        return sum;
    }
    String find(String title) {
        for (Book b : books) {
            if (b.title().equals(title)) { return "found: " + b.title(); }
        }
        return "not found";
    }
}

class Book {
    private final String title;
    private final double price;
    Book(String title, double price) { this.title = title; this.price = price; }
    String title() { return title; }
    double price() { return price; }
}

The output shows the split working: two books, a total value of 83.5, and a lookup that reports found: Clean Code. Each of those answers comes from a different object, and none of them required the caller to know how the catalogue is stored internally.

The line between a class and a plain set of fields is drawn by behaviour, not by shape. If a group of values is only ever passed around and printed, keep it as fields on the object that owns it. If it has rules, if it needs to be validated, or if it is referred to in several places in the language of the business, it deserves to be a class of its own. Book earns its place the moment price rules start to vary; a string field for the author might not.

The final check, and the one to mention in an interview, is whether the names match how the business talks. If your classes need a glossary to explain them, the model is probably not yet aligned with the domain.

Look for the things that the business has a vocabulary for. If people who work in the domain use a specific noun and disagree about it, that noun is probably a class. Orders, invoices, shipments and subscriptions are all things an organisation tracks, argues about and needs history for. A display label is not, and giving it a class usually produces noise.

Second test: does the thing have identity? If two instances with identical contents still need to be told apart, referred to, tracked or given a lifecycle, it is an entity and deserves a class. A value such as a money amount or a date range can be compared by content and usually belongs as fields rather than as a separate object with identity.

Third test: does the thing own behaviour, or does it own rules? Behaviour that belongs to one concept should sit with that concept. If the business says a discount applies to a line item under certain conditions, that logic belongs to the line item or to a discount policy that the item consults, not to the order that happens to contain it.

Finally, model only what you need. Every class is a promise about the future, and speculative classes get built on assumptions that the domain later contradicts. Start with the smallest set of classes that expresses the behaviour you are about to implement, and let the model grow when a real requirement arrives. In an interview, mentioning that classes are hypotheses about the domain, and that cheap revision is a design goal, tends to land well.