デザインパターン入門

1. 方針
2. 生成に関するパターン
   Factory Method/ Abstract Factory/ Builder/ Prototype/ Singleton/ Object Pool
3. 構造に関するパターン
   Proxy/ Composite/ Adaptor/ Iterator/ Faccade/ Flyweight/ Decorator/ Bridge
4. 振舞いに関するパターン
   Chain of Responsibility/ Command/ Mediator/ Snapshot (memento) / Observer/ State/ Strategy/ Template Method/ Visitor/ Interpreter

• 「眼鏡」を扱う工場で、型番を言えば、 いつでも、その型番の眼鏡を作ってくれる。 利用者は、生産される眼鏡の型番を変えても、 眼鏡の受け取り方・掛け方・メンテナンス方法などは いつも同じで良い。
• この工場(クラス)は、 ある識別子 discriminator (文字列や番号)を与えると、 それに対応する製品が出てくる、 という窓口(メソッド)を持っている。

  Factory

  createProduct(discriminator):Product

• 実際は、ConcreteProductA、ConcreteProductB、…が 返却されるわけだが、利用者は、その親クラスであるProductのレベルでのみ、 その製品を使用する。 製品の生産（コンストラクタ）を 抽象化することにより、 個々の製品と利用者の独立性が保たれ、 また、ポリモフィズムと異なり 動的に所望の製品の インスタンスを得られる。

• 利用者は、自分の好みの仕立て屋を選び、 この仕立て屋を、自分で働かせるのは面倒なので、 監督者に引き渡す。監督者は、責任をもって仕立て屋を働かせ、 最終製品を利用者に引き渡してくれる。
• 利用者は、まず第一に、getInstanceでビルダ(仕立て屋)を選ぶ。

  AbstructBuilder

  getInstance(discriminator):AbstructBuilder buildPart1() buildPart2() … getProduct():Product

  そして利用者は、第二に、ディレクタ(作業監督者)に、 ビルダを引き渡す。すると、製品が出てくる。

  Director

  Build(builder:AbstractBuilder):Product

  監督者は、ビルダが持っている各部分の製造メソッド (buildPart1、buildPart2、…)を呼び出しながら製品を仕上げ、 最後にgetProduct()で成果物を得て、利用者に返す。

• Builderパターンは、どの具象ビルダクラスの インスタンスを生成するかを 決定するために、Factory Methodパターンを 使用する。

• 自分自身のコピーを生成する機能を持っているメモ帳を考える。 メモ帳にも色々なデザインのものがあるが、 コピーの生成方法はそれぞれのデザイン毎に最適に定義されている。 利用者は、どの種類のメモ帳でも、また、何を書き込んだ状態でも、 そのコピーを、いつも同じ手順で得ることが出来る。
• あるプロトタイプのインスタンスがある。 プロトタイプは、自分自身をコピーする（クローンを作成する） メソッドを持っている。 利用者は、このメソッドにより、 プロトタイプが具体的には何であるかを意識せずに そのインスタンスの属性を引き継いだ 新たなインスタンスを生成することが出来る。

  Prototype

  clone():Prototype

• なお、実装上、複製の取り方には一般に以下の二種類がある。
  • 浅いコピー(Shallow copying)
    複製したオブジェクトの変数が 元のオブジェクトの変数と同じ値を持ち、 オブジェクト参照が全て同一オブジェクトを指している。
  • 深いコピー(Deep copying)
    複製したオブジェクトと、それが参照するオブジェクトの両方をコピーする。 言い換えると、 「元のオブジェクトによって参照されるオブジェクトのコピー」 を参照するオブジェクトを参照する変数を除いて、 複製したオブジェクトの変数が元のオブジェクトの変数と 同じ値を持っている。
• JavaBeansは、Prototypeパターンを使っている。 JavaBeansは、規約に則ったクラスのインスタンスであり、 その規約には、 Beanを生成するプログラムをカスタマイズする方法も含まれる。 Beanオブジェクトは、カスタマイズされた後ファイルに保存され、 実行時にアプリケーションによってロードされる。
• Prototypeは、通常、Cloneableインタフェースを実装する。

• 要は、既に作ったことがあればそれを渡し、 一度も作ってなければ、新たに作ってからそれを渡す、ということ。

  Singleton

  《constructor》 -Singleton() 《misc》 +getInstance()

  Singletonのコンストラクタは privateにしておき、 インスタンスを得るgetInstance()の方をpublicにしている、 という可視性の設定がミソ。 Singletonクラスは、自分自身のインスタンスを保持する static変数を内部に持っており、 getInstance()は、既に自分を生成したことがあればそれを返却し、 そうでなければ生成してからstatic変数に代入した上で返却する。

• オブジェクトを 再利用するための管理者が必要であり、 再利用可能なオブジェクトを獲得するメソッドと、 利用し終わったオブジェクトを返却するメソッドを持つ。

  ReusablePool

  《constructor》 -ReusablePool() 《misc》 +getInstance() +acquireReusable():Reusable +releaseReusable(:Reusable) +setMaxPoolSize(maxSize:int) …

• オブジェクトをプールに溜めて再利用することで、 オブジェクトの生成 construct や破壊 destruct を頻繁に行うことによる 性能劣化を避けることが出来る。
• オブジェクトプールを管理するオブジェクトは、 通常Singletonである。

◆構造に関するパターン

• 社員の中でも、管理者は、部下を複数人管理する役割を持つ。 その管理者も、更に上位の管理者に管理されている。
• 管理者も、社員であることに違いはない。 AbstractComposite(管理者)は、 AbstractComponent(社員)を継承しているし、 AbstractLeaf(末端の担当者)も、やはりAbstractComponent(社員)を 継承していることには変わりない。 つまり、「束ねる側」(Composite)と「束ねられる側」(Leaf)の共通部分は 親クラス(Component)として共通に定義され、同等に扱えるようにしておくのである。 （例えば「社員番号」というメンバは親クラスの方に定義しておけば良い。）

  AbstractComposite

  operation() add(AbstructComponent) remove(AbstructComponent) getChild(int)

• 利用者が知っているクラス(Target)を継承して、 その関数をオーバーライドし、 継承先(Adapter)の関数から別のクラスＸを利用する。 これによって、利用者は間接的に未知のクラスＸを利用していることになる。

  Adapter (extends Target)

  operation()

• Adapterは、利用者(Client)と、利用者の知らない１つのオブジェクトの メソッド呼び出しを仲介する。 一方、Faccadeパターンは、 利用者が知らない複数のオブジェクトのメソッドの呼び出しを仲介する。
• Strategyパターンは、 Adapterパターンと構造は似ているが、 もともと意図した機能を実現するための窓口ではなく、 利用者によって振舞いを変更あるいは決定する、という意図がある。

• 利用者が、FlyweightFactoryに、UnsharedConcreteFlyweightクラスの インスタンスを要求した場合は、単に生成して供給する。
  SharedConcreteFlyweightクラスのインスタンスを要求した場合は、 以前に生成したインスタンスを返し、 そうでなければ新しいインスタンスを生成して供給する。

  FlyweightFactory

  getFlyweight(attribute:object)

• SharedConcreteFlyweightの管理は、 Object Poolパターンに類似している。

• Decoratorパターンは、 オリジナルオブジェクトにオペレーションを 委譲している オリジナルクラスのサブクラスのインスタンスを使うことで、 クライアントに透過な方法でオブジェクトの機能性を拡張することができる。 継承が、 クラスのインスタンスの性質をすべて静的に決めるのに対して、 Decoratorパターンは、Decoratorを付加したり取り除くことで、 個々のオブジェクトの振舞いを動的に変更できる。

  AbstractWrapper

  -wrappee:AbstractService

  《constructor》 AbstractWrapper(wrapee) 《misc》 Operation() Operation2() …

• Decoratorパターンは、Wrapper(包むもの)パターンとも言われる。
  ポイントは、Wrapper(包むもの)が、生成時に Wrappee(包まれるもの)を渡されるというところ。 抽象クラスでは、Wrapperの操作(Operation)が呼ばれると、 単にWrappeeの同名の操作が呼ばれる、という仕掛けになっている。 Wrapperの具象クラスでは、各操作を任意に拡張すれば良い。
• 今、サービスＳを、ラッパーＡが包んだとする。 この時、ラッパーＢは、更にラッパーＡを包むように作成することが出来る。 このように、どんどん包んでいくことで、 機能をDecorate(修飾)していくことが出来るわけである。

• あるクラスSubjectから継承したProxy、RealSubjectは、 同じRequest()メソッドを持つが、 利用者は常にProxyに対してRequest()を発行する。 Proxyは、必要に応じて、実体処理の都合なども考慮し、 RealSubjectのRequestを呼び出す。 RealSubjectの生成にコストを要するとか、 呼び出し方に注意が必要な場合に、 その調整をProxyが行う。
• Decoratorパターンが 利用者に追加機能を提供するのに対して、 Proxyパターンは利用者への見せ方は変えずに、 実装上の処理実体の呼び出し方を最適に調整する。 このため、処理実体(RealSubject)と代理(Proxy)は、 同じクラス(Subject)から継承され、 利用者から見たインタフェース(Request)は同じである。

• クラスの継承は、機能を拡張したい場合と、 実装方法を増やしたい場合に使われるが、 この２つが同時に必要となる可能性があるなら、 実装方法は別のクラス階層にして、 委譲により呼び出すようにする。 （実装方法を疎な関係にしておく。）
• 例えば、時計クラスを継承して、 ゼンマイ時計クラスとクォーツ時計クラスを作ったとする。 ここでもし、多重継承が使えないとして、 アラーム機能付き時計クラスが欲しくなったらどうするか？ 時計クラスを継承してアラーム機能付き時計クラスを作り、 それを継承して新たにアラーム機能付きゼンマイ時計クラスと アラーム機能付きクォーツ時計クラスを作らねばならないだろう。
• こうならないよう、時計クラスは、 時間測定の実装を自分に持たず、 別の時間測定実装クラスに委譲してしまうのである。 こうしておけば、 「時計クラスに機能を追加する継承関係」と、 「時間測定実装クラスに実装方式を与える継承関係」を 独立に保つことが出来るのである。
• 委譲により、 機能のクラス階層と実装のクラス階層の橋渡しを行うので Bridgeパターンと呼ばれている。

◆振舞いに関するパターン

• Mediator(仲介者)は、Colleague(同業者)達からの申し出に耳を傾け、 また、Colleague達に適切な指示を出す。 Colleague同士で勝手に問題解決せず、かならずMediatorを仲介する、 という決まりにし、状況が複雑になるのを防ぐ。

  Mediator

  registerColleague1(Colleague1) registerColleague1(Colleague2) … handleEvent1() handleEvent2() …

• Mediatorパターンは、Compositeパターンで 構成されたオブジェクト構造において、 直接繋がっていない任意のobject同士が影響を及ぼしあうような、 複雑で保守の困難なコーディングを避けるのに適している

• 今、会話クラスに、３つの機能 挨拶する()、 断る()、承諾する() があるとしよう。ここで、相手が子供か上司か先生か恋人かによって 戦略を変えて適切な回答を返すようにしたい。 引数に相手のタイプを渡して個々のメソッドの中で if文やswitch文を連ねていちいち判定を行うのも手だが、 会話クラスには各機能の器だけ用意し（つまり抽象メソッドとして定義し）、 そこから子供用会話クラス、上司用会話クラスなどと 戦略別にサブクラスを継承して作った方が 煩雑な分岐文が無くなって分かり易いだろう。 相手を指定すると、それに対応した サブクラスのインスタンスを返すような仕組み(Contextクラス)を作っておけば、 利用者は、その仕組みに対して相手を指定する事で 適切な会話クラスのサブクラスのインスタンスを得ることが出来る。 それは具体的には子供用会話クラスのインスタンスかもしれないし、 上司用会話クラスのインスタンスかもしれないが、 利用者は何のサブクラスかは気にせず、 挨拶する()、断る()などの 機能を利用することが出来る。
• このように、必要な機能を定義しただけのクラスを用意し、 戦略毎の具体的なアルゴリズムは個々のサブクラスに実装するのが Strategyパターンである。 クライアントは、操作を抽象クラス(AbstractStrategy)に 委譲する。 クライアントは、最初に戦略の種類を指定して、 戦略クラスのインスタンスを得るが、 委譲する操作の実際のクラス(ConcreteStrategy)が何であるか については気にする必要がない。
• 一つの戦略クラスの個々の機能に、戦略種類毎に 分岐分で処理内容を記述するのは煩雑だし、 戦略種類を増やす場合の保守性も悪い。 個々の戦略をサブクラスに分けて記述することによって プログラムの可視性、保守性を向上させることができる。

  AbstractStrategy

  operation1() operation2() ：

• Strategyパターンでは委譲によって異なる振舞いを管理するが、 TemplateMethodパターンでは サブクラス化によってこれを実現している。
  Strategyパターンの目的は、クライアント側の振舞いを柔軟に変更する、 ということであるが、Adaptorパターンは クライアントが意図通りの機能を呼び出すことが目的である。 Strategyパターンの実装はStateパターンに良く似ているが、 Stateパターンが状態毎に挙動を定義するのを目的とするのに対して、 Stragegyパターンは処理対象毎に適切なアルゴリズムに切り替えるのが目的である。 言い換えると、どういう対象にどのアルゴリズムを適用させるか、という戦略を カプセル化することが出来る。

• オブジェクト構造の各要素に対して計算を行う。 要素が属するクラス毎に計算方法を定義しておく。 （要素のクラス毎にvisitメソッドを オーバーロードする。）

  AbstractVisitor

  visit(:Element1) visit(:Element2) …

• Visitorに訪れられる側の要素は、 Visitorを受け入れて、Visitorの特定のメソッドを呼び出した後、 他の要素の受け入れメソッドにVisitorを渡す。

  AbstractElement

  accept(:AbstractVisitor) …

• Compositeパターンの要素に accept()を実装しておけば、 visitorがComposite構造の各要素を順に巡って、 情報を集めたり処理を行わせるなどの機能追加が可能となる。 例えば、accept()は、自分に子いなければ (leafであれば) visitorのvistメソッドの引数に 自分自身を入れて呼び出し( v.visit(this) )、 自分の子がいれば全ての子にvisitorを渡す ( child.accept(v) ) としておけば、 visitorは全てのleafを巡って、情報収集や処理指示を行うことが出来る。 visitメソッドは、オーバーロードする事で 要素の型に応じた処理を指定できる。

• 例えば、ＢＮＦで表現された文法構造を、 同じ表現クラス(Expression)から継承した 対象表現クラス(TerminalExpression)と 関係表現クラス(NonterminalExpression)の構造で表現する、という事。 対象クラスとして「０」、「１」を、 関係クラスとして「足す」、「掛ける」を作ると、 「１×（０＋１）」という数式（文法構造）は、 「掛ける」の子に「１」と「足す」が、 その「足す」の子に「０」と「１」がいる、という木構造で表現できる。
• Interpreterパターンは、 構造としてはCompositeパターンと似ており、 「対象」と「対象間の関係」のいずれも木構造の一員になれる、 という意味で同じスーパークラスを持つ。 一方、Interpreterパターンでは、単なる木構造ではなく、 「対象間の関係」を表わすクラスは配下の子の特定の関係を表現する、 という積極的な意味を持っている点が特徴である。

◆参考文献

• 「オブジェクト指向における再利用のためのデザインパターン」 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides著、 SOFT BANK、ISBN4-89052-797-4
• 「UMLを使ったJavaデザインパターン 〜再利用可能なプログラミング設計集〜」 Mark Grand 著、カットシステム、ISBN4-87783-013-8