Reading and drawing a class box

Part of the free Low-Level Design course on LogicWiz, in the chapter: Class diagrams you can draw in five minutes. The class-diagram exercises run in the app.

Week 3: A box that tells you what you can call

"You drew a box and wrote Cart in it. What can I call on a Cart? What am I not allowed to touch?"

Priya, at the whiteboard

Three compartments

A class diagram is a picture of classes and how they connect. It follows UML, the Unified Modeling Language: a standard set of drawing rules for software. You do not need all of UML for an interview. You need the class box and six kinds of line. This lesson covers the box.

A class box has three parts, from top to bottom:

1. Name. The class name, such as Cart.
2. Fields. The data each object holds. UML writes the field name, a colon, then the type: items: List<CartItem>.
3. Methods. What you can ask the object to do. UML writes the name, the parameters in brackets, a colon, then the return type: total(): Money.

Here is SwiftKart's cart as a box.

classDiagram
  class Cart {
    -items: List~CartItem~
    -customerId: String
    +addItem(p: Product, qty: int) void
    +removeItem(p: Product) void
    +total() Money
  }

The diagrams in these lessons are drawn with a tool called Mermaid. It writes generic types with tildes, so List~CartItem~ shows as List<CartItem>. It also shows a return type after the brackets without a colon.

Read the box in one breath: a cart holds items and a customer id, and you can add, remove and get a total. That is the job of a class box. A reader sees what an object holds and what it does, without reading any code.

Visibility: who may touch it

A member is a field or a method. The symbol before each member is its visibility: which other code may use it.

Last week's lesson shows up here. Fields are almost always -. Methods that other classes call are +. If an interviewer sees + balance: long on your diagram, they see a public field and ask how the balance stays valid. A # member exists for subclasses, so use it only when you design a class to be extended.

Static, abstract, interface and enum

Four more markings appear on boxes.

• Static members belong to the class, not to each object. For example, MAX_ITEMS: int is one value shared by every cart. UML underlines static members. Mermaid marks them with $ at the end.
• Abstract classes cannot be created with new. They exist to be extended. An abstract method has no body, and each subclass must supply one. UML writes abstract names in italics. Mermaid marks an abstract method with * at the end.
• Interfaces list methods that a class promises to provide. UML marks them with the stereotype «interface» above the name. A stereotype is a label in double angle brackets that says what kind of box this is.
• Enums list a fixed set of named values, such as order statuses. UML marks them «enumeration» and lists the values where the fields go.

classDiagram
  class PaymentMethod {
    <<interface>>
    +pay(amountPaise: long) Receipt
  }
  class Notification {
    <<abstract>>
    -orderId: String
    +send() void
    +render()* String
  }
  class OrderStatus {
    <<enumeration>>
    PLACED
    PACKED
    OUT_FOR_DELIVERY
    DELIVERED
  }
  class Cart {
    +MAX_ITEMS: int$
    -items: List~CartItem~
  }

Notice that MAX_ITEMS is public. That is fine for a constant, a static value that never changes. In Java it would be public static final int MAX_ITEMS = 50;. The "keep fields private" rule is about state that changes.

What to put in the box, and what to leave out

Arjun's first full diagram had a getter and a setter for every field, about 14 methods per class. He believed a complete diagram is a better diagram. Priya erased most of it. "I can guess the getters. Show me the methods that carry the logic."

On a whiteboard you have five to ten minutes. Write these:

• the class name and its kind: class, abstract class, interface or enum;
• the fields that hold important state, with types where they help;
• the methods other classes call, especially ones with rules inside, such as debit or isValidFor.

Leave out getters, setters, constructors and toString unless they matter to the design. A box with three meaningful methods says more than a box with fifteen routine ones.

💡 Tip: If a box needs more than about ten methods, the class probably has more than one job. Split it before you draw any further.

Your first time in the class designer

The exercises from here on use the class designer. To add a box, pick a class, interface, abstract class or enum from the palette. Click the box to edit its name and members in the side panel. Write members the way you would on a whiteboard:

• a field: - status: OrderStatus
• a static field: + static MAX_ITEMS: int
• a method: + total(): Money
• an enum value: a plain name such as PLACED

To connect two boxes, drag from the handle on the edge of one box to the other box, then pick the relationship type. The next lesson explains the six types. The designer checks your drawing as you work, and it flags problems such as a public field.

Now try it. The starter has an Order with a public status string. Make the status an enum, keep the field private, and add a PaymentMethod interface with a pay method.

📌 Summary: A class box has a name, fields and methods. Visibility is + public, - private, # protected, ~ package. Mark interfaces, abstract classes, enums and static members, and draw only members that matter.

What Arjun learns next

Arjun can draw clear boxes. Next he must connect them, and Priya says the lines matter more than the boxes. Next lesson: the six relationships and multiplicity.

Check your understanding

1. A Rider box shows `# commission: Money`. In Java, which code can use this field?
2. How does a UML class diagram show that PaymentMethod is an interface?
3. Arjun draws 14 getters and setters in every box. What does Priya advise for a whiteboard round?
4. Every cart shares one MAX_ITEMS value. How is it marked in UML?