OOP & UML Fundamentals — Cheat Sheet

Learn UML class diagram notation — association, aggregation, composition, inheritance, and realization — with Java code equivalents for each relationship.

• ✓Composition: child is created INSIDE parent constructor and cannot exist independently — "owns-a" (filled diamond).
• ✓Aggregation: child is passed from OUTSIDE parent and can exist independently — "has-a" (hollow diamond).
• ✓Realization: a class implements an interface and provides all its methods — dashed line with open arrowhead in UML.
• ✓Multiplicity annotations on associations answer: "how many instances of B are related to one instance of A?"

// Association  : A has a reference to B, but A does not own B's lifecycle
// Aggregation  : A has-a B (hollow diamond) — B can exist without A
// Composition  : A owns-a B (filled diamond) — B is destroyed when A is destroyed
// Inheritance  : A extends B (is-a relationship)
// Realization  : A implements B (can-do capability)

Understand why has-a relationships are more flexible than is-a, illustrated by the classic Duck problem refactored with FlyBehavior Strategy.

• ✓Fragile base class: changing a parent method can silently break all subclasses that relied on the old behaviour.
• ✓Composition is more flexible: behaviours are injectable, independently testable, and swappable at runtime.
• ✓Use inheritance only for stable is-a relationships where the subclass truly is a specialisation of the parent.
• ✓This example IS the Strategy pattern: FlyBehavior is the strategy; Duck is the context; FlyWithWings is the concrete strategy.

// Problem: inheritance forces RubberDuck to deal with fly()
// Solution: extract FlyBehavior interface, compose it into Duck

Understand the differences between interface and abstract class in Java 21, when to use each, and how default methods blur the historic boundary.

• ✓Interface = capability/contract; abstract class = shared base implementation with state.
• ✓Java 8 default methods let interfaces provide implementations, but they still cannot hold instance fields or constructors.
• ✓Use the skeletal implementation pattern (AbstractXxx) to minimize the effort of implementing an interface.
• ✓A class can implement multiple interfaces but extend only one abstract class — this is the primary practical difference.

// Decision rule:
// Is-a relationship with shared state → abstract class
// Can-do capability, multiple implementations → interface
// Both needed → interface + abstract skeletal implementation (AbstractXxx)

Understand why high cohesion and low coupling are the bedrock of maintainable OOP design, with Java examples showing each extreme.

• ✓Functional cohesion: every method and field in the class exists to serve one single purpose — the gold standard.
• ✓Content coupling (worst): directly reading or writing another class's private fields — always a design smell.
• ✓Message coupling (best): a class only calls public methods on interfaces it depends on — no knowledge of internals.
• ✓The one-sentence rule: if you need "and" or "or" to describe a class, it has low cohesion and should be split.

// High cohesion: class has ONE well-defined purpose
// Low coupling: class depends on abstractions, not concrete details
// Violating either leads to fragile, untestable, hard-to-change code