Class Diagram

Imagine you're about to build a complex feature, like a new order management system. You have a team of developers, and you need to ensure everyone has a shared understanding of the core components: What are the main entities? What data do they hold? How do they relate to each other?

If you just start coding, each developer might have a slightly different mental model. This leads to integration problems, duplicated logic, and a system that's hard to understand and maintain. You need a blueprint.

A Class Diagram is that blueprint. It's a static, structural diagram in the Unified Modeling Language (UML) that describes the structure of a system by showing its classes, their attributes, operations (or methods), and the relationships among them. It is the most common and foundational diagram for Low-Level Design.

For an interview, being able to quickly sketch a Class Diagram on a whiteboard is a critical skill. It demonstrates that you can think about the structure of a system in a formal, standardized way before you start writing code.

Core Components of a Class Diagram

A class in a UML diagram is represented by a rectangle divided into three compartments:

1. Top Compartment: Contains the name of the class. It should be centered and in bold.
2. Middle Compartment: Contains the attributes (or fields) of the class.
3. Bottom Compartment: Contains the operations (or methods) of the class.

Visibility

Each attribute and operation has a visibility marker, which specifies its access level:

• + Public: Accessible from any other class.
• - Private: Accessible only within the class itself.
• # Protected: Accessible within the class and its subclasses.
• ~ Package Private: Accessible only by classes in the same package.

Relationships

Class Diagrams supports various types of relationships between classes. Here are the most common ones:

1. Association

An association represents a relationship between two or more classes. It's a "has-a" relationship. It can be bi-directional (without arrows) or uni-directional (with arrows). For example, a User "has a" ShoppingCart.

• Multiplicity: This defines how many instances of one class are linked to one instance of the other class.
  • 1: Exactly one
  • *: Many (zero or more)
  • 0..1: Zero or one
  • 1..*: One or more

2. Aggregation & Composition (Special Associations)

Both are special associations that represent a "whole-part" relationship, but they have a difference in their lifecycle dependency.

• Aggregation (Shared): A weaker "has-a" relationship where the "part" can exist independently of the "whole". For example, a Department has Professors, but if the Department is closed, the Professors still exist. It's depicted with an unfilled diamond.

• Composition (Owned): A stronger "has-a" relationship where the "part" cannot exist without the "whole". If the "whole" is destroyed, the "part" is also destroyed. For example, a House is composed of Rooms. If you demolish the House, the Rooms cease to exist. It's depicted with a filled diamond.

3. Inheritance (Generalization)

An "is-a" relationship. One class (the subclass or child) inherits from another class (the superclass or parent). For example, a Car is a type of Vehicle. It's depicted with a solid line and a hollow arrowhead pointing to the superclass.

4. Realization (Implementation)

A relationship between a class and an interface, where the class implements the operations specified by the interface. For example, a Car class might implement the Drivable interface. It's depicted with a dashed line and a hollow arrowhead pointing to the interface.

Example: E-Commerce System

Let's put it all together to model a simple e-commerce system.

Requirements:

• A Customer can have one ShoppingCart.
• A ShoppingCart can contain multiple LineItems.
• Each LineItem is associated with exactly one Product.
• A Customer places an Order.
• An Order is composed of the LineItems from the cart at the time of purchase.
• CreditCardPayment and PayPalPayment are different types of Payment methods.

This diagram clearly communicates the static structure of the system. Any developer can look at this and understand the core entities, their properties, and how they relate to one another before a single line of code is written. It's a powerful tool for communication and design clarity.