Design patterns are typical solutions to commonly occurring problems in software design. They are like pre-made blueprints that you can customize to solve a recurring design problem in your code.
Each pattern has its own folder containing a README.md explaining the problem it solves, and one subfolder per
language holding a runnable implementation with tests.
patterns provide object creation mechanisms that increase flexibility and reuse of existing code.
patterns explain how to assemble objects and classes into larger structures, while keeping the structures flexible and efficient.
patterns take care of effective communication and the assignment of responsibilities between objects.
See Behavioral/README.md for a comparison of the patterns that are easiest to confuse with each other — Strategy vs. State, Mediator vs. Observer, and so on.
<Category>/<Pattern>/
├── README.md problem, structure, how to implement, real-world example
├── assets/ diagrams (Creational and Structural)
├── php/ PHP implementation
│ └── Tests/
└── go/ Go implementation, with _test.go alongside
The Behavioral patterns are implemented in Go, as one package per pattern under a single module.
go test ./...Go is not required locally — the toolchain runs fine in a container:
docker run --rm -v "$PWD:/app" -w /app golang:1.23-alpine go test ./...The Creational and Structural patterns are implemented in PHP and tested with PHPUnit.
composer install
composer test| Category | Patterns | Language |
|---|---|---|
| Creational | 5 / 5 | PHP |
| Structural | 7 / 7 | PHP |
| Behavioral | 11 / 11 | Go |
Go implementations of the Creational and Structural patterns, and PHP implementations of the Behavioral ones, are not
written yet — the php/ and go/ layout is in place for both.