Object relationships: interview questions & scenarios

Model answer

Is-a is inheritance: SavingsAccount extends Account, so a savings account can be used anywhere an account is expected. Has-a is composition: Checkout holds a PaymentGateway in a field and calls it.

I prefer composition by default. It depends only on the collaborator's public interface, can be swapped at runtime or in tests, and doesn't inherit implementation details. I use inheritance when the subclass is a true subtype and the parent was designed to be extended.

Model answer

All three are has-a relationships, ordered by how tightly the lifecycles are bound:

• Association: objects know or use each other, with independent lifecycles. A Doctor and a Patient.
• Aggregation: a whole groups parts that are shared and can outlive it. A Team and its Players. UML: hollow diamond at the whole.
• Composition: the whole owns its parts exclusively; they are created by it and die with it. An Order and its OrderLines. UML: filled diamond at the whole.

This diagram is the picture I want in your head: the field shape may look similar, but lifecycle and sharing decide the relationship.

Fig. 1

Association, aggregation and composition are separated by lifecycle ownership and sharing rules.

Model answer

LSP says objects of a subtype must be usable wherever the parent type is expected, without breaking the parent's promises. A subclass may accept more and guarantee more, never require more or deliver less.

class Account {
    void withdraw(BigDecimal amount) { /* debit */ }
}
class FixedDepositAccount extends Account {
    @Override void withdraw(BigDecimal amount) {
        throw new UnsupportedOperationException("locked until maturity");
    }
}

It compiles, the sentence "a fixed deposit is an account" sounds right, and any caller that does account.withdraw(rent) breaks when given a FixedDepositAccount. Better: a Withdrawable interface that only some account types implement.

Model answer

When three things are true: the subclass is a true subtype under LSP, the parent was designed and documented for extension (it documents self-use, exposes protected hooks, and does not call overridable methods from its constructor), and you own both classes so they change together.

Good fits: AbstractList-style skeletal implementations, exception hierarchies, a template method where a final method fixes the algorithm and subclasses fill in steps, and sealed hierarchies with a closed set of subtypes. If a class is not designed for extension, make it final.

Model answer

class TrackedSkuSet extends HashSet<String> {
    int added = 0;
    @Override public boolean add(String s) { added++; return super.add(s); }
    @Override public boolean addAll(Collection<? extends String> c) {
        added += c.size();
        return super.addAll(c);
    }
}

var s = new TrackedSkuSet();
s.addAll(List.of("A", "B", "C"));
System.out.println(s.added);   // 6

HashSet inherits addAll from AbstractCollection, which loops and calls add(e) on this. That's an invokevirtual, so it dispatches to the override in TrackedSkuSet, and each element is counted twice: 3 in addAll, then 3 more in add.

Here is the dispatch path that causes the double count.

Fig. 1

The inherited addAll method calls add on this, so virtual dispatch lands back in the subclass override.

Model answer

By controlling how part references are created and exposed:

1. The whole creates its parts. order.addLine(sku, qty, price), not order.addLine(lineObjectFromOutside).
2. Nothing mutable escapes. Return Collections.unmodifiableList(lines) or List.copyOf(lines), and make parts immutable, like record OrderLine(...), or return copies.
3. Mutations go through the whole. order.changeQuantity(sku, 3), so the whole can re-check invariants like "total must be positive".

Model answer

This smells like representation exposure. The service probably returned its internal List<OrderLine> or mutable OrderLine objects, so another part of the code changed quantity or price without going through Order. The aggregate's invariant checks were bypassed.

I would inspect the getter first, then search for mutations on the returned list or line objects. The fix is to keep the list private, expose List.copyOf(lines), make OrderLine immutable, and provide intention-revealing methods like changeQuantity(sku, qty) that revalidate the order.

Model answer

If the link carries no data, two Set fields with helpers that keep both sides in sync:

void addPatient(Patient p) { if (patients.add(p)) p.addDoctor(this); }
void addDoctor(Doctor d)   { if (doctors.add(d)) d.addPatient(this); }

Set.add returns false the second time, which stops the recursion. In practice the link almost always has data: date, reason, fee. I would make it an association class: record Appointment(Doctor doctor, Patient patient, LocalDateTime at), stored in a repository. Doctor and Patient no longer reference each other, and the many-to-many becomes two one-to-many links, the same shape as a join table.

Model answer

The likely cause is a cycle in the object graph: Doctor has patients, each Patient has doctors, and the serializer walks both directions until the stack blows. The same problem appears in generated toString, equals or hashCode if they include back-pointers.

I would confirm from the stack trace: repeated serializer frames alternating between Doctor and Patient. The fix is to remove one direction if we do not need it, serialize DTOs instead of entities, or configure the serializer with managed/back references, identity references, or ignored fields.

Model answer

No collector understands "composition" or "aggregation" as domain concepts. HotSpot traces from GC roots: thread stacks, static fields, JNI handles and similar. Anything reachable stays alive.

A non-static inner listener has a hidden reference to its outer instance (this$0). If that listener is stored in a static list, event bus, scheduler, or long-lived cache, it keeps the outer OrderService reachable too. That can retain repositories, caches and recent order graphs long after the request is done.

Model answer

Pricing is behaviour that varies independently of the ticket, so it should not be a subclass. I would give Ticket a PricingStrategy field, for example Money price(Duration parked, VehicleType type), and implement hourly, daily, weekend, member discount and EV charging rules separately.

Subclassing multiplies with every new dimension: WeekendMemberEvTicket, DailyMemberEvTicket, and so on. With composition, a new rule is one class, and decorators or a rule pipeline combine them at runtime.

Model answer

I would suspect a fragile base class bug. The subclass overrides methods like add, put or record, while the parent implementation calls those methods internally. After the library upgrade, a new parent method path may call the override more often, or skip it entirely.

The first check is the stack trace or profiler sample around the counter increment. If the call enters super.addAll and then re-enters the subclass's add, it is the same self-use problem as the HashSet example. The fix is not to chase every parent method; wrap the collection behind a narrow interface and count at the boundary you own.

Model answer

Properties extends Hashtable<Object,Object>, so it inherits put(Object, Object). That means code can store a non-String key or value even though Properties is meant to represent string properties. Later, getProperty returns null for that key, and store() can fail because it expects strings.

This is inheritance for reuse leaking the wrong API. A better design would compose a Map<String, String> privately and expose only string-based operations. The same issue appears in Stack extends Vector: a stack accidentally exposes random access and insertion methods that violate LIFO.