[保存版]人間が読んで理解できるデザインパターン解説#1: 作成系(翻訳)

こんにちは、hachi8833です。今回から3回に渡ってDesign Patterns for Humansの日本語訳を公開します。あえてクラス図などを使わず、デザインパターンをストーリーで理解できるように書かれた異色のデザインパターン解説です。 #1 作成系デザインパターン(本記事) #2 構造系デザインパターン #3 振舞い系デザインパターン 概要 原著者の許諾を得て、MITライセンスに基づき翻訳・公開いたします。 英語記事: Design Patterns for Humans™ – An ultra-simplified explanation 更新日: 2017/09/25 著者: Kamran Ahmed サイト: Hugobots — 開発者向けのニュースレターを発行しています。 「Design Patterns for Humans」は商標(TM)です。 人間が読んで理解できるデザインパターン解説#1: 作成系(翻訳) 🎉 究極にシンプルなデザインパターン解説! 🎉 誰もがつい心躍ってしまうタイトルにしてみました。タイトルに負けないよう、本記事ではこれ以上不可能なまでにシンプルな方法にこだわってデザインパターンを解説しています。 本ガイドを気に入っていただいた方はコーヒー一杯おごってくださいまし。他の記事も読んでみたい方は、ぜひHugobotsのご購読をお願いいたします。 🚀 はじめに デザインパターンとは、常に繰り返される問題を解決するためのものであり「特定の問題に取り組む方法のガイドライン」です。デザインパターンはクラスではありませんし、アプリに追加するだけで奇跡を起こしてくれるようなパッケージやライブラリでもありません。デザインパターンはそうしたものではなく、特定の状況で特定の問題に取り組む方法を示すガイドラインであるとご理解ください。 デザインパターンとは、常に繰り返される問題を解決するためのものであり「特定の問題に取り組む方法のガイドライン」です。 Wikipediaには次のように書かれています。 ソフトウェアエンジニアリングにおけるデザインパターンとは、ソフトウェア設計上の特定コンテキストにおいてよく発生する問題に対する「一般的かつ再利用可能な問題解決法」である。デザインパターンは、ソースコードやマシンコードに直接置換えられるような最終設計ではない。デザインパターンは、さまざまな状況に適用可能な問題解決法の記述、またはテンプレートである。 ⚠️ ご注意 デザインパターンは、あらゆる問題を解決する「銀の弾丸」ではありません。 デザインパターンを強制してはなりません。無理にデザインパターンを適用すれば良くない結果が生じることでしょう。デザインパターンは、問題が起こってからそれを解決するものであって、問題をあら捜しして解決するものではありません。デザインパターンに過剰な期待を持たないことです。 適切な場所で適切に用いられたデザインパターンは、救いの神になるでしょう。そうでないデザインパターンは荒れ狂い、コードをめちゃめちゃにしてしまうことでしょう。 追伸: 以下のコードサンプルではPHP-7を使っていますが、コンセプトはどの言語でも同じなので、どうかページを閉じないでください。ついでながら、他の言語のサポートについては現在作業中です。 デザインパターンの種別 #1 作成系 — 本記事 #2 構成系 #3 振舞い系 #1 「作成系」デザインパターン わかりやすくまとめるとこうです。 作成系パターンとは、もっぱらオブジェクトのインスタンス化や、関連するオブジェクトのグループ化を行うパターンです。 Wikipediaではこうです。 ソフトウェアエンジニアリングにおける「作成系」デザインパターンとは、オブジェクト作成メカニズムを扱うデザインパターンであり、状況に即した方法でオブジェクトを作成しようとするものである。オブジェクト作成の基本フォームは、ともすると設計上の問題を引き起こしたり、設計が複雑になってしまうことがある。作成系デザインパターンは、オブジェクト作成を何らかの方法で制御することによってこの問題を解決する。 Simple Factoryパターン Factory Methodパターン Abstract Factoryパターン Builderパターン Prototypeパターン Singletonパターン 🏠 Simple Factoryパターン(link) 現実世界になぞらえるとこうです。 家造りでドアが必要になったときを考えてみましょう。家の中でドアが必要になるたびにいちいち作業着に着替えてドアを一からこしらえていたのでは煩雑になるばかりです。そんなことをするより、既製品のドアを工場(factory)から運んでくるのが普通でしょう。 わかりやすくまとめるとこうです。 simple factoryパターンは、クライアントが必要とするインスタンスを単に生成するものです。このとき、インスタンス生成ロジックはクライアントから見えないようにうまく隠しておきます。 Wikipediaではこうです。 オブジェクト指向プログラミング(OOP)におけるfactoryとは、他のオブジェクトを作成するオブジェクトのことである。元々factoryは、メソッド呼び出しからさまざまなプロトタイプやクラスのオブジェクトを返す関数やメソッド(newを前提)のことを指していた。 プログラム例 最初に、ドア(Door)のインターフェイスと実装を記述します。 interface Door { public function getWidth(): float; public function getHeight(): float; } class WoodenDoor implements Door { protected $width; protected $height; public function __construct(float $width, float $height) { $this->width = $width; $this->height = $height; } public function getWidth(): float { return $this->width; } public function getHeight(): float { return $this->height; } } 次に、ドアのfactoryを記述します。このfactoryはドアを作成して返します。 class DoorFactory { public static function makeDoor($width, $height): Door { return new WoodenDoor($width, $height); } } ここまでできたら、次のように使います。 $door = DoorFactory::makeDoor(100, 200); echo ‘Width: ‘ . $door->getWidth(); echo ‘Height: ‘ . $door->getHeight(); 使いみち オブジェクトを作成するときに、引数を渡す他にロジックも少々加えたいのであれば、そうしたコードをあちこちで繰り返し書くよりも、それ専用のfactoryを作ってそこに入れておく方が合理的です。 🏭 Factory Methodパターン(link) 現実世界になぞらえるとこうです。 … Continue reading [保存版]人間が読んで理解できるデザインパターン解説#1: 作成系(翻訳)