OOSC 1、2章

DDDを理解するためにOOSCを読み直すことにしたので、自分宛に感想や連想をメモしていきます。

今日は、1章と2章。

正確さと機能性を区別する

この本が外的品質要因で最も重要なものとする「正確さ」(p.4)は、「機能性」とは別の性質である。

自分は両者を混同していた。というのも、JUASの非機能要求指標の機能性に、「実行時の機能として正しく実装されている要求の割合」が含まれているので、その先入観があったため。機能として正しいかどうかは、正確さに近い概念だと思う。

OOSCでは、機能性を「そのシステムが提供できるサービスの範囲」と定義している。(p.15)

互換性の鍵

p.10から引用。

互換性の鍵は、設計が同質であることと、プログラム間のコミュニケーションの標準的規約が一致していることにある。

後者は理解できる。問題は前者で、設計が同質とはどういう状態か。

最近、古いシステムを新しい設計で移植していて、古いストアドプロシージャを引き続き使うかどうかについて議論になった。このストアドプロシージャには、いくつかの問題があった。

  • 相互に関係のない独立した複数の処理を、内部に持っている
  • どの処理を使うかは、呼び出し時のパラメータによって決定する
  • その用途のために、パラメータが大量に定義されている

このストアドプロシージャを呼び出すには、新しい設計に則った呼び出し側のコードを、古い設計に基づく実装に戻さなければならない。それはいやだ。いくらパラメータと戻り値のインタフェースを揃えても、呼び出し側とストアドにはもはや互換性があるとはいえない、というのが自分の意見だった。

たとえば、"設計が同質でない状態"というのは、そういう話なんだろうか?

抽象クラスを使うべき局面

2章では、「オブジェクトらしさ」を評価する基準が列挙される。身近なオブジェクト指向言語の仕様との対応を思い浮かべながら読むと面白い。

最近インタフェースにデフォルト実装が入ったJavaについて、「インタフェースと抽象クラスの違いがなくなった」という冗談を言った|聞いたことがあるけれども、インタフェースではなく抽象クラスを使うべき局面は厳然とあるはず。

オブジェクトらしさの基準の1つである「暫定(deferred)特性と暫定クラス」(p.38)を学習することで、その点も理解できるようになることを期待している。