Class Diagram

The UML picture of a design at rest: the classes, what they hold and do, and how they relate. In an LLD interview it is the main thing you draw.

Overview

A class diagram shows the static shape of a design: which classes exist, what data and operations each one has, and how they connect. It does not show time or order; that is what sequence and state diagrams are for. The notation comes from UML 2.5.1, published by the Object Management Group in December 2017; the symbols and arrowheads below follow that specification, and the interview advice is our own.

In a low level design interview, the class diagram is your primary artifact. It turns a vague prompt such as 'design a library system' into named classes with clear responsibilities, and it gives the interviewer something concrete to question. The rest of the interview usually follows its lines: each relationship becomes a field, each operation becomes a method, and each hard question is about one arrow.

The class box

A class is a rectangle split into compartments. The name is at the top; the attributes compartment comes next and the operations compartment below it. The attribute and operation compartments can be left out. An abstract class is shown with its name in italics, and an interface uses the same box with the keyword «interface» above the name.

+ — public — any class may use it
- — private — only the class itself
# — protected — the class and its subclasses
~ — package — classes in the same package

An attribute is written as visibility, name, a colon and the type, for example -balance: Decimal. An operation adds a parameter list and a return type, for example +withdraw(amount: Decimal): bool.

The six relationships

Every line between two boxes means something specific. Get the arrowheads right; interviewers notice.

Association — solid — none, or an open arrow for direction — one object knows about another — a field holding a reference
Aggregation — solid — hollow diamond at the whole — has-a; the part lives on without the whole — a field set from outside (passed in)
Composition — solid — filled diamond at the whole — owns-a; the part dies with the whole — a field created inside the whole
Generalization — solid — hollow triangle at the parent — is-a; a subclass — extends, or a subclass declaration
Realization — dashed — hollow triangle at the interface — implements a contract — implements, or an abstract base class
Dependency — dashed — open arrow at the supplier — uses briefly (a parameter, a local, a return type) — no field; the type appears in a method

Multiplicity

A number at the end of an association says how many objects can sit at that end. Read it from the far side: 'a Member holds 0..* Loans; a Loan belongs to exactly 1 Member.'

1 — exactly one — a single reference, never null
0..1 — optional — a nullable reference
0..* or * — any number — a list or set, possibly empty
1..* — at least one — a non-empty list, checked in the constructor
2..4 — a bounded range — a list with a validated size

From diagram to code

The translation is mechanical, which is why the diagram is worth drawing first: it makes the fields, constructors and method signatures fall out.

attribute with a type — a field
operation — a method with that signature
generalization arrow — a subclass
realization arrow — implementing the interface or abstract base
association, multiplicity 1 — a reference field
association, multiplicity many — a collection field
composition (filled diamond) — the whole creates the part in its constructor
aggregation (hollow diamond) — the part is created elsewhere and passed in

Drawing one in an interview

Work from the requirements to the boxes, and only then to the lines and members. A diagram that has the relationships right with few members beats one with every getter drawn.

What you will be able to do

Draw a class box with correct visibility symbols and read one written by someone else.
Choose the right line and arrowhead for each of the six relationships and defend the choice.
Translate a class diagram into code, and code into a diagram, without losing a relationship.
Sketch the core classes of a design problem in the first ten minutes of an interview.

Interview questions

What is the difference between aggregation and composition, and how does each look in code?
How do you show an interface, an abstract class and the Strategy pattern on a class diagram?
Translate this class diagram into code.
What should you include and what should you leave out of an interview class diagram?
When is a line a dependency rather than an association?