This repository is part of the Refactoring.Guru project.
It contains PHP examples for all classic GoF design patterns.
Each pattern includes two examples:
-
Conceptual examples show the internal structure of patterns, including detailed comments.
-
RealWorld examples show how patterns can be used in real-world PHP applications.
These examples require PHP 7.3 and newer, although they can be easily replicated in older versions of PHP.
This version provides explicit argument and return type declarations, which help to understand better some patterns' features that are not very obvious in dynamically typed language.
All examples can be launched via the command line, using the PHP executable as follows:
php src/Path-to-example/index.php
For the best experience, I recommend working with examples with these IDEs:
- Memento: RealLife
- State: RealLife
I'm out of decent ideas for real-world usages for these two in PHP apps. If you had used them in your project, feel free to suggest me an idea by posting an Issue.
Client means client of classes, defined as part of a pattern, which is merely a caller of the given methods or a user of the given classes. In other words, it's the part of your application's code that uses the pattern's classes.
Take a look at the conceptual example first. There you'll find detailed descriptions of each class in a pattern, its role, and connection to other classes.
I appreciate any help, whether it's a simple fix of a typo or a whole new example. Just make a fork, make your change and submit a pull request.
Here's a style guide which might help you to keep your changes consistent with the rest of the project's code:
-
All code should match the PSR2 coding style guide
-
Try to hard-wrap the code at 80th's character. It helps to list the code on the website without scrollbars.
-
Examples should match following namespace convention: RefactoringGuru\{pattern-name}\{example-name}. For instance:
<?php namespace RefactoringGuru\FactoryMethod\Example\Buttons; class Button { ...
-
Aim to put all code within one file. Yes, I realize that it's not how it supposed to be done in production. However, it helps people to understand examples better, since all code fits into one screen.
-
Comments may or may not have language tags in them, such as this:
/** * EN: All products families have the same varieties (MacOS/Windows). * * This is a MacOS variant of a button. * * RU: Все семейства продуктов имеют одни и те же вариации (MacOS/Windows). * * Это вариант кнопки под MacOS. */
This notation helps to keep the code in one place while allowing the website to generates separate versions of examples for all listed languages. Don't be scared and ignore the non-English part of such comments. If you want to change something in a comment like this, just do it. Even if you do it wrong, we'll tell you how to fix it during the Pull Request.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Authors: Alexander Shvets (@neochief) and Alexey Pyltsyn (@lex111)