豊田 孝
前回は，クラスとそれを構成するプロパティとメソッドを取り上げ，通常はソフトウエア開発をしない“普通の人々”の視点から，それら3者間に成立している関係を次のように定義しました。
“プロパティとメソッドは自分が含まれるクラスを具体的に表現する情報である”
前回はProperties.exeとMethods.exeという2つのサンプル・プログラムを紹介させていただきました。ダウンロードしていただけましたでしょうか？ また，実際に使用されたご感想はいかがでしたでしょうか？
必要な情報を取り出したい場合，対応するクラス名を入力しさえすれば，たちどころに関連情報が目の前の画面に表示されます。
Properties.exeとMethods.exeを使用すれば，使用しているコンピュータ・システムを構成する，例えば，OSやBIOS，あるいは，ネットワーク・プロトコルなどに関するさまざまな情報を表示させることができます。より多くの情報が利用できれば，私たちはそれらの製品に関する知識を深めることができます。
“情報”は日常的にはありふれた言葉の一つです。また，「情報公開」や「情報隠ぺい」といった言葉があることも知っています。情報隠ぺいは，オブジェクト指向プログラミングの世界では，カプセル化などと呼びます。情報という言葉をビジネス経営上の戦略として応用すれば，「情報戦略」という言葉になります。ご存知のように，情報戦略はどのようなビジネス・モデルでも重要な意味を持ちます。情報戦略なきビジネス・モデルは明らかに欠陥モデルであり，業績が悪化すれば，株主総会の場で，組織の先頭に立つ経営者は株主への申し開きはができなくなります。
情報戦略はビジネスをする上では必要不可欠です。これが真である限り，戦略としての情報は効率よく整理し，その発信には自社ならではの一貫性と整合性を持たせる必要があります。今回取り上げる“クラス継承”はこのような情報戦略作業に深く関与していると思います。
クラス継承の本格的な解説に入る前に，本連載ですでに紹介した次のようなクラス定義を思い出して下さい。
“類似したオブジェクトの構造と振る舞いは共通クラス内に定義できる”
“クラスは構造体と振る舞いを含んでいる”
“クラスはデータと動作で構成される”
クラス継承を定義してみる
クラス継承とは何か。素直に解釈すれば，クラス内容を継承する，ということになるでしょう。そして，本連載をここまでお読みいただいた皆さんは，クラスの内容をすでに熟知しています。具体的にいえば，継承対象となるのは，プロパティであり，メソッドであるといえるでしょう。ここでとっさに手を上げ，次のような質問を投げかける人が必ずいるはずです。
“クラスを構成するプロパティとメソッドは確かに継承対象であることは分かったが，いったいだれがそれを継承するのだろう”
|
| 図1 |
この図はすでに何度も紹介しているDTMFのWebサイトからダウンロードできるCIMドキュメントの一部です。図の中に，青い上向きの矢印の存在を確認できるかと思います。UMLでは，矢印が指している先に継承される側のクラスを配置し，その反対側にそのクラスを継承する側のクラスを記述することになっています。この図には次のような3個のクラスが描かれています。
・Person(人）
・Female（女性）
・Male（男性）
これら3個のクラス間の関係を文章にすれば，次のようになります。
“FemaleクラスとMaleクラスは，Personクラスの継承クラスである”
この説明文では，おそらく，通常開発作業に従事しない普通の人々の理解を得ることはできないでしょう。それでは，次のように説明文を変更してみることにします。
“FemaleクラスとMaleクラスは，Personクラスの情報を引き継ぐ”
ここで情報という言葉が出てきましたが，本稿冒頭では次のような一文を紹介しているはずです。
“プロパティとメソッドは自分が含まれるクラスを具体的に表現する情報である”
この一文の持つ意味を反映した文章を作成すれば，最終的に次のような文章が出来上がるはずです。
“FemaleクラスとMaleクラスはPersonクラスのプロパティとメソッドを引き継ぐ”
クラス，プロパティ，メソッドの関係はこれまでの連載ですでに詳細に説明してありますから，この一文を理解する上ではこれといった障害はないはずです。しかし，鋭い読者の方は次のような疑問をその胸の中に隠し持っているはずです。
“クラス継承は私たち普通の人々にどのようなメリットをもたらすのか？”
本連載はこの種の本質的な問いへの回答を用意するために起草されています。書き手としてはこの問いの前を，知らぬふりをして通り過ぎることはできません。
クラス継承は，クラスとクラスとの間の関係を示す用語であることはすでに説明したとおりです。この表現は表面上は何の問題も抱えていないようですが，次のような本質的な問いへの回答を無責任に隠ぺいしています。
“クラスとクラスの間に継承関係が成立するには，継承される側のクラスが存在しなければならないが，そのクラスは一体だれがどのような手順を踏んで作成するのか”
この問いへの回答はどのようなものでしょう。この問いへの回答を探す場合，次のような基本的な問いへの回答をまず探し出す必要があるのではないか，と私は考えます。
“クラスは一体だれのものか”
ソフトウエア開発作業を始点の方から眺めてみましょう。専門的には始点よりの開発段階を上流などといいますが，ここでは用語の定義の正確さは横に置いておきましょう。
まず，発注者の立場から言えば，クラスは発注者のものといえます。このような自覚を持たない発注者もいるかもしれませんが，そのような認識を持つことが何よりも重要です。また，それは発注者の責任であり，その人の仕事の中身です。
次に，アプリケーション・ドメインからクラスを探し出し，それを定義した開発者は，クラスは自分のものという意識が働きます。これはプロ意識の発現であり，当然のことでしょう。しかし，開発プロジェクトのリーダーの立場に立つと，すべてのクラスはプロジェクト・チーム全員の資産以外の何ものでもありません。
かくのごとく開発工程の作業者の立場によって，クラスへの思い入れが異なります。当然ですが，これは歓迎できることではありません。意志統一が図られていないのですから。私は次のように考えます。
“すべてのクラスはエンドユーザーのものである”
|
| 図2 |
理想としては，クラスは発注組織の経営者から開発工程の下流担当者までを含む関係者全員で作成する必要がある，といえると思います。それでは次にクラス継承の本質に迫ってみましょう。
継承される側のクラスの情報（プロパティとメソッド）は，継承する側のクラスに引き継がれます。これと似たようなことは，私たちが呼吸する現実世界にもあります。それは遺産相続です。遺産は通常は親から子に相続されますが，借金も相続の対象になります。すると，相続する遺産の情報（日常的には中身と表現しますね）が重要な意味を持っていることがわかります。これは，クラス継承でも，引き継がれる内容が重要であることを意味します。このため，クラス内容には，発注者の真意が開発チーム全員に伝わるような作業環境が作られていた方がよいに越したことはありません。私たちの社会でも，死後，自分の借金を愛する子に背負わせるようなことは，どの親でも望んでいないでしょう。その証拠に，世の多くの父母は，毎朝満員電車に揺られながら，あるいは，朝露の残るあぜ道を踏みしめながら，目的地まで努力しているのではないでしょう。私はある講演会で，“はたらく”，という言葉の意味は，“はたの人が楽ができるように努力することである”という解釈を聞いたことがあります。
クラス継承は，私たちがこれまでの暮らしをそのまま継続するために必要な情報戦略を根幹から支える考えです。これがクラス継承の最大のメリットです。次回は，私たちに身近な具体的な例をあげながら，クラス継承の意味とメリットをより具体的に考えてみたいと思います。また明日，お会いいたしましょう。ごきげんよう。
