OOSCより

22章 クラスの見つけかた

適切でないものをクラスとして扱ってしまう場合がある

これは「あるシステムにおいてどういう概念をクラスとして扱えば良いのか」という問題についての話題だが、クラスとなり得るものの候補を挙げることよりも、多くの候補の中から適切なものを選択する方が、多くの場合においては難しい。適切かどうかの基準はシステムによって変わるので、あるシステムにおいてはクラスとして扱うのが適切だが、他のクラスにおいては適切ではないという場合がある。例えば、エレベーターを制御するシステムにおいての「ドア」は、クラスとして扱ったほうが良い場合とクラスとして扱わないほうが良い場合とがある。

オブジェクトとクラスを混同している例

Cityクラスを継承したNewYorkクラスとSanFranciscoクラス。

23章 クラス設計の原則

抽象的な副作用を禁止すべき

まず参照透過性と呼ばれる性質があり、これは平易に言うとある2つの値を交換しても結果が変わらないようなときに参照透過性が保たれていると言えるというもの。参照透過性が保たれていると数学における様々な法則を適用できるという利点がある。しかしながら、ある値に関する処理の中に副作用が存在すると一般的には参照透過性が失われてしまうと言われる。副作用の中でも抽象的な副作用と具象的な副作用があり、公開されているクエリ(クエリというのはある種の処理のことで、副作用が無く必要に応じて何かの値を返すだけの処理のことを指す)の結果を変更することになるものが抽象的な副作用であり、公開されているクエリの結果を変更しない副作用は具象的な副作用と呼ぶ。OOSCの著者の主張は「抽象的な副作用は禁止すべき」というもので、具象的な副作用は実質無害なので許しても良いとしている。

24章 継承の上手な使い方

継承関係は実行時に変更できない

is-aとhas-aの関係のどちらを使うべきかについて、関係が実行時に変更されるかどうかについての基準が考えられる。is-a(継承)は「クラス間の関係性」を表現するが、クラス間の関係性は(これが実行時に決定されるシステムもあるが)実行時ではなくシステム自体が持つ特性と考えられるので、実質実行時に変更することはできない。例えば、EngineerはPersonクラスの子クラスとして表現されるべきだろうか。それとも、PersonクラスのプロパティとしてEngineerを表す要素を持つべきだろうか。