Week 5 Cheat Sheet - Introduction to OOP

Quick reference for OOP concepts — classes, getters, JUnit, static, has-a relationships.

Thinking in Objects

Classes are nouns. Look for people, things, places, concepts in your problem description.
Each object has two flavors of responsibility: data it KNOWS, and actions it DOES.
Most classes do both. Some are pure data (Ticket); some are pure actions (static helpers).
Verbs in the problem description usually become methods, not classes.

Class Anatomy (Review)

public class Person {
    // fields (data) — private
    private String name;
    private int age;

    // constructor
    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    // getters / setters
    public String getName() { return name; }
    public void setName(String n) { this.name = n; }
}

Getter Conventions

Stored getter: reads a field directly.
Derived getter: calculates from other fields; no backing field.
Boolean: use is…() or has…(), not get…().
Anything else: use get…().

// stored
public String getName() { return name; }

// derived (no fullName field)
public String getFullName() {
    return firstName + " " + lastName;
}

// boolean
public boolean isAdult() { return age >= 18; }

Access Modifiers

public — visible to all classes anywhere.
protected — same package + subclasses elsewhere.
(no keyword) — package-private. Same package only.
private — only inside this class.

Best practice: always write the access modifier explicitly. Don't rely on the package-private default — it makes intent unclear.

Method Overloading

Same method name, different parameter list.
Compiler picks the right one based on the arguments you pass.
Constructors can be overloaded too.

public Hotel(String n, int s, int r) { ... }
public Hotel(String n, int s, int r,
              int bs, int br) { ... }

Cohesion & Coupling

Cohesion (within class): aim HIGH — everything inside belongs together.
Coupling (between classes): aim LOW — minimize who knows about whom.
Test: if you removed a method, would the class still make sense?

Anti-pattern: a class that knows about three unrelated things (payroll + dinner + weather) has low cohesion. Split it.

JUnit Testing

Test naming — 3 underscored parts

// methodUnderTest_StateUnderTest_ExpectedBehavior
checkIn_RoomInitialStatus_RoomIsOccupiedAndDirty
checkout_RoomIsOccupied_RoomIsNotOccupied
punchOut_HoursNotSet_HoursWorkedSetCorrectly

Other styles exist (e.g. shouldX_whenY). Pick one for your project — and stick with it.

Arrange / Act / Assert

@Test
public void checkIn_RoomInitialStatus_RoomIsOccupiedAndDirty() {
    // Arrange
    Room room = new Room(2, 100.0);

    // Act
    room.checkIn();

    // Assert
    assertTrue(room.isOccupied());
    assertTrue(room.isDirty());
}

Common Assertions

assertEquals(expected, actual) assertNotEquals(expected, actual) assertTrue(boolean) assertFalse(boolean) assertArrayEquals(expected, actual)

Static Members

Instance: one copy per object — this.balance.
Static: one shared copy — BankAccount.interestRate.
Static methods are called via the class name, not an instance.
Static class = all members static + private constructor (e.g. Math).

private static double // shared
        interestRate;
private double balance;     // per instance

BankAccount.setInterestRate(0.045);  // no instance needed

Has-A Relationships

One class contains instances of another — that's a has-a relationship.
Hand has-a Card. Deck has-a Card. (Hand and Deck don't directly know about each other.)
main wires them together — that's loose coupling at work.

public class Hand {
    private ArrayList<Card> cards;
    public void deal(Card card) {
        cards.add(card);
    }
}

The Testing Pyramid

Unit (most)

A single method on a single class. Milliseconds. Hundreds.

Integration

Two or more classes (or class + file/db) working together. Seconds. Dozens.

End-to-End (few)

Full user flows through the whole system. Minutes. Few.