オブジェクト指向設計の説明
職場のやりとりの中で、オブジェクト指向を知らない上司にオブジェクト指向を説明する羽目になった。
たとえ話で説明したのだけど、なかなかうまくいったように思う。上司にも「わかりやすい！」と感謝してもらえ、かつマイmixi限定でやりとりを公開したら結構好評で、わたくしカナリゴキゲン（←アホ）なので、ここにもやり取りを残しておくことにする。うほ。
やりとり
上司「なんで継承構造が複雑だと問題なの？」
自分「（継承を駆使した(※)）オブジェクト指向設計のメリットは2つです。1つは、実作業者をある種のカタにはめられること。もう1つは、機能を共有できることです。」 （※: テンプレートメソッド的なイメージを持っていただければ。）
自分「たとえると、ビジネスフォームみたいなものです。たとえば、契約書とかで、本文には「甲が乙に・・・の義務を負う」みたいなヤツありますよね？ 甲の部分を変えれば別の契約書になりますし、逆に言えば、ソコしか変えることが出来ないので、いわゆるカタにはめる格好になります。そして肝心の契約本文は共有できるので、契約を起こすたびに文面を考える必要はありません。継承を多用したオブジェクト指向設計っていうのは、こんな感じなんです。」
上司「ふーん、いいじゃない。」
自分「ですけど、問題点もあるんです。」
上司「何？」
自分「たいていの開発の場合、契約書テンプレートを作る人と、テンプレートを埋める人は別の人なんです。そして、継続してメンテナンスしないといけない。しかも、契約書の場合と異なり、両者は常に整合性をもっていないとイケないんです。 たとえば、法律の改正があって、契約書を修正しないといけないとしましょう。契約書の場合だと、テンプレートを修正して終わりですけど、ソフトウェア開発の場合だと、そうはいきません。現実の契約書テンプレートとは異なり、契約書テンプレートを修正すると、この契約書テンプレートを元にして作った契約書も全部修正されちゃうことになるんです。去年作った契約書も全部です。」
上司「あー」
自分「しかも、この(イケてない)協力会社がつくったソースの構造は複雑で、契約書にたとえると、契約書の本文に、「～の詳細については、・・・を参照」みたに契約書の構成が複雑で全貌を容易につかめないような感じなわけです。 これを将来的にメンテナンスしていくのは大変ですよ。」
上司「なるほどねー」
てな具合。
