読者です 読者をやめる 読者になる 読者になる

【オブジェクト指向のこころ】第1章 オブジェクト指向パラダイム 解答

オブジェクト指向のこころ 第1章の練習問題の解答をまとめてみる。

基礎

機能分解の基本的なアプローチを解答してください。

機能分解では、問題を小さな機能にブレークダウンすることで、その問題を構成する機能要素の洗い出しを行う。 このアプローチだと、将来の変更に対して柔軟に対応するのが難しくなる。 (p.4)

要求の変更を引き起こす3つの理由とは何でしょうか
  1. ユーザが開発者と議論することで、ユーザがソフトウェアの新たな可能性に気づき、自らのニーズを変更すること
  2. ソフト開発の進展に伴い、開発者による問題領域に対する理解が深まるので、開発者の考え方が変わってくること
  3. ソフト開発の技術的な環境が変化すること (p.6)
機能に着目するよりも責任に着目するほうがよいとされています。これはどういった意味を持つのでしょうか?例を挙げてみてください。

何が行われるか(機能)についてまず考えるのではなく、行われることに対する責任はどのルーチンが持つかに着目するということを意味する。 この場合、制御プログラムはシンプルになる。 (p.12)

結合度(coupling)と凝集度(cohesion)の定義を答えてください。結合度が高いというのはどういうことでしょうか。

結合度とは、2つのルーチン間の結合の強さを表す尺度 凝集度とは、ルーチン内の演算(operation)がどれだけ密接に関連しているかを表す尺度。 (p.8)

オブジェクトにとってのインターフェースの目的は何でしょうか?

インターフェースは、他のオブジェクトに対して公開しているメソッドを提供する。 (p.17)

クラスのインスタンスの定義を答えてください。

各オブジェクトのユニークな実体のこと。 オブジェクトはクラスのインスタンスである。 (p.14)

クラスとはオブジェクトの完全な振る舞いを定義したものです。オブジェクトが定義する3つの観点とは何でしょうか。
  1. 該当オブジェクトの保持するデータ項目についての情報
  2. 該当オブジェクトが実行できるメソッド
  3. これらのデータ項目やメソッドにアクセスするための方法(インターフェース) (p.14)
抽象クラスとは何を行うものでしょうか?

概念レベルから見た場合、抽象クラスとは、それが表現している概念を具体化したクラスの実装を格納するための場所(placeholder)を提供するもの。 抽象クラスによって、関連のあるクラス群に名前を割り当てる方法が与えられ、関連のあるクラス群を一つの概念として扱えるようになる。

実装レベルから見ると、抽象クラスとは実体化されることがないクラスのこと。 (p.16)

オブジェクトが保持できるアクセス可能性にはどのようなものがあるでしょうか
  1. public
  2. protected
  3. private
カプセル化の定義を答えてください。また、振る舞いをカプセル化する例を挙げてください。

カプセル化とは、あらゆる種類のものを隠蔽すること。 データとふるまいもカプセル化されうる。 (p.17)

ポリモーフィズムの定義を答えてください。また、ポリモーフィズムの例を挙げてください。

同じ呼び出しでも、異なる動作が行われること。

講師が学生に「次の教室に行ってください」と指示を出したときに、学生の種類によって異なる移動先や移動方法をとるなど。

オブジェクトを考える際の3つの観点とは何でしょうか?
  • 概念
    • システムの高位の概念を表現したもので、「私は何に対して責任があるのか」という質問に答えるもの。 概念レベルにおいて、オブジェクトは責任の集合となる。
  • 仕様
    • ソフトウェアのインターフェースで「私はどのように使用されるのか?」という質問に答えるもの。仕様レベルでは、オブジェクトはメソッドの集合となる。
  • 実装
    • 各ルーチンはどのように動作するかを示すもので「私はどのようにして自身の責任をまっとうするのか?」という質問に答えるもの。実装レベルでは、オブジェクトはコードとデータとなる。

応用

プログラマソースコードを分割する際に「モジュール」というものを使うことがあります。これは要求の変更に取り組む効果的な方法でしょうか。答えとその理由を述べてください。

モジュールはルーチンに依存している。 通常、ルーチンは独立していないため、あるルーチンへの変更は、他のルーチンに影響を及ぼすことがある。 したがって、ルーチンに変更要求があると、モジュールにも変更の必要があるため、効果的でないと考えられる。

抽象クラスは実体化されないクラスであるというのは、あまりにも限定された定義です。この定義が限定されている理由は何でしょうか。抽象クラスに対するより優れた(または少なくとも代替となる)考え方はどのようなものでしょうか?

実装レベルでしか捉えられていないため、限定的な定義となってしまっている。概念レベルでの見方を無視している。概念レベルでは、抽象クラスは、関連するクラス群に、実装を格納するための場所(placeholder)を提供する。 抽象クラスによって、関連のあるクラス群に名前を割り当てる方法が与えられ、関連のあるクラス群を、詳細まで踏み込まずに一つの概念として扱えられるようになる。 (p.16)

振る舞いをカプセル化することによって、要求の変更から引き起こされる影響をどのように制限できるのでしょうか?どのようにすれば、好ましくない副作用からプログラマを守ることができるのでしょうか?

振る舞いをカプセル化することによって、振る舞いに対する責任を持たなくなった制御プログラムは単純化される。それにより、オブジェクト内部への変更はアプリケーションの他の部分への影響を小さくできる。 (p.21)

オブジェクトを他のオブジェクトの変更から保護するために、インターフェースをどのように役立てることができるでしょうか?

インターフェースは、他のオブジェクトが、該当オブジェクトとやり取りするための唯一の方法を定義している。そのため、他のオブジェクトの変更をインターフェースで捉え、該当オブジェクトの内部への変更を防ぐことができる。

セミナー会場となる教室の例を使って、システムにおける解説をしました。概念の観点からこの教室を解説してください。

教室は学生を保持している。そして各々の学生は自身の振る舞いに責任を持っている。ここからあそこへ移動する方法や、授業から授業へ移動する方法などの振る舞いは学生が責任を持つ。それらの振る舞いを指示するのは、先生だ。

yusuke-ujitoko.hatenablog.com