実践的オブジェクト指向設計入門24

　この記事は、実践的オブジェクト指向設計入門23の続きです。前回は、関連の設計について書きました。今回は、オブジェクトの表現について書きます。
　オブジェクト指向方法論OMTは、基本データ型を使う状況と、関係するオブジェクトを組み合わせで使うのはどんな状況なのかを、明確に定義しなくてはならないと説いています。ちょっとわかりにくいので噛み砕いて説明します。
　オブジェクトの属性を表現するとき、大まかにいうと、基本データ型（整数型、実数型、文字列型など）で表現するのか、特別なオブジェクトを定義して表現するのかの2通りの方法が考えられます。例えば、社員オブジェクトの属性・住所に使用する郵便番号は、文字列で表現できますし、オブジェクトでも表現できます。どちらが良いのでしょうか？こうした実装者の疑問に対し設計者は、明確に答えねばなりません。しかし、どちらの方法が良いのかは決まっていません。絶対の答えがないからこそ設計者の腕の見せ所なのです。絶対の答えがないというのが分かりにくいと思いますので、両方法についてちょっとだけ詳しく書きます。
　先程の例でいうと、郵便番号を文字列で表現すると簡単に扱えるように思うでしょう。しかし、実現するシステムにより、簡単か否かは変わってしまいます。社員の住所を表示するぐらいの処理しかなければ、文字列でも問題はないでしょう。ですが、郵便番号を解析して複雑な処理をするようなシステムならば、オブジェクトにしたほうが簡単に実装できます。すなわち、実現しようとしているシステムで可否が決まります。よくいわれる、設計のトレードオフの一つといえます。
　絶対に正しい答えというものがないので、設計者はトレードオフに対して、毅然とした態度で決定を下しましょう。もちろん、そこには設計思想がなければなりません。設計思想がないその場限りの決定は、現場を混乱に陥れるだけです。十分に注意しましょう。
　以上がオブジェクト指向方法論OMTの説明です。私個人の考えを付け加えます。日本の状況を考えると、この作業は余計な干渉のもとになるから注意する必要があると思います。日本では、プログラミングを知らない設計者がいます。そんな設計者がデータ型にまで口を出すと、プログラマーの仕事がやりにくくなるだけです。むろん、プログラミングを知らずとして正しい設計などできないと思いますが、日本の体制ではそうなっているので柔軟に対応するしかありません。
　それともう一つ注意するべき点があります。それは、プログラミングと設計の境が薄くなるという点です。もともと設計と実装は切り離された工程ではなく、数直線のように無限に途切れなく続くものですが、設計と実装の目的の違いを常に意識しなければなりません。やはり、設計と実装は違います。この作業（オブジェクトの表現を考える）をする際には特に注意しましょう。