[JP]Design Pattern: Factory Method

Jangwook Kim
Dec 22, 2019 · Unlisted

Design Pattern とは Object-Oriented プログラミングをしながら発生する一般的な問題を解決する方法を定義したものであります。

Design Pattern はモジュール・ライブラリーではなく、1つの概念で、我々が普通に使っているフレームワークは Design Pattern に適した書き方でコードがかけるようにデザインされています。

フレームワークを使えば Design Pattern を守ることができるというのにも関わらず、Design Pattern を勉強する必要があるのでしょうか?

もちろんあるのでこの記事を作成しています。笑


なぜ Design Pattern を勉強しなければなりませんか?

  1. Design Pattern を知ることにより、Object-Oriented プログラミングではどんな問題が発生するのかを理解することができます。
  2. 他のプログラマーにコードを説明するとき、お互い理解できる言葉で簡単に説明できるようになります。言い換えると、Design Pattern はプログラマーたちの1つのプロトコルと言えます。
  3. 効率的なコードとは何かもう一回考えてみるきっかけとなります。

上記のような理由で我々は Design Pattern を勉強しなければなりません。

これから何回に分けて、Design Pattern を調べてみようと思っています。

もちろん僕は PHPer なので例は PHP で作成されます。


Factory Method

Factory Method は Design Pattern の中で Creational Pattern になります。Factory Method は SOLID 原則の中 D に該当する依存関係逆転(DIP: Dependency Inversion Principle)を満たします。

Factory Method は何をしますか?

  1. クライアント(実際生成されたオブジェクトが使われるところ)がオブジェクトの生成ロジックを知らなくてもオブジェクトを生成できるようにします。
  2. 共通インタフェースを使用し、必要な最低限の情報を利用してオブジェクトが生成できるようになります。

Factory はその言葉通り、オブジェクトを生成するための工場になります。この工場は作ろうとするオブジェクトの詳細には興味がありません。単純に作るのに集中するだけです。

Factory Method Pattern を使用するとどんな利点がありますか?

  1. クラス間の結合が弱くなります。
  2. 複雑な生成ロジックを持っているオブジェクトの生成をクライアントが簡単にできるようにします。
  3. 新しいタイプのクラスが追加された時、クライアントのコードを変更する必要がなくなります。
  4. コードをより柔軟に、メンテナンス可能に、拡張可能にします。

例を通じて Factory Method Pattern を理解してみましょう

私は実は字で書いてあるものを読みながら理解するのが好きです。コードをずっと読むのは私のとって難しいことでもあります。それにも関わらず、適切なコード例は理解することを助けてくれるのも事実です。

我々はゲームを作るための簡単なプログラムを持っています。下記のコードが現在我々が持っているプログラムです。

Factory Method Pattern が適用されてない簡単なプログラム

簡単で理解しやすいプログラムですが、このプログラムには問題があります。クラスを修正するとクライアントコードを修正しなければならないことです。

簡単すぎると何が問題になるのか想像つかないので、このプログラムをもうちょっと複雑にしてみましょう。

Factory Method Pattern が適用されてない少し複雑なプログラム

API を通じてゲームを作る日の販売価格を取得する必要があると想定してみましょう。この場合、AbstractGame を継承した全てのクラスは販売価格と日付データがパラメータとして必要になります。下記のような修正が発生します。

クラスには販売価格と日付の2つのプロパティーが追加されました。上記のコードだけではあまり変わった部分ないじゃない?と思われるかもしれませんが、実際のコードでは ZeldaPokemon のインスタンスがいろんなところで生成されている可能性が非常に高いです。

コード全体で生成されたインスタンスを検索し、修正する手間がかかります。

Factory Method Pattern 適用

この記事の上部で Factory は単純にオブジェクトを生成する工場という意味だと説明しました。

クラスの変更によるコードの変更することをできるだけ避けたいため(これはクラス間の結合度を弱くすることとも表現できます。)、生成だけを担当している Factory を作ります。

ゲームを生成を担当している Factory を生成しました。

これからクライアントコードは下記のように変えることができます。

もし最初から Factory を持っていて、getGameTitle() メソッドを実行するために上記のようなコードを作成したと想定したら、販売価格($price)および日付($today)プロパティーが追加された時、クライアントコードにはなんの影響もなかったことがわかります。

コードを変更したあと、Factory のメソッドが動作することだけ確認したら、クライアントコードでは動作に問題がないことがある程度保証できるようになります。


結論

Design Patterを適用しないでコードを何も考えず正しく動くだけに集中して書くと、時間が経って仕様を変更する必要があるとき、サイドエフェクトの範囲が特定できないため、修正が難しい場合ができます。

こんなリスクをできるだけ回避するために Design Pattern を勉強する必要があります。私もより品質高いコード作成およびリファクタリングのため Design Pattern を勉強し続けていきます。

記事に対するフィードバックは遠陵なく話してください!

次回の記事では Factory Method Pattern を少し改善した Abstract Factory Pattern に対して記事を書きます。


Unlisted

Jangwook Kim

Written by

Korean, live in Japan. The programmer. I love to learn something new things. I’m publishing my toy projects using GitHub. Visit https://www.jangwook.net.

Jangwook Kim

Written by

Korean, live in Japan. The programmer. I love to learn something new things. I’m publishing my toy projects using GitHub. Visit https://www.jangwook.net.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store