« 建国記念日 | メイン | 2月16日 »

2005年02月12日

なぜオブジェクト指向か

いつもみてるブログなぜオブジェクト指向かという記事があったので、ボクもなぜオブジェクト指向か考えてみた。たまにはここは技術系プログラマによるブログだということを再確認しなくてはならない(謎)。

以前たまたま読んだ、結城浩さんの2004年7月4日の日記の、

そのように「共通なところは何か」「違うところは何か」を考えてプログラミングする。共通なところは全部共通なプログラムにする。

という一文に大衝撃をうけた。オブジェクト指向の重要な点はこれだと、ようやく理解した。それにしてもなんたる英才教育。。プログラミングにおいて重要なのは、共通部分を共通なプログラムにすることであり、オブジェクト指向はそれを意識して設計できるのがいいところなのだ。だから、共通部分のすくないようなところではあまり意味がなく、オブジェクト指向は戦場では必要なしというのも一理ある。とはいえほとんどのプログラムにはなんらかの共通点があるものだ。

ボクはだめぽプログラマであるので、ながらくオブジェクト指向がなんの役に立つかわからなかったし、いまも完全には理解できていない。それはどうやらC++をずっと使ってことに原因があり、最近Small TalkやRubyを触れてみてようやくその一端をつかんだ感じだ。よくオブジェクト指向の特徴で「データの隠蔽」「カプセル化」などがいわれるが、これらは副次的なもので、本質的なものではないんでないかと思うようになった。こういった解説と、C++のとってつけたようなオブジェクト指向がボクの理解を妨げていたのだ(たぶん)。

さて、オブジェクト指向プログラミングが構造を抽象化するものだとしたら、処理を抽象化するのがジェネリックプログラミングだろう。しかし、残念ながらボクはジェネリックプログラムをまったく理解しておらず、使いこなせるようになるにはあと5年はかかりそうだ。そもそもボクにはC++のテンプレートの記法がノイズにしか見えないのだ(謎)。。

オブジェクト指向プログラミングとジェネリックプログミングに関してはSmall Talkがすばらしい。C++やJavaにあるこれらの機能は、なんだかとって付けたようにしかみえないが、Small Talkではとても自然にこのふたつが融合している。だからだめぽプログラマなボクもここではなんとか救われる。Small Talkを開発したアランケイは、-おそらく彼の分子生物学の知識からのアナロジーで-、それぞれ共通点をもち、かつそれぞれ差異をもつようなオブジェクト同士がたがいにやりとりするようなシステムを構築しようと考え、そのためにオブジェクト指向を選択したようだ。たしかにこのようなシステムにはオブジェクト指向はうってつけだ。

ところで、オブジェクト指向の「クラス」と「インスタンス」という考え方は、なんとなくプラトンの「イデア」説がもとになっているのではないかと思っていた。西洋人のこうした思考方法が、脈々と積み重なってオブジェクト指向を生み出したのだとしたら、ちょっといい話だ(適当)。そうすると、対象を対象としてみる東洋的な考え方からは、オブジェクト指向は理解しにくい。ボクがオブジェクト指向を理解するのに苦しんでいるのもだからなのだ。と強引に結論付ける。

投稿者 osa : 2005年02月12日 10:09

コメント

気の効いたコメントではありませんが,持論をば。

単に大域空間を分離する目的でも,OOP(オブジェクト指向プログラミング)は有効かと思われます。
従来のOOPに則らない言語,例えばBasicやC言語は何がマズかったのかというと,「変数」や「手続き関数」と呼ばれる存在が一つのだたっぴろい名大域空間の中にごっちゃまぜになっていたという点です。(C言語は構造体があるので,完全にOOPがないとは否定できませんが。)
初代のBasicにはとにもかくにも「手続き関数」という概念すらありません。行番号・スタック・変数が在る程度です。そのBasicでゲームを作ろうものなら全ての操作,例えばデータの読み込み,キー入力,思考,画面への出力等の処理内容と変数群を一つの大域空間に表現していました。
Basicでやるように,OOPがなくともゲームは作れます。しかしそれは大概一人の人間が作る,他の人には管理不能な巨大なプログラムになるでしょう。何故ならすべてがごっちゃになって,単純に判りにくいからです。わたくしも実際そんな類いの問題作品を多数作りました。

ではOOPをうたっているC++やJavaは何を解決したのでしょう。
わかり易く言うと,「大域空間」を沢山つくる方法を上手に導入した点でしょう。いままで一つの大域空間に「手続き関数」やら「変数」を押し込んでいましたが,OOPでは,それは一つではありません。クラスの数だけ大域空間のようなものが存在することになります。実際そうでしょう。何かの目的の為に新しい空間を作って,プログラムを構築する。他の空間がどう在ろうとも直接は関係ありません。クラスの性質上,他のクラスと結合することもあるでしょうが,独立性だけをうたっているこのコメントでは,それは重要ではありません。

いま3dsを読み込むテストプログラムをC++でスクラッチしています。3dsを読み込むクラスは,そのプログラムの中で何かの共通部分を以ってクラス化している訳ではありません。単に「3dsファイルを読み込む目的の関数・変数を集めた大域空間」を作っているだけなのです。そしてこのクラスが完成すれば,別のプログラムに組み込んで使うことだってできるでしょう。3dsを読み込むクラスとテストプログラムは別の空間に居ますので,分離は問題なくできるという考え方です。

このようにOOPは共通化だけではなく,問題の切り分けに使う場合もあるかもしれません。

投稿者 欄炭士 : 2005年02月15日 03:16

ほうほう。たしかに問題を局所化できるというのは、OOPの実利的な強さのひとつですね。ちなみに、ボクのいう共通化というのは、たんに継承を意味するわけではなく(もちろん継承も含みます)、

「共通なところは何か」「違うところは何か」

というのはつまりは問題領域の切り分けのことであり、ランタソさんの意見と矛盾するものではないです。

ともうちょっと書こうと思ったんですが、眠いのでまた次の機会に。。

投稿者 おかね : 2005年02月16日 00:13

コメントしてください




保存しますか?