02 - Diagrama de clases

El diagrama de clases es un diagrama UML que representa las clases de un sistema, sus atributos y métodos, y las relaciones entre ellas. Sirve para diseñar antes de codificar, comunicar el diseño y documentar el código existente.

Una clase se dibuja como un rectángulo con tres compartimentos: nombre, atributos y métodos.

┌──────────────────────────────┐
│            Book              │
├──────────────────────────────┤
│ - id: long                   │
│ - title: String              │
│ - stockQuantity: int         │
├──────────────────────────────┤
│ + decrementStock(): void     │
│ + isAvailable(): boolean     │
└──────────────────────────────┘

La visibilidad se indica con un símbolo antes del nombre:

En PlantUML:

@startuml
class Book {
  - id: long
  - title: String
  - stockQuantity: int
  + decrementStock(): void
  + isAvailable(): boolean
}
@enduml

Una dependencia existe cuando una clase usa otra de forma puntual: recibe un objeto como parámetro, lo devuelve o lo crea. Es la relación más débil: no guarda referencias.

public class BookPrinter {
    public void print(Book book) { /* usa el objeto */ }
}

@startuml
BookPrinter ..> Book : usa
@enduml

La flecha discontinua (..>) significa *usa*. Si el diseño de Book cambia, BookPrinter puede verse afectado; leer las dependencias de un diagrama indica qué clases hay que revisar al cambiar otra.

Una asociación es una relación estable: una clase guarda una referencia a otra. La multiplicidad indica cuántos objetos participan:

@startuml
class Order
class Book

Order "1" --> "*" Book : contains >
@enduml

public class Order {
    private final List<Book> books;
}

Ambas son asociaciones de *todo-parte*:

@startuml
class Team
class Player
class Order
class OrderLine

Team o-- Player : agregación
Order *-- OrderLine : composición
@enduml

Un jugador puede existir fuera del equipo (agregación, rombo hueco o–). Una línea de pedido no existe fuera del pedido (composición, rombo relleno *–).

La herencia (generalización) conecta una subclase con su superclase; la realización conecta una clase con la interfaz que implementa. Ambas se dibujan con flecha hueca: línea continua para herencia y discontinua para interfaces.

@startuml
interface Repository
class BookRepository

class Entity
class Book

Entity <|-- Book
Repository <|.. BookRepository
@enduml

public class Book extends Entity implements Repository { /* ... */ }

Las dependencias indican el impacto de un cambio: cuantas más clases dependen de una, más cuidado exige modificarla. Esta idea reaparece en las pruebas de arquitectura con ArchUnit, que comprueban automáticamente esas reglas en el código.