Java/C#の常識はOOPの非常識《予告編》
Java/C#プログラマーの中には、Ruby/Pythonによって提供される、洗練されたOOPの支援機能を使いこなせずに、戸惑う人も少なくありません。ここでは、今後の連載の予告編も兼ねて、いくつかの問題点を紹介します。
継承に警鐘を鳴らす
継承には（1）構造継承 （2）機能継承 （3）プロトコル継承があって、さらに機能継承は、次の3つに分類できます。
ともすると、Java/C#では（2a）に関心が寄せられがちです。しかし、Pythonに限らず、洗練されたOOPの支援機能が得られる世界では、その限りではありません。
たとえば、サイクロイドの事例では（2c）の機構を利用して、クラスCanvasPanelで定義されたpaintを再利用（継承）しながら、インスタンスごとに固有のpaintを再定義しています。そのお陰で、CanvasPanelの傘下には、アプリケーションごとに多数の子孫クラスを定義する必要がなく、迂遠なアプローチを回避できます。
Ruby/Pythonなどに象徴される、アジャイル言語が再評価されています。その開発環境下では、要求仕様が確定するのを待たずに、ソフトウェア開発に着手できる術が求められます。「仕様が決まらないと開発できない」という言い訳は、もう通用しません。また、UML/OCLが業界標準として普及していますが、アジャイル言語の進化に追いつけず、その脆弱さを露呈する場面に遭遇します。たとえば、サイクロイドの事例をUML/OCLで厳密に表現するのは、不可能ではないにしても困難が予想されます。
GoFは何を伝えなかったのか：Let's GoForward
GoFのデザインパターンは、図らずもJava/C#の脆弱さを露呈する結果となりました。Pythonに限らず、洗練されたOOPの支援機能が得られる世界では、いくつかのパターンは単純なイディオムにすぎず、言語によっては組み込みの機能として提供されています。また、GoFの事例を鵜呑みにすると、迂遠なアプローチを余儀なくされるばかりか、その洗練された特徴を活かせません。GoFを模写しても始まりません。GoFが模写したその起源を探ることで、パターンの本質に迫れます。
Java/C#からRuby/Pythonへと移行するプログラマーには、ひとつありがちな落とし穴があります。それは、GoFの例題に追従するあまりに「先祖返り」を余儀なくされ、洗練されたOOPの特徴が見過ごされてしまうことです。
この連載では、GoFデザインパターンを反面教師として、本物指向のOOPを目指す旅へと誘いざないます。GoFが何を伝え、何を伝えなかったのか。そのルーツを探ると、新たな知見が開けてきます。さあ、GoFより一歩前へ。Let's GoForward!
アナログ思考からディジタル思考へ
201X年のユビキタスネットワーク社会を控えて、ソフトウェアの賞味期限はさらに短くなる傾向にあります。価値観の多様化に伴い、少品種大量生産から多品種少量生産へと移ろい、環境の変化（市場のニーズ）に適応できないものから自然淘汰されます。
地デジ対応（2011年7月24日にアナログ放送は終了）を機に、液晶やプラズマディスプレイへの買い替え需要も加速しています。同様に、アナログ思考（Java/C#）からディジタル思考（Ruby/Python）へ世代交代となる過渡期に、際物でない本物指向のOOP言語への買い替え需要も加速しつつあります。
Eclipseが統合開発環境って本当ですか？
テストのパラドックスをご存知でしょうか。あるテストで不具合が見つかったとします。そのプログラムは不合格ですが、そのテスト仕様はバグを発見できたことで合格です。ところが、あるテストで不具合が見つからなかったとします。すると、そのプログラムは合格ですが、問題は解消されたのでしょうか。もしかすると、そのテスト仕様は「潜在的なバグを発見できない」不具合を抱えているかもしれません。このジレンマを抱えると、疑心暗鬼のまま一歩も前へ進めません。
「任意の数の和と積はつねに同じになる」という公式を発見したとします。そこで、この公式を検証するために、2つのテストケースを思い付きます。
- case #1: a=0 ⇒ a+a = a*a（両辺の値はともに 0 である）
- case #2: b=2 ⇒ b+b = b*b（両辺の値はともに 4 である）
テストには合格ですが、この公式が認定される…ということはありません。このように「そのテストをいつ止めてもいいのか」明確な指針を持たないなら、テストを何度繰り返しても、プログラムの正当性を保証できません。
テスト（力仕事）に頼らない、プログラムの正当性を検証するための形式手法が、再評価されています。形式手法の歴史は古く、1970年代まで遡ります。肉体派（テストファースト）から頭脳派へと転身したいなら、今からでも遅くありません。
あなたの母国語は何ですか？
プログラミング言語について「あなたの母国語は何ですか」と聞かれたら、迷わずSmalltalkと答えます。外国語を学び始めた頃は、まず日本語で考えてから、他の言語に置き換えていませんでしたか。私は、Smalltalkでオブジェクト「思考」してから、Java/Pythonなどに置き換えています。外国語で夢を見るようになれば本物と言われたりします。みなさんは、とっさの場合に何言語を使いますか。
ときにLightweight Languageと同じカテゴリーに分類されるSmalltalkですが、Ruby/Pythonとの決定的な違いをひとつ挙げるとするなら、つねに開発環境を意識した言語仕様（プログラミング言語と開発ツールとの統合）になっていることです。最近Ruby/Pythonのコミュニティーでも、Eclipse/Visual Studioのようなツールの寄せ集めではなく、真の統合開発環境を目指そうとする動きが見られます。先日、年金制度の破綻を予感させる報道に「欧米なら暴動が起こってもおかしくない」と述べる評論家がいました。Smalltalk-80/InterLisp-Dで育った人々が、Eclipseのような環境下での開発を余儀なくされたなら、それこそ暴動を起こしかねませんね。
単にプログラム（コード）を比較するだけでは、その本質に迫ることはできません。開発環境が進化するなら、プログラミング（過程）も進化します。プロダクト指向からプロセス指向への扉を開いて、伝統的な開発環境（コード作成、コンパイル、実行、デバッグ…の繰り返し）から脱すると、新たな展望が見えきます。Java/C#のトレンドが、他のコミュニティーでは、何年前、何十年前に実践されてきたかを知るなら、呑気に構えてはいられません。村夫子と呼ばれないためにも、今がその好機です。
