[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-1082":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":10,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":29,"readmeContent":30,"aiSummary":31,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":32,"discoverSource":33},1082,"python-patterns","faif\u002Fpython-patterns","faif","A collection of design patterns\u002Fidioms in Python","",null,"Python",42799,7012,1589,11,0,2,15,75,10,86,false,"master",true,[26,27,28],"design-patterns","idioms","python","2026-06-12 04:00:07","# python-patterns\n\nA collection of design patterns and idioms in Python.\n\nRemember that each pattern has its own trade-offs. And you need to pay attention more to why you're choosing a certain pattern than to how to implement it.\n\n## Creational Patterns\n\n> Patterns that deal with **object creation** — abstracting and controlling how instances are made.\n\n```mermaid\ngraph LR\n    Client -->|requests object| AbstractFactory\n    AbstractFactory -->|delegates to| ConcreteFactory\n    ConcreteFactory -->|produces| Product\n\n    Builder -->|step-by-step| Director\n    Director -->|returns| BuiltObject\n\n    FactoryMethod -->|subclass decides| ConcreteProduct\n    Pool -->|reuses| PooledInstance\n```\n\n| Pattern | Description |\n|:-------:| ----------- |\n| [abstract_factory](patterns\u002Fcreational\u002Fabstract_factory.py) | use a generic function with specific factories |\n| [borg](patterns\u002Fcreational\u002Fborg.py) | a singleton with shared-state among instances |\n| [builder](patterns\u002Fcreational\u002Fbuilder.py) | instead of using multiple constructors, builder object receives parameters and returns constructed objects |\n| [factory](patterns\u002Fcreational\u002Ffactory.py) | delegate a specialized function\u002Fmethod to create instances |\n| [lazy_evaluation](patterns\u002Fcreational\u002Flazy_evaluation.py) | lazily-evaluated property pattern in Python |\n| [pool](patterns\u002Fcreational\u002Fpool.py) | preinstantiate and maintain a group of instances of the same type |\n| [prototype](patterns\u002Fcreational\u002Fprototype.py) | use a factory and clones of a prototype for new instances (if instantiation is expensive) |\n\n## Structural Patterns\n\n> Patterns that define **how classes and objects are composed** to form larger, flexible structures.\n\n```mermaid\ngraph TD\n    Client --> Facade\n    Facade --> SubsystemA\n    Facade --> SubsystemB\n    Facade --> SubsystemC\n\n    Client2 --> Adapter\n    Adapter --> LegacyService\n\n    Client3 --> Proxy\n    Proxy -->|controls access to| RealSubject\n\n    Component --> Composite\n    Composite --> Leaf1\n    Composite --> Leaf2\n```\n\n| Pattern | Description |\n|:-------:| ----------- |\n| [3-tier](patterns\u002Fstructural\u002F3-tier.py) | data\u003C->business logic\u003C->presentation separation (strict relationships) |\n| [adapter](patterns\u002Fstructural\u002Fadapter.py) | adapt one interface to another using a white-list |\n| [bridge](patterns\u002Fstructural\u002Fbridge.py) | a client-provider middleman to soften interface changes |\n| [composite](patterns\u002Fstructural\u002Fcomposite.py) | lets clients treat individual objects and compositions uniformly |\n| [decorator](patterns\u002Fstructural\u002Fdecorator.py) | wrap functionality with other functionality in order to affect outputs |\n| [facade](patterns\u002Fstructural\u002Ffacade.py) | use one class as an API to a number of others |\n| [flyweight](patterns\u002Fstructural\u002Fflyweight.py) | transparently reuse existing instances of objects with similar\u002Fidentical state |\n| [front_controller](patterns\u002Fstructural\u002Ffront_controller.py) | single handler requests coming to the application |\n| [mvc](patterns\u002Fstructural\u002Fmvc.py) | model\u003C->view\u003C->controller (non-strict relationships) |\n| [proxy](patterns\u002Fstructural\u002Fproxy.py) | an object funnels operations to something else |\n\n## Behavioral Patterns\n\n> Patterns concerned with **communication and responsibility** between objects.\n\n```mermaid\ngraph LR\n    Sender -->|sends event| Observer1\n    Sender -->|sends event| Observer2\n\n    Request --> Handler1\n    Handler1 -->|passes if unhandled| Handler2\n    Handler2 -->|passes if unhandled| Handler3\n\n    Context -->|delegates to| Strategy\n    Strategy -->|executes| Algorithm\n\n    Originator -->|saves state to| Memento\n    Caretaker -->|holds| Memento\n```\n\n| Pattern | Description |\n|:-------:| ----------- |\n| [chain_of_responsibility](patterns\u002Fbehavioral\u002Fchain_of_responsibility.py) | apply a chain of successive handlers to try and process the data |\n| [catalog](patterns\u002Fbehavioral\u002Fcatalog.py) | general methods will call different specialized methods based on construction parameter |\n| [chaining_method](patterns\u002Fbehavioral\u002Fchaining_method.py) | continue callback next object method |\n| [command](patterns\u002Fbehavioral\u002Fcommand.py) | bundle a command and arguments to call later |\n| [interpreter](patterns\u002Fbehavioral\u002Finterpreter.py) | define a grammar for a language and use it to interpret statements |\n| [iterator](patterns\u002Fbehavioral\u002Fiterator.py) | traverse a container and access the container's elements |\n| [iterator](patterns\u002Fbehavioral\u002Fiterator_alt.py) (alt. impl.)| traverse a container and access the container's elements |\n| [mediator](patterns\u002Fbehavioral\u002Fmediator.py) | an object that knows how to connect other objects and act as a proxy |\n| [memento](patterns\u002Fbehavioral\u002Fmemento.py) | generate an opaque token that can be used to go back to a previous state |\n| [observer](patterns\u002Fbehavioral\u002Fobserver.py) | provide a callback for notification of events\u002Fchanges to data |\n| [publish_subscribe](patterns\u002Fbehavioral\u002Fpublish_subscribe.py) | a source syndicates events\u002Fdata to 0+ registered listeners |\n| [registry](patterns\u002Fbehavioral\u002Fregistry.py) | keep track of all subclasses of a given class |\n| [servant](patterns\u002Fbehavioral\u002Fservant.py) | provide common functionality to a group of classes without using inheritance |\n| [specification](patterns\u002Fbehavioral\u002Fspecification.py) | business rules can be recombined by chaining the business rules together using boolean logic |\n| [state](patterns\u002Fbehavioral\u002Fstate.py) | logic is organized into a discrete number of potential states and the next state that can be transitioned to |\n| [strategy](patterns\u002Fbehavioral\u002Fstrategy.py) | selectable operations over the same data |\n| [template](patterns\u002Fbehavioral\u002Ftemplate.py) | an object imposes a structure but takes pluggable components |\n| [visitor](patterns\u002Fbehavioral\u002Fvisitor.py) | invoke a callback for all items of a collection |\n\n## Design for Testability Patterns\n\n| Pattern | Description |\n|:-------:| ----------- |\n| [dependency_injection](patterns\u002Fdependency_injection.py) | 3 variants of dependency injection |\n\n## Fundamental Patterns\n\n| Pattern | Description |\n|:-------:| ----------- |\n| [delegation_pattern](patterns\u002Ffundamental\u002Fdelegation_pattern.py) | an object handles a request by delegating to a second object (the delegate) |\n\n## Others\n\n| Pattern | Description |\n|:-------:| ----------- |\n| [blackboard](patterns\u002Fother\u002Fblackboard.py) | architectural model, assemble different sub-system knowledge to build a solution, AI approach - non gang of four pattern |\n| [graph_search](patterns\u002Fother\u002Fgraph_search.py) | graphing algorithms - non gang of four pattern |\n| [hsm](patterns\u002Fother\u002Fhsm\u002Fhsm.py) | hierarchical state machine - non gang of four pattern |\n\n## 🚫 Anti-Patterns\n\nThis section lists some common design patterns that are **not recommended** in Python and explains why.\n\n### 🧱 Singleton\n**Why not:**\n- Python modules are already singletons — every module is imported only once.\n- Explicit singleton classes add unnecessary complexity.\n- Better alternatives: use module-level variables or dependency injection.\n\n### 🌀 God Object\n**Why not:**\n- Centralizes too much logic in a single class.\n- Makes code harder to test and maintain.\n- Better alternative: split functionality into smaller, cohesive classes.\n\n### 🔁 Inheritance overuse\n**Why not:**\n- Deep inheritance trees make code brittle.\n- Prefer composition and delegation.\n- “Favor composition over inheritance.”\n\n## Videos\n\n* [Design Patterns in Python by Peter Ullrich](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=bsyjSW46TDg)\n* [Sebastian Buczyński - Why you don't need design patterns in Python?](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=G5OeYHCJuv0)\n* [You Don't Need That!](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=imW-trt0i9I)\n* [Pluggable Libs Through Design Patterns](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=PfgEU3W0kyU)\n\n## Contributing\n\nWhen an implementation is added or modified, please review the following guidelines:\n\n##### Docstrings\nAdd module level description in form of a docstring with links to corresponding references or other useful information. \nAdd \"Examples in Python ecosystem\" section if you know some. It shows how patterns could be applied to real-world problems.\n[facade.py](patterns\u002Fstructural\u002Ffacade.py) has a good example of detailed description, but sometimes the shorter one as in [template.py](patterns\u002Fbehavioral\u002Ftemplate.py) would suffice.\n\n##### Python 2 compatibility\nTo see Python 2 compatible versions of some patterns please check-out the [legacy](https:\u002F\u002Fgithub.com\u002Ffaif\u002Fpython-patterns\u002Ftree\u002Flegacy) tag.\n\n##### Update README\nWhen everything else is done - update corresponding part of README.\n\n##### Travis CI\nPlease run the following before submitting a patch:\n- `black .` This lints your code.\n- Either `tox` or `tox -e ci37` for unit tests.\n- If you have a bash compatible shell, use `.\u002Flint.sh`.\n\n## Contributing via issue triage [![Open Source Helpers](https:\u002F\u002Fwww.codetriage.com\u002Ffaif\u002Fpython-patterns\u002Fbadges\u002Fusers.svg)](https:\u002F\u002Fwww.codetriage.com\u002Ffaif\u002Fpython-patterns)\nYou can triage issues and pull requests on [CodeTriage](https:\u002F\u002Fwww.codetriage.com\u002Ffaif\u002Fpython-patterns).\n","python-patterns 是一个汇集了多种设计模式和惯用法的 Python 项目。它涵盖了创建型、结构型等多种设计模式，每种模式都提供了具体的实现代码与简要说明，帮助开发者理解如何在实际编码中应用这些模式。例如，在创建型模式中，项目展示了抽象工厂、建造者等模式的具体实现；而在结构型模式部分，则包括了外观、适配器等模式。该项目适合于希望提升代码质量和可维护性的 Python 开发者学习参考，尤其是在构建复杂系统时，通过合理选择并运用适当的设计模式来优化软件架构。","2026-06-11 02:41:29","top_all"]