Software design patterns in python

Design Patterns in Python

Design Patterns are reusable models for solving known and common problems in software architecture.

They’re best described as templates for dealing with a certain usual situation. An architect might have a template for designing certain kinds of door-frames which he fits into many of his projects, and a software engineer, or software architect, should know templates for solving frequent programming challenges.

A good presentation of a design pattern should include:

Equivalent Problems

If you were thinking that that’s a pretty fuzzy concept, you’d be right. For instance, we could say that the following «pattern» solves all of your problems:

1. Fetch and prepare the necessary data and other resources
2. Do the calculations needed and perform the necessary work
3. Make logs of what you’re doing
4. Release all resources
5. .
6. Profit

This is an example of thinking too abstract. You can’t really call this a pattern because it’s not really a good model for solving any problem, despite being technically applicable to any of them (including making dinner).

On the other extreme, you can have solutions that are just too concrete to be called a pattern. For instance, you could wonder whether QuickSort is a pattern for solving the sorting problem.

It certainly is a common programming problem, and QuickSort is a good solution for it. However, it can be applied to any sorting problem with little to no modification.

Once you have it in a library and you can call it, your only real job is to make your object comparable somehow, you don’t really have to deal with the essence of it yourself to modify it to fit your particular problem.

Equivalent problems are somewhere between these concepts. These are different problems that are sufficiently similar that you can apply a same model to them, but sufficiently different that this model has to be customized considerably to be applicable in each case.

Patterns that could be applied to these sorts of problems are what we can meaningfully dub design patterns.

Why use Design Patterns?

You’re probably familiar with some design patterns already through practice of writing code. A lot of good programmers eventually gravitate towards them even without being explicitly taught or they just pick them up from seniors along the way.

Motivations for making, learning, and utilizing design patterns are manyfold. They’re a way to give names to complex abstract concepts to enable discussion and teaching.

They make communication within teams faster, because someone can just use the pattern’s name instead of whipping out a whiteboard. They enable you to learn from the experiences of people who came before you, rather than having to reinvent the wheel by going through the whole crucible of gradually improving practices yourself (and having to constantly cringe at your old code).

Bad solutions that tend to be commonly invented because they seem logical on the first glance are often called anti-patterns. In order for something to justly be called an anti-pattern it needs to be commonly reinvented and there needs to be a pattern for the same problem which solves it better.

Despite the obvious utility in practice, design patterns are also useful for learning. They introduce you to many problems that you may not have considered and allow you to think about scenarios that you may not have had hands-on experience with in-depth.

They’re a must-learn for all, and they’re an exceptionally good learning resource for all aspiring architects and developers who may be at the beginning of their careers and lacking the first-hand experience of grappling with various problems the industry provides.

Design Patterns in Python

Traditionally, design patterns have been classified into three main categories: Creational, Structural, and Behavioral. There are other categories, like architectural or concurrency patterns, but they’re beyond the scope of this article.

There are also Python-specific design patterns that are created specifically around the problems that the structure of the language itself provides or that deal with problems in special ways that are only allowed because of the structure of the language.

Creational Design Patterns deal with creation of classes or objects. They serve to abstract away the specifics of classes so that we’d be less dependent on their exact implementation, or so that we wouldn’t have to deal with complex construction whenever we need them, or so we’d ensure some special instantiation properties. They’re very useful for lowering levels of dependency and controlling how the user interacts with our classes.

Structural Design Patterns deal with assembling objects and classes into larger structures, while keeping those structures flexible and efficient. They tend to be really useful for improving readability and maintainability of the code, ensure functionalities are properly separated, encapsulated, and that there are effective minimal interfaces between interdependent things.

Behavioral Design Patterns deal with algorithms in general, and assignment of responsibility between interacting objects. For example, they’re good practices in cases where you may be tempted to implement a naive solution, like busy waiting, or load your classes with unnecessary code for one specific purpose that isn’t the core of their functionality.

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

A collection of design patterns/idioms in Python

faif/python-patterns

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Pass the `move` object to the `do_action()` method

Git stats

Files

Failed to load latest commit information.

README.md

A collection of design patterns and idioms in Python.

Creational Patterns:

Pattern	Description
abstract_factory	use a generic function with specific factories
borg	a singleton with shared-state among instances
builder	instead of using multiple constructors, builder object receives parameters and returns constructed objects
factory	delegate a specialized function/method to create instances
lazy_evaluation	lazily-evaluated property pattern in Python
pool	preinstantiate and maintain a group of instances of the same type
prototype	use a factory and clones of a prototype for new instances (if instantiation is expensive)

Structural Patterns:

Pattern	Description
3-tier	databusiness logicpresentation separation (strict relationships)
adapter	adapt one interface to another using a white-list
bridge	a client-provider middleman to soften interface changes
composite	lets clients treat individual objects and compositions uniformly
decorator	wrap functionality with other functionality in order to affect outputs
facade	use one class as an API to a number of others
flyweight	transparently reuse existing instances of objects with similar/identical state
front_controller	single handler requests coming to the application
mvc	modelviewcontroller (non-strict relationships)
proxy	an object funnels operations to something else

Behavioral Patterns:

Pattern	Description
chain_of_responsibility	apply a chain of successive handlers to try and process the data
catalog	general methods will call different specialized methods based on construction parameter
chaining_method	continue callback next object method
command	bundle a command and arguments to call later
iterator	traverse a container and access the container’s elements
iterator (alt. impl.)	traverse a container and access the container’s elements
mediator	an object that knows how to connect other objects and act as a proxy
memento	generate an opaque token that can be used to go back to a previous state
observer	provide a callback for notification of events/changes to data
publish_subscribe	a source syndicates events/data to 0+ registered listeners
registry	keep track of all subclasses of a given class
specification	business rules can be recombined by chaining the business rules together using boolean logic
state	logic is organized into a discrete number of potential states and the next state that can be transitioned to
strategy	selectable operations over the same data
template	an object imposes a structure but takes pluggable components
visitor	invoke a callback for all items of a collection

Design for Testability Patterns:

Pattern	Description
dependency_injection	3 variants of dependency injection

Fundamental Patterns:

Pattern	Description
delegation_pattern	an object handles a request by delegating to a second object (the delegate)

Pattern	Description
blackboard	architectural model, assemble different sub-system knowledge to build a solution, AI approach — non gang of four pattern
graph_search	graphing algorithms — non gang of four pattern
hsm	hierarchical state machine — non gang of four pattern

Источник