python パターン集
パイソンで書かれたデザインパターンやイディオムのコレクション
主流のパターン
生成に関するパターン:
パターン | 説明 |
---|---|
abstract_factory | 特定のファクトリでジェネリック関数を使用する |
borg | インスタンス間で状態を共有するシングルトン |
builder | 複数のコンストラクターを使用する代わりに、ビルダーオブジェクトはパラメーターを受け取り、構築されたオブジェクトを返す |
factory | インスタンスを作成するための特殊な関数/メソッドを委任する |
lazy_evaluation | Pythonで遅延評価されたプロパティパターン |
pool | 同じタイプのインスタンスのグループを事前にインスタンス化して維持する |
prototype | 新しいインスタンスのファクトリとプロトタイプのクローンを使用する(インスタンス化に時間がかかる場合) |
構造に関するパターン:
パターン | 説明 |
---|---|
3-tier | データ<->ビジネスロジック<->プレゼンテーションの分離(厳密な関係) |
adapter | ホワイトリストを使用して、あるインターフェイスを別のインターフェイスに適合させる |
bridge | インターフェイスの変更を和らげるためのクライアントとプロバイダーの仲介者 |
composite | クライアントが個々のオブジェクトと構成を均一に処理できるようにする |
decorator | 出力に影響を与えるために、機能を他の機能でラップする |
facade | 1つのクラスを他の多くのクラスへのAPIとして使用する |
flyweight | 類似/同一の状態のオブジェクトを透過的に再利用する |
front_controller | 単一のリクエストハンドラー |
mvc | model <-> view <-> controller(非厳密な関係) |
proxy | あるオブジェクトが他の何かに操作を集中させる |
振る舞いに関するパターン:
パターン | 説明 |
---|---|
chain_of_responsibility | 連続するハンドラーのチェーンを適用して、データを処理する |
catalog | 一般的なメソッドは、構築パラメータに基づいてさまざまな特殊なメソッドを呼び出す |
chaining_method | コールバックの次のオブジェクトメソッドを続行する |
command | 後で呼び出すコマンドと引数をバンドルする |
iterator | コンテナを横断し、コンテナの要素にアクセスする |
iterator (alt. impl.) | コンテナを横断し、コンテナの要素にアクセスする |
mediator | 他のオブジェクトを接続してプロキシとして機能する方法を知っているオブジェクト |
memento | 以前の状態に戻るために使う曖昧なトークンを生成する |
observer | データにイベント/変更の通知をするためのコールバックを提供する |
publish_subscribe | ソースはイベント/データを0件以上の登録済みリスナーに配給する |
registry | 特定のクラスのすべてのサブクラスを追跡する |
specification | ブール論理を使用してビジネスルールをチェーン化することにより、ビジネスルールを再結合できる |
state | 離散的な潜在的状態と、遷移可能な次の状態に構造化される |
strategy | 同じデータに対する選択可能な操作 |
template | オブジェクトは構築化を負いますが、接続可能なコンポーネントを受け取る |
visitor | コレクションのすべてのアイテムに対してコールバックを呼び出す |
テストしやすいパターン:
パターン | 説明 |
---|---|
dependency_injection | 依存性注入 3パターン |
基本的なパターン:
パターン | 説明 |
---|---|
delegation_pattern | オブジェクトは、2番目のオブジェクト(デリゲート)に委任することによってリクエストを処理する |
その他:
パターン | 説明 |
---|---|
blackboard | アーキテクチャモデル、ソリューションを構築するためのさまざまなサブシステム知識の組み立て、AIアプローチ - Gang Of Fourのデザインパターンではない |
graph_search | グラフ化アルゴリズム - Gang Of Fourのデザインパターンではない |
hsm | 階層型ステートマシン - Gang Of Fourのデザインパターンではない |
Videos
Design Patterns in Python by Peter Ullrich
Sebastian Buczyński - Why you don't need design patterns in Python?
Pluggable Libs Through Design Patterns
Contributing
When an implementation is added or modified, please review the following guidelines:
Docstrings
Add module level description in form of a docstring with links to corresponding references or other useful information.
Add "Examples in Python ecosystem" section if you know some. It shows how patterns could be applied to real-world problems.
facade.py has a good example of detailed description, but sometimes the shorter one as in template.py would suffice.
Python 2 compatibility
To see Python 2 compatible versions of some patterns please check-out the legacy tag.
Update README
When everything else is done - update corresponding part of README.
Travis CI
Please run tox
or tox -e ci37
before submitting a patch to be sure your changes will pass CI.
You can also run flake8
or pytest
commands manually. Examples can be found in tox.ini
.
You can triage issues and pull requests which may include reproducing bug reports or asking for vital information, such as version numbers or reproduction instructions. If you would like to start triaging issues, one easy way to get started is to subscribe to python-patterns on CodeTriage.