作成系(翻訳)|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社エンジニアの「?」を「!」に。作成系(翻訳)hachi8833シェアツイートブックマークLINEこんにちは、hachi8833です。Humansの日本語訳を公開します。クラス図などを使わず、デザインパターンをストーリーで理解できるように書かれた異色のデザインパターン解説です。原著者の許諾を得て、MITライセンスに基づき翻訳・公開いたします。開発者向けのニュースレターを発行しています。Humans」は商標(TM)です。?誰もがつい心躍ってしまうタイトルにしてみました。タイトルに負けないよう、本記事ではこれ以上不可能なまでにシンプルな方法にこだわってデザインパターンを解説しています。本ガイドを気に入っていただいた方はコーヒー一杯おごってくださいまし。他の記事も読んでみたい方は、ぜひHugobotsのご購読をお願いいたします。はじめにデザインパターンとは、常に繰り返される問題を解決するためのものであり「特定の問題に取り組む方法のガイドライン」です。デザインパターンはクラスではありませんし、アプリに追加するだけで奇跡を起こしてくれるようなパッケージやライブラリでもありません。デザインパターンはそうしたものではなく、特定の状況で特定の問題に取り組む方法を示すガイドラインであるとご理解ください。デザインパターンとは、常に繰り返される問題を解決するためのものであり「特定の問題に取り組む方法のガイドライン」です。Wikipediaには次のように書かれています。ソフトウェアエンジニアリングにおけるデザインパターンとは、ソフトウェア設計上の特定コンテキストにおいてよく発生する問題に対する「一般的かつ再利用可能な問題解決法」である。デザインパターンは、ソースコードやマシンコードに直接置換えられるような最終設計ではない。デザインパターンは、さまざまな状況に適用可能な問題解決法の記述、またはテンプレートである。ご注意デザインパターンは、あらゆる問題を解決する「銀の弾丸」ではありません。デザインパターンを強制してはなりません。無理にデザインパターンを適用すれば良くない結果が生じることでしょう。デザインパターンは、問題が起こってからそれを解決するものであって、問題をあら捜しして解決するものではありません。デザインパターンに過剰な期待を持たないことです。適切な場所で適切に用いられたデザインパターンは、救いの神になるでしょう。ないデザインパターンは荒れ狂い、コードをめちゃめちゃにしてしまうことでしょう。以下のコードサンプルではPHP-7を使っていますが、コンセプトはどの言語でも同じなので、どうかページを閉じないでください。ついでながら、他の言語のサポートについては現在作業中です。「作成系」デザインパターンわかりやすくまとめるとこうです。作成系パターンとは、もっぱらオブジェクトのインスタンス化や、関連するオブジェクトのグループ化を行うパターンです。Wikipediaではこうです。ソフトウェアエンジニアリングにおける「作成系」デザインパターンとは、オブジェクト作成メカニズムを扱うデザインパターンであり、状況に即した方法でオブジェクトを作成しようとするものである。オブジェクト作成の基本フォームは、ともすると設計上の問題を引き起こしたり、設計が複雑になってしまうことがある。作成系デザインパターンは、オブジェクト作成を何らかの方法で制御することによってこの問題を解決する。Factoryパターン(link)現実世界になぞらえるとこうです。家造りでドアが必要になったときを考えてみましょう。家の中でドアが必要になるたびにいちいち作業着に着替えてドアを一からこしらえていたのでは煩雑になるばかりです。そんなことをするより、既製品のドアを工場(factory)から運んでくるのが普通でしょう。わかりやすくまとめるとこうです。factoryパターンは、クライアントが必要とするインスタンスを単に生成するものです。このとき、インスタンス生成ロジックはクライアントから見えないようにうまく隠しておきます。Wikipediaではこうです。オブジェクト指向プログラミング(OOP)におけるfactoryとは、他のオブジェクトを作成するオブジェクトのことである。factoryは、メソッド呼び出しからさまざまなプロトタイプやクラスのオブジェクトを返す関数やメソッド(newを前提)のことを指していた。最初に、ドア(Door)のインターフェイスと実装を記述します。}}次に、ドアのfactoryを記述します。このfactoryはドアを作成して返します。}}ここまでできたら、次のように使います。$door->getHeight();使いみちオブジェクトを作成するときに、引数を渡す他にロジックも少々加えたいのであれば、そうしたコードをあちこちで繰り返し書くよりも、それ専用のfactoryを作ってそこに入れておく方が合理的です。Methodパターン(link)現実世界になぞらえるとこうです。manager)を題材にして考えてみましょう。一般に、面接官(interviewer)があらゆる職種(開発、営業、経理など)向けの面接をひとりですべてこなすのは不可能です。欠員の生じた職種によっては、面接を別の人に委任(delegate)しなければならないでしょう。わかりやすくまとめるとこうです。methodは、インスタンス化のロジックを子クラスに委譲する手段を提供するものです。Wikipediaではこうです。method呼び出しでオブジェクトを作成することで行われる。methodをインターフェイスで指定し実装は子クラスで行うか、ベース(親や先祖)クラスに実装し、必要なら派生クラスでオーバーライドする。コンストラクタの呼び出しでは行わない。面接の例を使うことにします。最初に面接官(Interviewer)のインターフェイスと実装を少々記述します。}}続いて採用担当の管理職(HiringManager)を記述します。}}これで、どの子クラスも拡張可能になり、必要な面接官を提供できるようになります。}}これで、次のように使うことができます。コミュニティ育成について尋ねる使いみちあるクラスに何らかの一般的な処理があるが、実行時にサブクラスを動的に決定する必要がある場合に便利です。言い換えると、サブクラスで必要になりそうなものをクライアントが正確には知らない(または知る必要がない)場合です。Factoryパターン(link)現実世界になぞらえるとこうです。factoryのドアのたとえをもう少し広げて考えてみましょう。木製ドアは木製ドア専門店、鉄製ドアは鉄専門店、塩ビドアはそれ専門の店から入手したいとします。ドアの種類ごとに違う職人が必要になるとします(木製なら大工、鉄製なら溶接工、など)。現在取り付けられているドアの種類に応じて、木製ドアには大工を、鉄製ドアなら溶接工を、といった具合に職人を頼む必要があります。わかりやすくまとめるとこうです。factories)は、個別のファクトリーを束ねてグループ化しますが、関連する(または依存する)ファクトリーの具体的なクラスを指定しません。Wikipediaではこうです。factoryパターンは、テーマの共通な個別のファクトリーのグループをカプセル化する手段を提供する。このとき、ファクトリーの具体的なクラスを指定しない。先のドアの例に手を加えます。最初に、Doorインターフェイスと実装を少々記述します。expert)を記述します。factoryができました。これによって、関連するオブジェクト(木製ドアのfactoryは木製ドアと木製ドア取付職人を1つずつ作成し、鉄製ドアのfactoryは鉄製ドアと鉄製ドア取付職人を1つずつ作成する、など)をファミリーごとにまとめることができます。}}これで、以下のように使うことができます。doorとwelderがカプセル化されています。これで、作成したドアの種類に合わない取付職人を呼び出すことがなくなります。使いみち依存関係が双方向で、作成のロジックがある程度以上複雑な場合。Builderパターン(link)現実世界になぞらえるとこうです。米国のレストランチェーン)で何か注文するところを考えます。「ビッグハーディ」を頼めば、店の人は何も聞かずに持ってきます。factoryの例になります。凝ったサブウェイ風のが欲しい場合、ハンバーガーの作り方にはいろいろなオプションが考えられます(どんなバンズにするか、ソースの種類は何がいいか、チーズはどれにするか、など)。このような場合にはbuilderパターンが助けに来てくれるでしょう。わかりやすくまとめるとこうです。味や香り、転じて追加的な要素)を持つオブジェクトを作成できるようになります。オブジェクトにさまざまなフレーバーがある場合や、オブジェクトの作成に関連する手順が多い場合に有用です。Wikipediaではこうです。constructor」アンチパターンの解決を目指す意図を持つソフトウェアデザインパターンである。constructor」アンチパターンについて少しだけ説明しておこうと思います。ひと頃、以下のようなコンストラクタをよく見かけたものです。true){}見てのとおり、コンストラクタのパラメータ数はあっという間に増えて手に負えなくなり、パラメータの並びを理解するのが困難になってしまいます。今後オプションを追加したくなればパラメータリストは大きくなる一方でしょう。constructor」アンチパターンです。プログラム例これに対するまともな手法がbuilderパターンです。最初に、作りたいハンバーガーBurgerを記述します。}}続いてbuilderを記述します。}}これで以下のように書けます。constructorを避ける場合に有用です。factoryパターンとの大きな違いは、factoryパターンは作成が1ステップでできる場合に使うのに対し、builderパターンは作成に複数のステップを踏む場合に使う点です。Prototypeパターン(link)現実世界になぞらえるとこうです。クローン羊ドリーを覚えていますか?詳しい点はともかく、ここで重要なのは「クローン」です。わかりやすくまとめるとこうです。prototypeパターンは、既存のオブジェクトを「クローン」することでオブジェクトを作成します。Wikipediaではこうです。prototypeパターンとは、ソフトウェア開発における作成系デザインパターンであり、作成するオブジェクトの種類はプロトタイプとしてのインスタンスによって決定される。このインスタンスをクローンすることで新しいオブジェクトを生成する。要するに、オブジェクトをスクラッチから苦労して作成・セットアップするのではなく、既存のコピーを作成して必要に応じて改変できるのがprototypeパターンです。プログラム例PHPではcloneで簡単にクローンを実現できます。}}これで以下のようにクローンを実行できるようになります。オオツノヒツジ__cloneというマジックメソッドを使うと、クローンする際の振る舞いを変更することもできます。使いみちオブジェクトが既存オブジェクトに近いものであることが求められる場合や、オブジェクト作成のコストがクローンよりも高い場合に有用です。Singletonパターン(link)現実世界になぞらえるとこうです。一国の大統領は、普通1人だけです。実際に表敬訪問する大統領は常に同一人物でなければなりません。大統領はsingletonなのです。わかりやすくまとめるとこうです。あるクラスのオブジェクトが常に1つだけ作成されることを保証します。Wikipediaではこうです。ソフトウェア・エンジニアリングにおけるsingletonパターンとは、クラスのインスタンスを常に1オブジェクトに制限するソフトウェアデザインパターンです。システム全体に渡る操作を1つのオブジェクトだけが扱う必要がある場合に役に立つ。singletonパターンは実際にはアンチパターンであると考えられており、使い過ぎは慎むべきです。それ自体は悪くありませんし、有用なユースケースもいくつかありますが、アプリケーションにグローバルステートを持ち込んでしまうのと、ある箇所での変更が他の箇所にも影響してしまうことでデバッグがかなり難しくなってしまうため、利用の際には十分注意が必要です。ひとつ問題なのは、コードが密結合になってしまい、シングルトンのモックを作ることが難しくなってしまう点です。プログラム例singletonを作成するには、コンストラクタをprivateにし、クローンを無効にし、拡張(extend)を無効にしてから、静的変数を作成してインスタンス内に配置します。}}使うときは以下のようにします。コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。チュートリアル第2版の監修および半分程度を翻訳、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れて更新翻訳中。enno.jpを運営。実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。Storageを使ってはいけない(翻訳)#Tags#会社紹介#自社サービス#勉強会#Rails#PHP#デザイン#実績#週刊RailsウオッチCONTACTお気軽にご相談ください。(翻訳)CONTACTTechRachoでは、パートナーシップをご検討いただける方からのご連絡をお待ちしております。お気軽にご意見・ご相談ください。