design-patterns-for-humans: a Persian-language pattern guide

A repository that ships a README and an images folder, nothing else

The whole project lives in two top-level entries: README.md and images/. There is no package manifest, no build script, no test suite, no dependency file and no continuous integration configuration. The poster referenced at the top of the guide lives under images/poster.png. That shape matters for the first decision any adopter has to make, because there is no install step to follow and no artifact to add to a project. You read it.

The README also states where the text comes from. It names rommel-sunga/design-patterns-for-humans-python as the main source and describes it as a Python-flavored version of kamranahmedse/design-patterns-for-humans, and it adds that the translation draws definitions and examples from various Persian and English sources. The default branch is master, and no homepage is registered. So this repository sits downstream of two upstream guides and presents itself as the Persian edition. The upstream names are given here because the guide itself attributes them; the code examples you see are arranged for this text, not shipped as a module you can import.

Every pattern follows the same five-part template

The guide runs each pattern through an identical structure, which is what makes it usable as a reference rather than a read-through. The order is fixed: a real-world example first, a plain-language explanation second, the Wikipedia definition with a Persian translation third, the code in ten languages fourth, and a closing box on when to apply the pattern, where it does not fit, and how it differs from similar patterns.

That fifth part is the one that carries the most editorial weight. A pattern reference that only shows code leaves the reader to work out fit; a pattern reference that only explains theory leaves nothing to copy. Here the two are pinned together, and the audience is stated in the introduction: readers who already know object orientation, meaning classes, objects, inheritance and interfaces, and who want the material without the dryness of university texts, from beginners up to people who only want a quick review.

A quick-list table at the top of the guide collects every pattern with a direct anchor link, grouped by family, so the text also works as a lookup table. The introduction suggests using it that way, more like a dictionary than a curriculum.

The prose is Persian, the code sample count is ten

The document is laid out right to left, and the pattern names are given in Persian with their English equivalents attached, so English-reading developers can still navigate it. The Wikipedia definition of a design pattern is reproduced and translated, which is the closest thing the guide has to a formal anchor: it quotes the definition in Persian translation and credits Wikipedia for the wording.

The code is where the language spread happens. Each pattern is shown in Python, JavaScript, TypeScript, Java, C#, PHP, Go, C++, Kotlin and Dart, and the guide tells the reader to open the tab for their own language. Ten languages is far more than most pattern guides carry, and it changes the reading experience. Rather than arguing abstractly about a pattern, you see the same structure instantiated across very different type systems, so you can tell which parts of the pattern depend on a language feature and which parts are the pattern itself.

One caveat is worth stating plainly. The code is embedded in the document text rather than existing as files in the repository, and the top-level listing confirms that only README.md and images/ are present. Copying a snippet means copying from prose, which makes it easy to lose indentation or a closing brace, and it gives you no test to run against.

SOLID is taught before the first creational pattern

The guide puts a full chapter on the five SOLID principles ahead of the pattern catalogue, and the ordering is defended in the text. The stated reason is that the principles are the alphabet of clean code, and that they help you write code that stays easy to change instead of turning into a tangled plate of pasta.

Each principle gets a golden-rule line and a real-world anchor. Single Responsibility Principle uses a Swiss army knife against a toolbox: if the saw breaks, you should not lose the screwdriver, which is why a repository, an email service and a logger should be separate classes. Open/Closed Principle uses a game console, where a new title arrives as a disc rather than as new wiring, and maps onto a hypothetical Bitcoin payment that should be a new class rather than another branch in a payment service. The chapter then continues into Liskov Substitution and the remaining principles.

The three families are defined in the same breath. Creational patterns concern making objects, structural patterns concern how classes and objects are arranged together, and behavioral patterns concern how objects talk to each other and share out the work. Readers who come from the upstream guides will recognise the structure, and readers who do not get a vocabulary and a taxonomy in the same pass.

The guide spends real space telling you not to force a pattern

A warning block sits near the top of the document, and it is not boilerplate. The bullets state that design patterns are not a solution for every problem, that you should not go looking for reasons to use them, and that using a pattern in the wrong place turns into a disaster rather than a rescue. The line that summarises it is that patterns are a solution to a problem, not a way to find a problem.

This is the most transferable content in the repository, and it is also the part most likely to be missed if you only skim. A guide that names 24 patterns creates an obvious temptation: when a project feels awkward, look for a pattern name that fits. The guide is arguing the other direction. Its recommendation is to treat the catalogue as a dictionary you consult when you are already stuck on a specific problem.

For the wrong-tool case, think about a team whose members are still learning object orientation. The guide explicitly targets readers who already know classes, objects, inheritance and interfaces, and it goes out of its way to explain the SOLID principles first. Handing a beginner the pattern chapters without the principles would be handing them vocabulary before grammar. The other wrong-tool case is the reader who needs a specific language reference, since the code samples are illustrations of a structure rather than complete, runnable programs with error handling and tests.

Coverage: 6 creational, 7 structural, 11 behavioral

The catalogue inventory is worth spelling out because it tells you what the guide will and will not cover. The creational group holds six entries: Simple Factory, Factory Method, Abstract Factory, Builder, Prototype and Singleton. The structural group holds seven: Adapter, Bridge, Composite, Decorator, Facade, Flyweight and Proxy. The behavioral group is the largest with eleven: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, Visitor, Strategy, State and Template Method. The SOLID chapter adds five more topics to the table of contents, so the quick list covers 29 links in total.

The distribution tells you the emphasis. Behavioral patterns get nearly twice the space of creational ones, which matches the way most working code bases accumulate coupling between objects, but it also means the creational coverage, including the three factory-flavoured entries that beginners often confuse with each other, is the thinner half. The template's closing box is where those distinctions are supposed to be settled, since each pattern is meant to state how it differs from similar patterns.

What is not on the list is as telling. There is no chapter on architectural patterns, no CQRS or event sourcing material, and no GoF reference table with the original authors or intents. The document stays inside the classic catalogue, so it will not answer questions about patterns that postdate the Gang of Four book.

Last push 2026-09-26, no releases, and no stated licence

The repository is not archived, and the last push was on 2026-09-26. The repository has no GitHub releases, so there is no versioned artifact, no changelog and no upgrade path to follow. In practice that matters little here, because there is nothing to install and nothing to depend on. Keeping a copy up to date means refreshing the markdown, and applying a correction means editing text and submitting a change by hand.

Licence is the real open question. The repository listing shows README.md and images/ and no licence file, and the project metadata records the licence as unknown. A translated and rewritten document that quotes Wikipedia and adapts example code from two upstream projects has permission questions in more than one place, and the answer is not written down anywhere in the files. The Wikipedia attribution for the definition suggests the licence question was at least partly considered, but attribution is not the same as a grant.

Treat that as a boundary rather than a defect. Reading, linking and citing the guide costs nothing. Copying its code snippets into a proprietary codebase, or redistributing the text, asks questions that only the upstream projects and the missing licence file can answer.

Editorial conclusion

Adopt this guide if you read Persian and want one place that covers SOLID plus 24 classic patterns with side-by-side code in ten languages; it costs nothing and needs no install. Do not adopt it as a pattern catalogue in English, as a quick reference for a specific language, or as a source you can paste code from, because the licence is not stated and the upstream repositories are separate. Before using anything from it, check the licence in the upstream repository you intend to copy from, and confirm the two upstream projects named in the README still match the version you are reading.

Frequently asked questions

Official sources

1. 3lf/design-patterns-for-humans on GitHub
2. Issues
3. README