豊田　孝

　.NETの世界では，数千にも及ぶクラスが事前に定義されています。そして，それらすべてのクラスは，ある特定のクラスの性質を受け継ぐように定義されています。次回からはいよいよ.NETクラスを実際に使用していくことになりますから，今回は，これまでの連載内容を「関数からクラスへの変化」という視点から振り返るとともに，第2回連載から紹介してきたサンプル・プログラムを，関数ではなく，クラスを使って書き換えます（サンプル・プログラムのダウンロードはこちら）。「関数からクラスへ」の変化では，「発想の転換」が求められますが，それはいったいどのような発想の転換なのでしょうか？また，発想の転換の意味を理解しておくと，どのようなメリットが得られるのでしょうか？それでは，本論に入りましょう。

関数からクラスへの変化の意味

　前回の連載で明らかになったように，ANSI C準拠のサンプル・プログラムを「.NET対応プログラム」に変換すると，それまでの「関数」は「メソッド」と呼ばれるようになりました。メソッドはオブジェクト指向の世界を支える概念の一つですが，この名称変更は，次のようなことを私たちに教えてくれています。

“関数もクラスもこれまで通り「再利用部品」であることに変わりはない。しかし，関数の所有者がOSと密接に関係しているWin32プログラムであったのに対して，メソッドの所有者はクラスとなった”

　この文章をじっくり読むと分かるように，従来の関数に相当するメソッドとWin32プログラムの間にクラスが介在するような構図になっています。第1回で触れたように，.NET世界のクラスはインターネット空間に提供することができます。「インターネット空間に提供されるクラス」という視点からこの構図を見ると，クラスがWin32プログラムをインターネットから隠ぺい（あるいは，抽象化）しているということになります。このため，次回以降の連載で説明しますが，これから作成するC++クラスと，次回作成されるC#クラスの間にはたいへん興味深い相違があります。現時点では，クラスは次のように分類できる，とのみ述べておきます。

“クラスには，管理されるクラスと管理されないクラスがある”

　この意味を具体的に理解したい方は，今回の連載を最後までお読みください。.NETの世界は，クラスをベースとするオブジェクト指向の世界であるだけではなく，クラスの概念そのものを再考し，戦略的に活用している世界でもあるのです。より詳細については次回以降取り上げるとし，これまでのサンプル・プログラムを「関数からクラスへの変化」という視点から書き換える作業に入りましょう。

連載名と連載回数を表示するのはだれか？

　第2回では，次のような機能を実装するサンプル・プログラムを紹介いたしました。

“連載名と連載回数を表示する”

　この文章には主語がありません。連載回数を表示するのは，いったいだれでしょう？“この文章に主語を追加してください”と言われた場合，多くの人は次のような主語を追加するのではないかと思います。

  • このプログラムは，連載名と連載回数を表示する
  • 開発者である私は，連載名と連載回数を表示する
  • 私が作成した関数は，連載名と連載回数を表示する

　この3つの文章のいずれかが正しいということではありませんが，少なくとも，大きく的を外しているとはいえないでしょう。しかし，これらの文章には次のような共通点があります。

“これらの文章はすべて開発者の視点から記述されている”

　表示する対象が連載名であれ連載回数であれ，表示機能の実装は，経験を積んだソフトウエア開発者にとっては簡単な作業です。しかし，その機能が実際に使用するユーザーの要求を満たしているかどうかということになると，それはまったくの別問題といえます。

　つまり，表示機能をプログラム内の“どこに，どのように実装するか”という視点は，あくまでも開発者の視点であり，ユーザーの要求を満たすための視点ではありません。また，インターネットが普及している現状を考えると，開発した表示機能がWebアプリケーションの一部であるような場合，その機能は，実際に運用されていく過程の中で，さまざまな要因により，変更されることも多々あると思います。

　プログラム開発を開発者の視点とユーザの視点から眺めると，次のような重要な点が浮かび上がってきます。

“プログラム開発で重要なのは，ユーザーの要求を理解した上で効率的に開発作業を行うことである。しかし，インターネット人口が急増した今，インターネットからの要求を，一様かつ正確に，定義することはできない”

　この文章は，ユーザ要求を理解することの重要性と，要求自体の定義ができない，あるいは，少なくとも，一度定義した要求が変化してしまう時代の到来を教えてくれています。それでは次に，このあたりの事情をより具体的な場面を想定して考えてみます。

求められる発想の転換

　ここでは，私の友人の1人が，「連載名と連載回数を表示する」プログラムを作ってくれるように依頼してきたとします。私ならまず，以下のような行動を取ります。

  • 本人に直接会い，要求内容の説明を受ける（ヒアリング）
  • そして，本人自身も要求内容を理解していないことを確認する（要求変更と機能拡張への備え）
  • さらに，ヒアリングの結果を文章化して電子メールで送信する（ドラフト提案書の作成）

　おそらく以下のような文章を用意すると思います。

“あなたは，どこかの雑誌から連載を頼まれた。連載名以外はまだ決まっていない。しかし私が考えるに，連載というものは，最低限，連載名と連載回数というデータ項目を持っているはずである”

　これは失笑を買うほどの文章ですが，しかし，次のような点をはっきりさせてくれます。

“連載は，連載名と連載回数という「属性」を持っている。このため，常識的に考えれば，それらを表示する「操作」も必要である”

　この文章は，表示機能をプログラム内のどこに，どのように実装するかという，どちらかといえば，プログラムの構造ではなく，依頼人の問題領域（この場合，連載作業の管理）の構造の1つを示しているといえます。このため，この構造を定義し，その定義内容をプログラムにそのまま反映することができれば，少なくとも，ユーザーの要求を満たすことができます。このような場面で威力を発揮するのが，クラスといわれます。私は次のようなクラス（リスト1）を用意してみました。

リスト1●クラスのソース・コード
class Rensai : public RensaiBase
{
private:
　string strRensaiName;
　string KaishaName;
　int Kaisuu;

public:
　static void compilerinfo(void);
　Rensai(){};
　virtual void setRensaiName(string RensaiName);
　virtual void getRensaiName(void);
　virtual void setKaisuu(int Kaisuu);
　virtual void setKaisha(string name);
};

図1●サンプル・プログラムの実行結果
　ご覧のように，Rensaiというクラスを定義し，連載というものの構造を定義しています。関数を使用した第2回のサンプル・プログラムは，このような構造を定義していませんでした。クラス構造の定義内容，つまりヒアリング結果の解釈と分析は，主観や感受性，あるいは個性が入リ込むため，開発者によって異なるのが自然です。ソース・コードに興味のある方はプロジェクトをダウンロードし，クラス構造を自分なりに再定義してみてください。将来の変更や拡張に備え，“継承”などのオブジェクト指向の概念も取り入れています。参考のために，実行画面を示しておきます（図1[拡大表示]）。

　それでは，これまでの説明内容を次のように整理しておきましょう。

  • 開発者の視点からユーザーの視点への発想の転換が必要である
  • ユーザー要求は定義できない，あるいは，一度定義した内容は変更され得る，という発想の転換が必要である
  • 関数の所有者はプログラムであるが，メソッドの所有者はクラスである
  • クラスは，問題領域の構造を記述するために使用すると便利である
  • 問題領域の構造を理解するためには，ユーザーとのコミュニケーションが必要である

　冒頭で触れたように，.NETクラスはインターネットにも公開されるという役割を持っています。このため，同じクラスという概念で語られるとしても，本日作成したRensaiクラスとはかなり異なる性質をもっているのではないかと予想されます。次回は，本日のサンプル・プログラムをC#プログラミング言語に移植してみます。.NETのクラスはどのような性質をもっているのでしょうね。楽しみなところです。

　それではまた次回お会いいたしましょう。ごきげんよう！