デザインパターン 小淵 将吾 日和 悟 廣安 知之 2015 年 11 月 11 日 IS Report No. 2015111101 Report Medical Information System Laboratory Abstract プログラミングでは，開発時にいくつかのパターンが存在する．Erich Gamma，Richard Helm，Ralph Johnson，John Vissides の 4 人はそのようなパターンを「デザインパターン」という形にして整理し た．この 4 人は the Gang of Four，あるいは GoF と呼ばれ，23 個のデザインパターン（GoF のデザイ ンパターン）を作成した．本稿では，オブジェクト指向プログラミング，Unified Modeling Language について説明した後に，それらを用いて GoF のデザインパターンにについて記述する． キーワード: オブジェクト指向, UML, デザインパターン, GoF 目次 第 1 章 オブジェクト指向プログラミング. . . . . . . . . . . . . . . . . . . 2 第 2 章 Unified Modeling Language (UML). . . . . . . . . . . . . . . . . . 4 2.1 クラス図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 シーケンス図 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 第 3 章 設計の原則 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 第 4 章 デザインパターン . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1 Template Method. . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 第 1 章 オブジェクト指向プログラミング オブジェクト指向とは，ソフトウェアを開発するときにオブジェクトを中心に考える「視点」のこと である 1) ．オブジェクトは，ソフトウェアの中の「もの」と考えられ，オブジェクト指向プログラ ミングでは，いくつかの「オブジェクト」を生成して，これらの「オブジェクト」どうしを相互作用 させることによりプログラムを実行していく．これにより，人間に把握できるプログラム開発を実現 する．オブジェクトとは，認識の対象として具体的に識別できるもので，以下の 4 つの特性がある． • 属性 固有の姿，形，性質 • 操作 固有の振る舞い • 関係 他のオブジェクトとの関係 • アイデンティティ 他のオブジェクトから自らを識別 オブジェクト指向プログラミングは上記の特性を持った「オブジェクト」がプログラミングの中心 となる．そもそも，プログラムやシステムは「現実世界における何らかの活動を自動化するためのも の」である．したがって，オブジェクト指向の開発を行う場合，実現しようとする部分の「現実世界」 を観察し，設計図を描く必要がある．オブジェクト指向プログラミングは，オブジェクト間の協調動 作を表現する自立分散協調モデルの考え方を用いて設計を行う．この考え方は複数のオブジェクトが 集まって一つの仕事をするという考え方である．個々のオブジェクトは責務をもち，仕事の依頼に応 答する．それぞれ責務をもったオブジェクトがメッセージのやりとりで協力して 1 つの仕事を果たす というモデルが自立分散協調モデルである．このモデルのもと，オブジェクトをプログラム中で表現 していくために，プログラマは「クラス」を作成する．クラスは，オブジェクトの情報を一般化した 「定義」である．つまりクラスを具体化したものがオブジェクトである． オブジェクト指向言語には，開発者が「より便利に」「より安全に」現実世界が模倣できるように 一般的に以下の 3 つの機能がある． • カプセル化 • 継承 • 多態性 2 第 1 章 オブジェクト指向プログラミング カプセル化とは，オブジェクト内部のデータや振る舞い，そして実際の型を隠蔽することをいう． したがって，カプセル化を用いるとメンバやクラスについてアクセス制御が可能となる．特に，変数 に「現実世界ではあり得ない値」が入らないように制御する．カプセル化の定石として，クラスとメ ソッドは public，フィールドは private で修飾することが多い．継承とは，以前作ったクラスにとて もよく似ているが，一部だけ違うクラスを作成する際に，あるオブジェクトが他のオブジェクトの特 性を引き継がせることをいう．親クラスのメンバは自動的に子クラスに引き継がれるため，子クラス では差分だけを記述する．親クラスに宣言が存在するメソッドを，子クラスで上書き宣言することを オーバーライドという．一般的に継承関係には「子クラス is-a 親クラス」の関係が成り立つ．継承に は， 「抽象的・具体的」の関係にあることを定義する役割もある．多態性とは似ている 2 つのクラスを 同じようなものと見なし利用できる機能のことをいう．このメリットとしては，同一視をすることに よって，配列に格納することができる．同一視してザックリとした引数を受け取ることができる．ま たメソッドの動作は中身の型に従う．呼び出し側は相手を同一視し，同じように呼び出すのに，呼び 出される側は，きちんと自分に決められた動きをする．以上より，オブジェクト指向プログラミング の具体的なメリットとして， • プログラムを用意に変更しやすくなる（柔軟性・保守性の向上） • プログラムの一部を簡単に転用できる（再利用性の向上） が挙げられる． 実際オブジェクト指向でプログムを作成するには，現実世界をモデリングする必要がある．以下で はそのモデリングを容易に行うために必要な Unified Modeling Language (UML) を説明する． 3 第 2 章 Unified Modeling Language (UML) オブジェクト指向によるシステム開発では，オブジェクト群がどのような構造を持っているのか，オ ブジェクトの間でどのようなメッセージが交わされているのかなどのさまざまな視点からオブジェク トをとらえる．それらを図（ダイアグラム）であらわすことで，技術者間でより正確にオブジェク トに関する情報や考え方を交換することができるようになる．そのような図のことをモデルとよぶ． モデルを正確に読み取るためには，モデルの描き方のルール（表記法）が決まっている必要がある． UML はオブジェクト指向によるシステム開発で用いられるさまざまなモデルの表記法のデファクト スタンダードである．UML は分析から設計，実装まで終始一貫して使われる技術である．分析から実 装までが同じ表現で統一されることで，それぞれの対応関係や問題箇所の特定がしやすくなる．UML では構造を表すダイアグラムや，振る舞いを表すダイアグラムなど，全部で 10 種類のダイアグラム を提供している（Table. 2.1）．システム開発の際にはこれらを必要に応じて組み合わせて利用する． Table. 2.1 UML ダイアグラムの種類 ダイアグラム 役割 開発フェーズ ユースケース図 システムの境界 分析 アクティビティ図 システムの動作の流れの表現 分析・設計 状態図 オブジェクトの取りうる状態，遷移を表現 分析・設計 クラス図 概念や静的なクラス間相互関係を表現 分析・設計 パッケージ図 各モデル要素の階層的グルーピング 分析・設計 シーケンス図 オブジェクト間のメッセージ交換の時系列表現 分析・設計 コラボレーション図 オブジェクトの集団の協調動作の表園 分析・設計 オブジェクト図 実行時のオブジェクト状態のスナップショット 分析・設計 コンポーネント図 システムを構成する実行可能モジュールやソースコードの物理的構造を表現 設計 配置図 システムを構成するマシンや装置の作りを表現 設計 以下ではデザインパターンの章で使用するクラス図とシーケンス図について記述する． 2.1 クラス図 クラス図とは，オブジェクト指向の分析・設計において，対象領域やシステム内部の静的な構造と クラス間の関係を示すダイアグラムである 2) ．UML のクラス図は，クラスやインスタンス，インタ フェースなどの静的な関係を表現したもので，図の要素には以下のものがある．長方形の中は 3 区画 に分かれ，Fig. 2.1(a) と Fig. 2.1(b) のように上からクラス名，属性，操作が記述される．クラスの 関係は，クラスを表す矩形と矩形の間に線を引いて表現し，線の横に関連名や役割名，多重度などを 記してその関係をより明確にする．関係を以下に示す． • 関連（association） クラスとクラスの間に関係があることを示す． 4 2.1 クラス図 第 2 章 Unified Modeling Language (UML) • 誘導可能性（navigatability） あるクラスから関連するほかのクラスへの参照を持っていることを示す． • 集約（aggregation） あるクラスから関連するほかのクラスへの参照を持っていることを示す． • コンポジション（composition） あるクラスがほかのクラスの組み合わせで構成されていることを示す．要素を表すクラスが消 滅しても，全体を表すクラスは消滅しないような関係に使われる． • 依存（dependency） あるクラスがほかのクラスの組み合わせで構成されていることを示す．全体・部分の 2 つのク ラスの生成と消滅が一致するようなものの関係に使われる． • 汎化（generalization） あるクラスの変更がほかのクラスに影響を及ぼすような動的・一時的な関係を示す． • リアライゼーション（realization） 一般的なクラス（スーパークラス）と具体的なクラス（サブクラス）の関係を示す． 特に Fig. 2.1(a) では関係の中でも階層関係を示している．矢印はサブクラスからスーパークラス へ向かっており，抽象クラスや抽象メソッドは斜体，静的な変数やメソッドは下線を引いて表現する． また Fig. 2.1(b) では，アクセス制御を示している．’+’ は public なメソッドや変数，’-’ は private な メソッドや変数を表現する． (a) 階層関係 (b) アクセス制御 Fig. 2.1 クラス図（参考文献 2) を参考に自作） 5 2.2 シーケンス図 第 2 章 Unified Modeling Language (UML) クラス図ではクラス間の静的な関係を示している．一方で，次にプログラム実行時の動きを示す UML であるシーケンス図がある． 2.2 シーケンス図 シーケンス図とは，プログラムが動くときに，どのようなメソッドがどういう順番で実行されるか， どのような事象がどういう順番で起きるかを表現したものである．クラスやオブジェクト間のやりと りを時間軸に沿って表現する．図の要素には以下のものがある． • ライフライン 使用するオブジェクトやクラスを表現する． • 実行仕様 生成されているライフラインが実行状態にあることを意味する． • 停止 生成されたライフライン自体の消滅を意味する． • メッセージクラスやオブジェクト間のやり取りの内容を意味する． Fig. 2.2 にシーケンス図の例を示す． Fig. 2.2 シーケンス図（参考文献 2) を参考に自作） 矢印はメソッドの呼び出しを示し，破線の矢印はメソッドからの戻りを示す．システム作成は，ま ずこれらのような UML を作成し行っていく．UML の作成にあたり，どのようなシステム設計が良 いのかを次章で記述する． 6 第 3 章 設計の原則 システム設計には優れた設計の原則がある．原則は • コード記述全般について • クラス設計について • クラス間の関係について の 3 種類に分けれる． コード記述全般に関する原則は， 「同じことを何度もやらない」Don’t Repeat Yourself (DRY)， 「意 図や意味がわかりやすい記述」Program Intently and Expressively (PIE) の 2 つである．適切名前 を選んだり，マジックナンバーに名前をつけたり，複雑な処理に名前をつけることがこれにあたる． クラス設計に関する原則は， 「クラスの役割は 1 つだけ」Single Responsibility Principle (SRP)， 「修 正なしで拡張可能に」Open-Closed Principle (OCP) の 2 つである．クラスは拡張に対して開いて いて，変更に対して閉じているが好ましく，抽象クラスやインタフェースを上手に活用することがこ れにあたる．クラスの関係に関する原則は， 「安定なものに依存する」Stable Dependencies Principle (SDP)， 「循環依存，相互依存を避ける」Acyclic Dependencies Principle (ADP) の 2 つである．変更 が発生しにくいクラス（安定的なクラス）に依存するようにし，相互依存を避けることがこれにあた る．これらの原則にのっとることにより優れたシステムの作成が可能となる．このような優れたシス テムを作成するため，いくつかの定石が存在する．それがデザインパターンである． 7 第 4 章 デザインパターン デザインパターンとは部品がどのように組み立てられているか，個々の部品がどのように関連して大 きな機能を果たすのかを表現したもの 3) ．デザインパターンの目標の 1 つは，プログラムを再利用可 能にすること．どうやってプログラムを「部品」として再利用するかを考えている．デザインパター ンを利用するメリットとして， • 開発者間のコミュニケーションが円滑になる • オブジェクト指向や設計原則の理解が深まる が挙げられる．現在，多くの開発者によってさまざまなデザインパターンが提唱されているが，本稿 では特に有名な GoF のデザインパターンを説明する．GoF の 23 のデザインパターンを Table. 4.1 に 示す． Table. 4.1 GoF のデザインパターン 種別 生成に関するパターン 構造に関するパターン 振る舞いに関するパターン パターン名 目的 Abstract Factory 関連する部品を生成するファクトリーごとに切り替える Builder 複雑なオブジェクトを生成する Factory Method サブクラスのメソッドにインスタンスの生成方法をまかせる Prototype コピーしてインスタンスを生成する Singleton 生成するインスタンスを 1 個に制限する Adapter インタフェースが一致しないクラスを再利用する Bridge 機能と実装の階層を分離し，拡張を別々に行う Composite 再帰的なオブジェクト構造を表現する Decorator 元になるオブジェクトを包み込んで機能を拡張する Facade 複雑な処理を呼びだすシンプルな入り口を提供する Flyweight インスタンスを共有して，インスタンスの生成コスト・使用メモリを抑える Proxy 代理（プロキシ）を用意してインスタンスの生成やアクセス制御をコントロールする Chain of Responsibility 処理を順番にたらいまわす Command 命令そのものをオブジェクトとして扱う Interpreter 構文解析の結果を表現するクラスを定義する Iterator 複数のオブジェクトに順番にアクセスする Mediator 複数のオブジェクトを集中管理する Memento オブジェクトの状態を保管して復元可能にする Observer オブジェクトの状態変化を通知する State 状態に応じて処理内容を切り替える Strategy アルゴリズムを交換可能にする Template Method 一連の処理の一部をサブクラスで実装し，変更可能とする Visitor 複数のオブジェクトを渡り歩く処理を追加・変更する このパターンを用いることにより，再利用性の高い柔軟な設計が可能となり，また開発者間のコ ミュニケーションも円滑になる．本章では特に Template Method，Singleton，Facade について説明 する． 8 第 4 章 デザインパターン 4.1Template Method 4.1 Template Method Template Method パターンは，テンプレートの機能を持つパターンである．つまり，スーパークラ スで処理の枠組みを定め，サブクラスでその具体的な内容を定めるようなデザインパターンである． これにより，スーパークラスのテンプレートメソッドでアルゴリズムの記述がされているので，サブ クラス側ではアルゴリズムを記述する必要がなくなる．例えば，Template Method を使わずに，コ ピー&ペーストで複数の Concrete Class を作ったとする．その中の一つでバグが発見された場合，コ ピー&ペーストなため，すべての Concrete Class に修正を行わなければならない．その点，Template Method パターンでプログラミングしていれば，テンプレートメソッドさえ修正すれば良い，というこ とになる．そのため，ロジックの共通化が行える．ここでは「文字や文字列を 5 回繰り返して」表示す るプログラムを例に Template Method を説明する．AbstractDisplay，CharDisplay，StringDisplay， Main の 4 つのクラスが登場する．その関係を Fig. 4.1(a) に示す． AbstractDisplay クラスの display メソッドには open メソッドを呼び出す，print メソッドを 5 回 呼び出す，close メソッドを呼び出すという処理を行っている．ここでいう display メソッドがテンプ レートメソッドに当たる．各メソッドは抽象メソッドになっているため，定義のみで実装はサブク ラスに任されている．サブクラスである CharDisplay クラス，StingDisplay では抽象メソッドであ る open，print，close の実装を行っている．Main クラスではこれまで作った CharDisplay クラスと StringDisplay クラスのインスタンスを作り，display メソッドを呼び出している．これを一般化して まとめると Fig. 4.1(b) のようなクラス図となる．Template Method パターンでは，AbstractClass （抽象クラス）と ConcreteClass（具象クラス）の 2 つのクラスがある．AbstractClass ではテンプレー トメソッドが実装され，ここで使われる抽象メソッドを宣言する．この抽象メソッドは，サブクラス である ConcreteClass によって実装される．ConcreteClass では AbstractClass で定義されている抽 象メソッドを具体的に実装する．ここで実装したメソッドは，AbstractClass のテンプレートメソッ ドから呼び出せる． (a) 文字・文字列表示のサンプル (b) Template Method パターン Fig. 4.1 Template Method パターンのクラス図（参考文献 2) を参考に自作） 9 第 4 章 デザインパターン 4.2Singleton 4.2 Singleton プログラムでは普通，多くのインスタンスが生成される．しかし，システムの中に 1 個しか存在し ないものをプログラムで表現したい時がある．例えば，コンピュータを表現したクラスやウィンドウ システムを表現したクラスなどである．そこで，指定したクラスのインスタンスが絶対に 1 個しか存 在しないことを保証したい場合や，インスタンスが 1 個しか存在しないことをプログラム上で表現し たい場合に Singleton パターンを用いる．Singleton クラスでは，static 変数として singleton が定義 される．それを Singleton クラスのインスタンスで初期化する．Singleton クラスのコンストラクタは private になっている．これは Singleton クラスの外からコンストラクタを呼び出すことを禁止するた めである．getInstance メソッドでは，Singleton クラスの唯一のインスタンスを得る． Fig. 4.2 Singleton のクラス図（参考文献 2) を参考に自作） 4.3 Facade プログラムはだんだん大きくなり，多くのクラスが作られ，相互に関係し合い，複雑になる．そう なると，これらの多くのクラスを適切に制御する必要が出てくる．その処理を行うためには「窓口」 を用意しておくのが適切である．それにより，たくさんのクラスを個別に制御しなくても，その「窓 口」に対して要求を出すだけで処理が可能となる．その「窓口」に当たるのが Facade パターンであ る．Facade パターンには Facade の役，システムを構成しているその他大勢の役，Client の役の 3 つ の役が必要である．それらの関係を Fig. 4.3 に示す．Facade 役は，システムを構成しているその他 大勢の役の「シンプルな窓口」となる．したがって，シンプルなインタフェースをシステム外部に提 供することが可能で，再利用しやすいというメリットがある．システムを構成しているその他大勢の 役は，Facade 役から呼び出されて，それぞれの仕事を行う．この役から Facade の役を呼び出すこと はない．Client の役は Facade パターンを利用する役である． (a) Web ページ作成のサン プル (b) Facade パターン Fig. 4.3 Facade パターンのクラス図（参考文献 2) を参考に自作） 10 参考文献 1) 中山清喬, 国本大悟. スッキリわかる Java 入門 第 2 版 (スッキリシリーズ). インプレス, 第 2 版, 2014. 2) 結城浩. 増補改訂版 Java 言語で学ぶデザインパターン入門. SB クリエイティブ株式会社, 第 23 版, 2015. 3) 中山清喬. スッキリわかる Java 入門 実践編 第 2 版 (スッキリシリーズ). インプレス, 第 2 版, 2014. 11
© Copyright 2024 ExpyDoc
