📗

オブジェクト指向のこころ 第15章の振り返り

2024/04/04に公開

はじめに

みなさんこんにちは、やすのりです。

『オブジェクト指向のこころ』の15章を読み終わりましたので、
自身の理解度や考えをまとめるためにまとめ問題の回答を残しておこうと思います。
※『それは違うよ!』ということがあれば遠慮なくご指摘いただければ幸いです🙇

第15章 共通性/可変性分析

基礎問題

Q1. 共通性と可変性を洗い出すための2つのアプローチとは?

  1. ソフトウェア内の『概念』を洗い出し、その概念内に存在している『流動的要素』を見つけ出す。
  2. 問題領域の中から任意の言葉を2つ選択して、以下の質問を投げかけてみる。
    • いずれかは、もう一方の流動的要素なのか?
    • これらはいずれも、何かの流動的要素なのか?

応用問題

Q1. 共通性/可変性分析では、共通性はそれ自体が1つの関心事に基づいているべきであると述べているが、それは何故か?

設計の中で各々の凝集度を高めることができないため。

CAD/CAMシステムを例に挙げると、『CAD/CAMのフィーチャー』という2つの関心事が入った共通性を基にクラス設計をしてしまうと、作成されるクラスは以下になってしまう。

  • V1Slot
  • V2Slot
  • V1Hole
  • V2Hole

上記の場合、システムのバージョンアップや描画図形の増加が発生すると、その都度クラスが『バージョン数 × 図形数』分増え続けクラス爆発を引き起こしてしまう。

共通性を『CAD/CAMシステム』『フィーチャー』の2つにそれぞれ分けておくと作成されるクラスは下記になる。

  • Shape
    • Slot
    • Hole
  • CADCAM
    • V1
    • V2

これによりシステムバージョンアップの際は『V3クラス』を、描画図形の増加(今回は円形を追加してみる)の際には『Circleクラス』を作成するだけで対応できるようになる。


Q2. 共通性/可変性分析とデザインパターンは、どのように補完し合うのか?

【共通性/可変性分析】

  • 抽象的側面を早期から着目しているために、最も有益な設計を見つけ出しやすくなっている。
    • デザインパターンでは抽象的側面を洗い出す助けはできない。

【デザインパターン】

  • 成功裏に終わった過去の設計における洞察が適用できる。
    • 『Facadeは状態を保持させるべきではない』ということが過去の経験から判明している。
      その場合、状態保持機能をFacadeから切り出しAdapterに移すことができる。
      この考えは共通性/可変性分析だけでは得られない結果となる。
GitHubで編集を提案

Discussion