Object-Oriented Modeling: Concepts, Java Implementation, and Composition vs Aggregation

Object-oriented (OO) is a way of understanding and abstracting the world by modeling objects, which consist of attributes and behaviors.

The article explains the meaning of objects, things, and how objects represent the abstraction of a thing's attributes and methods, emphasizing that OO design starts with considering both attributes and methods together.

It contrasts object models with data models: data models focus only on attributes (e.g., relational tables), while object models combine attributes and methods, leading to richer domain modeling.

An example of a simple financial account is presented. The relational table definition is shown, followed by a Java class with Lombok annotations, an interface defining getters and operations, and an implementation that manipulates the account state.

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

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

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

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

The service contains only coordination logic, illustrating the concept of an Application Service that orchestrates domain objects without embedding business rules.

Composition and aggregation are discussed as stronger and weaker whole‑part relationships. Real‑world analogies (car‑wheel, human digestion) and a Java model of the eating process (Mouth, Esophagus, Stomach, Intestine, Person) demonstrate how composition implies lifecycle dependency, whereas aggregation allows independent existence.

// Mouth class public class Mouth { public Object chew(Object food){ return food; } }

// Esophagus class public class Esophagus { public Object transfer(Object paste){ return paste; } }

// Stomach class public class Stomach { public Object fill(Object paste){ return paste; } }

// Intestine class public class Intestine { public void absorb(Object chyme){ /* absorbing... */ } }

// Person class 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); } }

The article also mentions Mallfoundry, an open‑source Spring Boot based multi‑tenant e‑commerce platform that follows DDD and OO design.

In summary, the piece advocates an object‑model mindset, demonstrates its application through an account example, and clarifies composition versus aggregation within OO design.