A design pattern is a well-known, named solution to a problem that keeps coming back in software, like only one of these may exist, or add a feature without editing the class. Knowing the name lets you spot the problem faster and explain your design in one word, which is exactly what a low-level design round rewards.
This course covers the 18 patterns you will meet most often in real Python code, one session each. Every session starts from code without the pattern, shows where it hurts, then fixes it with the pattern, and ends with an example from AI apps (LLMs, RAG and agents).
Each session closes with common mistakes, hands-on exercises with solutions you can reveal, a quiz and a flash card deck. A patterns-at-a-glance page compares all 18 side by side so you can answer which pattern fits.
What is inside this course
- 18 patterns in plain words with diagrams
- Runnable Python, before and after
- An AI-app example in every session
- Exercises, a quiz and flash cards per session
- A side-by-side comparison of all patterns
Who it is for
Python developers who want cleaner, more maintainable code and to answer design questions in interviews.
What you will be able to do
- Recognise when a pattern fits
- Implement 18 patterns in Python
- Explain trade-offs between patterns
Syllabus, start to finish
4 modules, 20 chapters.
1Getting started2
- Setup
- Patterns at a glance
2Creational · how objects are made5
- Singleton patternSome things in a program should exist exactly once, the app settings, the logger, the database connection pool, the LLM client.
- Factory Method patternYour code often needs to create objects, but which class to create depends on a value that is only known at run time (a setting, a user choice, a file extension).
- Abstract Factory patternFactory Method creates one kind of object.
- Builder patternSome objects have many settings, and most are optional.
- Prototype patternSometimes creating an object from scratch is slow or complicated (loading a file, calling an API, long setup).
3Structural · how objects fit together7
- Adapter patternYou have code that expects one interface, and a library that offers a different one.
- Decorator patternYou want to add behaviour to an object or function (logging, timing, retrying, caching) without changing its code and without creating a subclass for every combination.
- Facade patternA real system is made of many small parts, each with its own setup and methods.
- Proxy patternSometimes you don't want callers to talk to the real object directly.
- Composite patternSome data is a tree, a folder holds files and other folders, a company holds departments that hold employees, a menu holds items and sub-menus.
- Bridge patternWhen a class can vary in two independent directions, inheritance explodes.
- Flyweight patternIf your program needs thousands or millions of similar objects, memory becomes the problem.
4Behavioural · how objects work together6
- Strategy patternYou have one job that can be done in several ways, and you want to switch the way without rewriting the code that uses it.
- Observer patternWhen one object changes, other objects need to know, but you don't want the first object to know who they are.
- Command patternNormally you call a method and it runs now.
- State patternSome objects behave differently depending on what state they are in, an order can be placed, paid, shipped or cancelled, and what you may do changes with each.
- Template Method patternSeveral jobs follow the same steps in the same order, but a few steps differ.
- Chain of Responsibility patternA request needs to be handled, but you don't know in advance who should handle it, or several checks must run one after another.