デザインパターン概要
基本原則：
❶変わるものを変わらないものから分離
❷プログラムはインターフェイスに対して行う
❸継承より集約
❹委譲、委譲、委譲
❺必要になるまで作るな（YAGNI）

その後の変更や追加、修正が容易、安全、迅速に行えるように設計すること。

●TemplateMethodパターン
変わるものを、変わらないものから分離するため、
抽象基底クラスを抽出し、基底クラスのメソッドを、サブクラスでオーバーライドさせる方法。
動作は同じだが、種類が違うものに応用できる。abcモジュールで実装可能。
例：種類の違うファイルの出力形式を合わせる。
デメリット：サブクラスが基底クラスに依存してしまう。
↓
●Strategyパターン
strategy(変化する部分、行動、アルゴリズム)を関数として抽出し、基底クラスから呼び出すという形。
TemplateMethodパターンでは種類を分離したが、strategyでは種類と行動を分離する。
これにより、承継による依存度が薄くなる。

●Observerパターン
何かが変更になった際に、オブザーバーに通知する際のデザイン。
変更になった時だけでなく、変更が間違っていた時には通知しない実装も必要。
例：FXでティックが変更になった際に、チャートが更新される仕組み。

●Compositeパターン
複合物、容器と中身を同一視するパターン。
例：ファイル管理
ファイルやディレクトリは同じ、削除メソッドを持っている。
削除メソッド抽出して、新しくシンボリックリンクを追加できるようにする。

●Iteratorパターン
Pythonで言うところのリスト。イテレータ。リスト状に格納して、順番に取り出すことができる。

●Commandパターン
ボタンとボタンが押された時の動作を分離させる。

●Adapterパターン
継承と委譲の２パターンがあり、二つのクラスやインターフェイスの間に入って、二つの機能をつなぐ。

●Proxyパターン
本体とは別に、本体と同じ機能を備えたクラスを作成する。

●Decoratorパターン
アイスクリームのトッピングのように何重にも動作を付け加えていく。

●Singletonパターン
唯一のインスタンスになるデザイン。

●FactoryMethodパターン
Creatorと呼ばれる実行クラスと、concrete creatorと呼ばれる種類を変えるクラスでできている。
Creatorクラスを、concreatorクラスに承継させることで、種類の違う動作をさせる点は、
templatemethodパターンの一種である。
また、承継させるだけでなく、引数としてクラスを呼び出すことで、さらに対応範囲が広がる。
↓
●AbustructFactoryパターン
Factorymethodパターンから、動作の部分を分離させ、種類ごとにクラスわけすることで、
メインクラスから、各種類のクラスを呼び出せるようにした。
Strategyパターンの一種。

●Builderパターン
作業工程をクラスや多くの引数を使って、一気に動作させるのではなく、
クラス内に分離したメソッドに分けて、一つ一つ指示しながら、完成させていくパターン
例：部品が多いオーダーメイドなPCの組み立てなど

●Interpriterパターン
抽象構文木を使うパターン。行動と要素を分類して、順次実行していく。

●Prototypeパターン
型を作って、同じものを量産していく。

●Bridgeパターン
同じ機能を必要としているクラスに対して、機能を重複して足すのではなく、
機能と実装を分離させる。

●Visitorパターン
処理をオブジェクトに任せて、そのオブジェクトを呼び出す。

●Chain of Responsibilityパターン
処理できるものに処理を任せるパターン

●Facadeパターン
多くのクラスが作られる大規模アプリケーションなどで、それらのクラスを統制するクラスを
玄関として作り、そこから各クラスを操作するパターン。

●Mediatorパターン
多くのオブジェクトが複雑に関係している場合に、間に入って、上手いことするやつ。

●Mementoパターン
処理手順のある段階の状態（インスタンス）を記録しておき、
そこに戻ったり、そこから次の処理を開始したりする。

●Stateパターン
状態によって、振る舞いが変化するクラス。
ifを使った場合わけではなく、場合わけをクラスによって行う。

●Flyweightパターン
以前実行して取得したインスタンスを使い回す。