Object‑Oriented Modeling: Concepts, Java Implementations, and Composition vs. Aggregation

The author introduces object‑oriented (OO) thinking as a way to understand and abstract the world, defining objects as the combination of attributes (properties) and methods (behaviors) that represent a thing.

Core OO concepts are highlighted: an object must consist of both attributes and methods; sometimes only attributes or only methods are needed, depending on the modeling goal.

Object Modeling vs. Data Modeling – In a relational database, tables map only to attributes, which leads to an incomplete representation compared with a full OO model that includes behavior.

Example – a simple financial Account :

create table account (
    id      integer,
    balance integer,
    status  integer
);

Java class generated from the table (data model) shows only fields:

@Getter
@Setter
public class Account {
    private int id;
    private int balance;
    private AccountStatus status;
}

When modeled as an OO interface, the full behavior appears:

public interface Account {
    int getId();
    int getBalance();
    AccountStatus getStatus();
    void open();
    void close();
    void credit(int amount);
    void debit(int amount);
}

An implementation of the interface contains the business logic, while an application service (e.g., AccountService ) merely coordinates calls:

public class AccountService {
    private final AccountRepository accountRepository;
    public AccountService(AccountRepository repo) { this.accountRepository = repo; }
    public Account creditAccount(int id, int amount) {
        var account = accountRepository.findById(id)
            .orElseThrow(() -> new AccountException("not found"));
        if (account.getStatus() != AccountStatus.OPENED) {
            throw new AccountException("not open");
        }
        account.setBalance(account.getBalance() + amount);
        return accountRepository.save(account);
    }
}

The article then shifts to the concepts of composition and aggregation . Composition describes a whole‑part relationship where the part cannot exist without the whole (e.g., a human’s mouth), while aggregation describes a looser relationship where parts can be replaced or exist independently (e.g., a car’s wheels).

To illustrate, a Java simulation of the eating process is provided, modeling Person , Mouth , Esophagus , Stomach , and Intestine as objects that collaborate to transform food:

// Mouth
public class Mouth {
    public Object chew(Object food) { return food; }
}
// Esophagus
public class Esophagus {
    public Object transfer(Object paste) { return paste; }
}
// Stomach
public class Stomach {
    public Object fill(Object paste) { return paste; }
}
// Intestine
public class Intestine {
    public void absorb(Object chyme) { /* absorbing... */ }
}
public class Person {
    private final Mouth mouth = new Mouth();
    private final Esophagus esophagus = new Esophagus();
    private final Stomach stomach = new Stomach();
    private final Intestine intestine = new Intestine();
    public void eat(Object food) {
        var paste = mouth.chew(food);
        paste = esophagus.transfer(paste);
        var chyme = stomach.fill(paste);
        intestine.absorb(chyme);
    }
}
public class PersonTests {
    public static void main(String[] args) { new Person().eat("chips"); }
}

Finally, the author mentions an open‑source multi‑tenant e‑commerce platform (Mallfoundry) built with Spring Boot, emphasizing that its domain model follows DDD and OO principles.

In summary, the piece demonstrates how adopting an object‑model mindset leads to clearer designs, distinguishes composition from aggregation, and shows practical Java code that embodies these ideas.