Strategy Pattern Class Diagram
The code
classDiagram
class PaymentGateway {
+charge(amount) Result
}
class StripeGateway {
+charge(amount) Result
}
class PaypalGateway {
+charge(amount) Result
}
class CheckoutService {
-PaymentGateway gateway
+processOrder(order) Result
}
StripeGateway ..|> PaymentGateway
PaypalGateway ..|> PaymentGateway
CheckoutService --> PaymentGateway
How this template works
This diagram shows the strategy pattern in the shape you will actually meet in a codebase. CheckoutService needs to charge money, but it should not know whether the money moves through Stripe or PayPal. The PaymentGateway class defines the contract, two concrete gateways realize it, and the service holds a reference to the abstraction. Adding a third provider becomes a one-class change, and this file is how you document that promise.
Each class block names a type and lists its members between curly braces. The + prefix marks a public member and - marks a private one, so -PaymentGateway gateway inside CheckoutService reads as a private field typed as the interface. Members with parentheses are methods and members without them are attributes, which is how Mermaid decides where to render each one. The relationship lines carry the pattern: StripeGateway ..|> PaymentGateway is realization, the dashed arrow with a hollow triangle that means implements, and it always points from the implementer to the interface. CheckoutService --> PaymentGateway is a plain directed association, the visual shorthand for the service holding a reference it calls into.
The gotcha is arrow direction. Writing PaymentGateway ..|> StripeGateway flips the meaning and documents that the interface implements the concrete class, which will confuse every reader who trusts the picture. Class names must also be unique across the file; two blocks with the same name merge into one node with all members combined, which silently hides a duplicate definition.
To reuse the pattern, rename the domain — exporters, notification channels, storage backends — and keep the same three relationship lines. If you add a factory that picks a gateway at runtime, draw it with a plain association to the interface and the diagram still tells the truth.
Related templates for deeper reading: the inheritance hierarchy class diagram for solid inheritance arrows, the domain model class diagram for data-centric schemas, and the API SDK class diagram for layering a client library. The class diagram guide covers the full notation.
Variations to try
- Add a third gateway such as a mock implementation used in tests to show how easily the set grows.
- Add a factory class with a create method that returns the chosen gateway at runtime.
- Rename the domain to fit your own pluggable component such as exporters or notification channels.
