📗
オブジェクト指向のこころ 第11章の振り返り
はじめに
みなさんこんにちは、やすのりです。
『オブジェクト指向のこころ』の11章を読み終わりましたので、
自身の理解度や考えをまとめるためにまとめ問題の回答を残しておこうと思います。
※『それは違うよ！』ということがあれば遠慮なくご指摘いただければ幸いです🙇
第11章 AbstractFactoryパターン
基礎問題
Q1. switchは、処理の選択を行う際に使用できる機能ですが、この章で考察したデバイスドライバの例では問題が引き起こされています。
- どう言った問題が引き起こされるのか？
- switchによってどう言ったニーズが示されているのか？
A:
- 問題
-
高い結合度
『デバイスドライバを使用した形状の描画 or 印刷』という実行処理の中に
『低解像度・高解像度どちらのデバイスドライバを使用するのか？』という判定処理が入っている。 -
低い凝集度
コードの結合度が高いため判定処理に修正が必要となった際[1]に、本来無関係な実行処理のコードを修正しなくてはいけない。
-
- ニーズ
- クライアント側の事情(マシンスペック[2])によって、使用するデバイスを変更したい。
Q2. このパターンは、どうして『Abstract Factory』と呼ばれているのでしょうか？
A: 抽象化で定義されたオブジェクト自体を生成するファクトリだから。
Q3. Abstract Factoryにおける3つの概念的手順とはなんでしょうか？
A:
- 『流動的要素』を見つけ出して、その要素をカプセル化する。
今回の事象だと『使用するデバイスドライバ』がマシンスペックに依存(流動的要素)していますので、デバイスドライバをカプセル化。 - 『クラス継承』よりもオブジェクトの集約を多用する。
これは本書でも口酸っぱく言われている事柄で、第9章の振り返りでも意見を述べた部分なのでそちらをご確認ください。[3] - 『実装を使用した設計』ではなく、『インタフェースを使用した設計』をする。
クライアント側は処理の具体的な実装方法を知らずに、
具体的な実装を提供しているインタフェースの利用方法だけ知っていれば良いように設計する。
この考えによってクライアント側のコードの結合度を低下できる。
Q4. このパターンではん、2種類のファクトリが存在しています。
- AbstractFactoryとは何をするものなのでしょうか？
- ConcreteFactoryNとは何をするものなのでしょうか？
A:
- AbstractFactory
- ファクトリの抽象クラス
オブジェクトを生成するためのメソッドを定義するインタフェースの役割
- ファクトリの抽象クラス
- ConcreteFactoryN
- ファクトリの具象クラス
実際に使用するオブジェクトを生成(実体化)するための役割
- ファクトリの具象クラス
Q5. Abstract Factoryパターンの因果関係とはなんでしょうか？
A: 『どのオブジェクトを利用するのか？』という条件や『決定したオブジェクトの利用方法のロジック』を分離できる。
応用問題
Q1. GoFは、Abstract Factoryパターンの目的として『関連、または依存しあうオブジェクトのファミリを、その具象クラスを指定することなしに生成するインタフェースを提供する』と述べています。
- この意味を答えてください。
- 例を挙げてください。
A:
- 意味
- 関連オブジェクトを生成するためのインタフェースを提供することで、
クライアント側が具体的なクラスを把握していなくても必要なオブジェクトを生成・利用できるようになる。
- 関連オブジェクトを生成するためのインタフェースを提供することで、
- 例
- 業務用チャットアプリでライト・ダークという2つのテーマがある。
両方ともそれぞれの外観のコンポーネントが実装されているが
クライアント側ではどちらのテーマを使用するかさえ選択すれば、選択したテーマの外観コンポーネント群が生成される。
- 業務用チャットアプリでライト・ダークという2つのテーマがある。
最後に
この章を読んでいてこれはしっかり覚えておかないとないう一文がありましたので、その文もここに記して終わりたいと思います。
switchは抽象化の必要を示す赤信号となり得る
すべてがそうではないにしろ、switch文を使用していたら抽象化できるのか一考してみても良いかもしれませんね。
Discussion