Class Relationships & UML for Machine Coding

A machine-coding round rewards the candidate who spends the first sixty seconds sketching before typing. A single UML class box forces you to name the entity, decide what state it owns, and list the operations it exposes — three decisions you would otherwise make badly while already deep in syntax.

Every class in UML is drawn as one box split into three horizontal compartments:

class Account {
    private String id;
    private long balanceCents;

    public void deposit(long cents) { balanceCents += cents; }
    private void audit() { /* internal only */ }
}

The box for Account reads top to bottom like this:

• Top compartment: the class name, Account, on its own.
• Middle compartment: the fields, - id: String and - balanceCents: long.
• Bottom compartment: the methods, + deposit(cents: long) and - audit().

The leading symbol is the visibility marker: + means public, - means private, and # means protected. So + deposit is callable by anyone, while - audit is internal. Reading a box, you learn an entity's whole contract at a glance — its name, its state, and the operations outsiders may invoke — without scrolling through an implementation. That is why the sketch beats diving straight into code: it makes you commit to responsibilities and encapsulation up front, where they are cheap to change.