PlantUML Class Diagram: Design Patterns
Document GoF design patterns with PlantUML class diagrams. Covers Observer, Strategy, Factory, and Singleton patterns with complete examples.
Detailed Explanation
Design Patterns in PlantUML Class Diagrams
PlantUML class diagrams are the standard way to document design patterns. Each pattern has a characteristic structure that becomes immediately recognizable in diagram form.
Observer Pattern
@startuml
interface Observer {
+update(event: Event): void
}
abstract class Subject {
-observers: List<Observer>
+subscribe(o: Observer): void
+unsubscribe(o: Observer): void
+notify(event: Event): void
}
class EventBus extends Subject {
+publish(topic: String, data: any): void
}
class Logger implements Observer {
+update(event: Event): void
}
class MetricCollector implements Observer {
+update(event: Event): void
}
Subject o-- Observer
@enduml
Strategy Pattern
interface SortStrategy {
+sort(data: List): List
}
class QuickSort implements SortStrategy
class MergeSort implements SortStrategy
class BubbleSort implements SortStrategy
class Sorter {
-strategy: SortStrategy
+setStrategy(s: SortStrategy): void
+doSort(data: List): List
}
Sorter --> SortStrategy
The Strategy pattern uses a --> association from the context to the strategy interface, with concrete strategies implementing the interface.
Factory Method Pattern
abstract class Creator {
+{abstract} createProduct(): Product
+doSomething(): void
}
interface Product {
+use(): void
}
class ConcreteCreatorA extends Creator {
+createProduct(): Product
}
class ConcreteProductA implements Product
ConcreteCreatorA ..> ConcreteProductA : creates
The dashed dependency arrow (..>) with "creates" label shows the factory relationship clearly.
When to Use Each Arrow
The key to readable pattern diagrams is using the correct arrow type. Inheritance (<|--) for "is-a", composition (*--) for "has-a and owns", association (-->) for "uses", and dependency (..>) for "creates or depends on temporarily".
Use Case
Teaching design patterns to junior developers, documenting architectural decisions in ADRs, reviewing proposed designs in pull requests, and creating reference materials for coding standards.