オブジェクト指向言語を利用した開発が当たり前になり，早くもポスト・オブジェクト指向言語は何かという話題も出ているようだが，先日，具体的に今後の技術の一つの方向性を示す話を聞くことができたのでご紹介したいと思う。それは動的なオブジェクト指向言語のRubyと，静的なオブジェクト指向言語のJava，それぞれのフレームワークについての話だったのだが，意外なほど目指している方向性が近いようだ，と確認したということである。
　結論を先に書くと，ソフトウエアの動的に決定したい部分を設定ファイルのようにソース・ファイルの外部に置かれる構成要素で解決するのではなく，言語とフレームワークの機能を利用してソース・ファイルの︵文字通り︶行間を補完することで解決するという方向だ。
　去る2005年5月23日に，筆者は有志による﹃エンタープライズ アプリケーションアーキテクチャパターン﹄︵マーティン・ファウラー，翔泳社 ISBN: 4798105538︶読書会に参加した。その日のテーマは，各種O/Rマッパーに関するアーキテクチャ・パターン︵注1︶についてだったのだが，関連する話題として日本Rubyの会の高橋征義会長からRuby on Rails︵注2︶におけるActiveRecord︵注3︶についての解説が行われたのが始まりである。
　Ruby on Railsは，プログラミング言語Rubyを利用したWebアプリケーション・フレームワークで，デンマークのDavid Heinemeier Hansson氏が中心となって開発している。徹底して無駄を排除した合理性が特徴である。具体的には，プログラムの持つメタ情報を有効活用すること，プログラムの命名規約を活用すること，設定を外部に出さずにプログラムの中に記述することで，規模の大きなソフトウエアに不可欠となる設定ファイルを可能な限り不要化することである。また，多分にプロモーション的な意味合いもあるのだろうが，Javaより10倍以上生産性が高いといった言い方でWebアプリケーション開発で主流となっているJavaの方法論への対決姿勢を打ち出している。そのため，Java開発者との間でフレーム︵論争︶が巻き起ったりもしている︵注4︶。
　高橋氏によれば，この10倍という数は先にも触れたように多分にプロモーション的な数字であり，実際のプログラムの行数はJavaと比べてそれほど違わないとのことだ。しかしソフトウエア全体として見た場合には確かにそれ以上の差がついている個所があるという。具体的には，Ruby on Railsの技術的な特徴である設定ファイルの排除が挙げられる。
　Javaの典型的なWebアプリケーションを例にすると，Tomcat＋Struts＋Spring＋Hibernate のようなオープンソース・ソフトウエアを利用した開発であっても，EJBをコアに置いたベンダー提供のアプリケーション・サーバーを利用した開発であっても，多数のXMLによる設定ファイルが必要になる。これは，強い型付けであらかじめコンパイルされる静的言語であるJavaで，実行時における動的な構成を可能とするためには，ある意味，必然的なことだ。
　しかしその必然が，結果として開発者に対してはプログラムを書くことだけではなく，種々のフレームワークについて設定方法の学習を要求したり，運用に当たっては一つの変更がプログラムと設定の複数個所の変更に及ぶことで複雑さが増す原因となっているのは，ある意味皮肉なことである。
　Ruby on Railsの中心的な思想に重複排除の原則︵Don't Repeat Yourself――略してDRY原則と呼ぶ︶がある。これは同じことに対する記述を一つのソフトウエアの中に重複して持たないということでもある。そのため，ソース・ファイルとは別に設定ファイルが必要になることを目の敵にしているのだろう。だからと言って，すべての情報を静的にソース・ファイル内に記述してしまっては，ソフトウエアを実運用するための弾力性が欠如してしまうため，Webアプリケーションのように動きが早いシステムには向かないことも事実である。そのため，Ruby on RailsはRubyの動的な評価機構を利用することで，ソース・ファイルに設定ファイルを兼ねさせるようにしている。具体的には特定の命名規約にしたがってソース・ファイルを記述することで，実行時には実際のテーブルに対する読み書き削除などが実行できるように解決される。
　結論として，Ruby on Railsは，Rubyの動的な言語の特徴を生かすことで，開発に利用するプログラミング言語と命名規約をきちんと守ることを知っている――すなわち特別にいろいろな知識を持っているわけではないごく普通のプログラマから構成される少人数の開発チームが，ある程度の規模のWebアプリケーションを短期間に一定の質以上でリリースすることを目的としていて，かつそれが確かに成果を上げているということのようだ。
 さて，なぜJavaのコラムでえんえんとRubyに関する話題を書いていたのだろうか？ 実はまだ続きがあるのだ。
　もう一度，読書会へ戻ろう。
　読書会では，高橋氏の次に実際のO/Rマッパーの実装例としてSeasarプロジェクト︵注5︶の開発者のひがやすを氏から，SeasarプロジェクトでのO/RマッパーであるS2DAO︵注6︶についての解説が行われることになっていた。

S2DAO

ちなみに，S2はDI（Dependency Injection）コンテナ＋AOP（アスペクト指向プログラミング）のSeasar2の略であり，DAO（Data Access Object）はJ2EEパターンで規定されているO/Rマッピングのパターン名で，データ・アクセスの実装を隠蔽したJava Beanのことである――は，データベースのカラムに対応する属性を持ったJava Beanと，DAOのインタフェース定義の2つのソース・ファイルを利用するO/Rマッパーである。またS2DAOは必要に応じてテキスト・ファイルに記述した対象となるRDBMS用の本物のSQL（注7）を実行時に組み込むことも可能である。


　しかし，ひが氏はS2DAOの設計思想をRuby on Railsの言葉を使って語ることに︵恐らくアドリブで︶切り替えたのだ。しかも，それは十分に納得のいくものだった。
 具体的には次のようなことだ。
　S2DAOは，多くのJavaのO/Rマッパーと異なりXMLによる設定ファイルが不要である。これはRuby on Railsの重複排除の思想と同様であろう。S2DAOの場合は設定ではなく命名規約を利用して解決しているからだ。例えば自動生成されるデータ・アクセス・メソッドは命名規約によって制御されている。またJavaBeansに規約にしたがった文字列定数を定義することで実際のデータベースとの関連を指定することもできる。いずれもJavaプログラマが必要とするスキルはJavaプログラミングと命名規約への遵守だけである。
　なお，ひが氏は，Ruby on Railsの設計思想の一つであるプログラミング言語の機能を活用した問題解決という点についてはそのときは言葉が見つからなかったようだった。この点について筆者は，Seasar2のインタフェース・マターとでも言うべき点こそ，AOP︵アスペクト指向プログラミング︶も含めてJavaの特徴をうまく利用した方法論だと思う。
　ご存知のようにJavaはRubyのように動的な言語ではない。しかし実行時にクラスの情報をリフレクションという機構を利用することで読むことができる。それにより，コンパイル済みのプログラムでもあるクラスをパラメータ・ファイルとして利用することがきるのである。特に実装を持たず，単にメソッドや定数などの定義体であるインタフェースであれば，元々実装を持っていないのであるから，安全に，実行時にあらかじめ用意した実装を無理なく埋め込むことができる。AOPと言えばメソッドの呼び出し前後でのログ出力が良く例に出されるが，データベース・アクセスのように手順がほとんど決まっている処理であれば，処理そのものを実行時に織り込むことが可能だ。もちろん，そのためには処理の対象となるテーブルについての知識が必要となるのだが，それについては命名規約によって指定する︵クラス・ファイルがパラメータ・ファイルを兼ねているということを思い出して頂きたい︶ことができる。
　明らかに，Ruby on RailsとS2DAO︵Seasar2自身は多数のプロダクトから構成されているため，すべてが同様に共通する思想を持っているとは言えない。その中では，筆者にはS2JSFのピュアHTML指向とでも言うべき方向性は同じ思想を共有しているように思える︶は，全く異なる場所，異なる言語，異なる人間によって，互いに影響を及ぼすこともなく開発されたフレームワークである。しかし，ひが氏が気づいたように，ソフトウエアが解決すべき課題として見ているものと，その解決方法として提示したものは同じ思想によって生まれたかのようだ。
　それは一言で言えば，開発成果物で言えばプログラムへの回帰ということになり，開発作業で言えばピュアなプログラミングへの回帰ということになるだろう。異なるのは，Ruby on Railsは動的言語であるRubyを徹底的に活用することでそれを実現し，S2DAOでは静的な言語であるJavaにAOPを加えることでそれを実現している点だ。もちろん，単にプログラミングへの回帰と言っても，えんえんと似たようなコードを書く単調な作業ではない。定型的なコードは，フレームワークによって実行時に提供することができるのだから，それに対する指示になる。それと同時に必要に応じて，本当に人間がプログラミングしない限りは実現できない処理は人間がプログラミングするのだ。それを前者を設定ファイル，後者をソース・ファイルというように分断し異なる記述のスキルセットを作るのではなく，同じソース・ファイル上にプログラムとして記述するということだ。
　実際のところ，筆者はXMLによってJavaで構築されたソフトウエアに柔軟性を取り入れるという考えは好きである。しかし，確かにServletコンテナのためにweb.xmlを記述して，Strutsのためにstruts-config.xmlやvalidator-rules.xmlを記述して，とやっているうちに嫌になってくることがある。
　実際にはすべてがプログラムだけで解決可能となることはないだろう。開発規模が大きければ開発者も多数擁することになるので，逆に設定のエキスパートとプログラミングのエキスパートによる作業分担によって，より細かい作業やより大量の生成物の作成が可能かも知れない。したがって，大規模システムの領域ではモデル言語のようなより高度な︵一種の︶設定ファイルの作成とツールを利用したソース・ファイルの自動生成，それでは解決できない部分に対するプログラミングによるソース・ファイルの作成，という開発方法が今後の方向性ではないかと思う。そもそもソフトウエアの文字通りの固さが好まれる場所でも，実行時に動的な解決が行われることをあえて避けることもあるだろう。また，Webシステムと異なり運用時にオペレータが付き添うような作業では，いわゆる設定ファイルがJCL︵ジョブ制御言語︶にとって代わって利用されるということも考えられる。
　しかし，それより小さな規模，特にWebアプリケーションのように比較的定型的なしかし案件ごとに実際のプログラムは異ならざるを得ない分野ではRuby on RailsやSeasar2などが実現しているプログラミング主体の開発に今後は進んでいくのではないか，そんなことを筆者は感じた。この場合は，開発に携わる人間がプログラマだけで構成されていても不思議ではなく，ソフトウエア・ライフサイクルの短さから，物理的に少ない記述が時間的な短い開発時間に直結することが可能なプログラミングそのもの︵物理的な記述量は少なくても記述対象が特殊な設定ファイルでは，テストやデバッグがすぐに可能なプログラミングより短期間にできるわけではない︶に集中できるほうが望ましいだろう。すなわち開発者に求められるのはプログラミング・スキルだけで十分な，そういうフレームワークの方向だ。また，JavaがJ2SE5.0でアノテーションをサポートしたことからも見えるように，静的な言語であっても動的な処理を実行するための機構がますます充実していくに違いない。
　最後になったが，読書会を開催した角谷氏，会場を提供されたオージス総研，および参加された各氏へ感謝したい。

arton（ITエンジニア)


■著者紹介‥arton︵あーとん︶氏　　謎のITエンジニア。RTOS上でのデータベースエンジンを皮切りにミドルウエアやフレームワークとそれを利用するアプリケーションの開発を行い現在に至る。専門分野がある業界に特化しているために逆にメインフレームクラスから携帯端末まで，その時の需要に応じてダウンサイジングしたりアップサイジングしたりしながらオブジェクトを連携させていくという変化に富んだ開発者人生を歩んでいる。最近はもっぱらJ2EEが主戦場。著書に﹃Rubyを256倍使うための本　邪道編﹄﹃Visual C# .NETによるWebプログラミング入門﹄共著に﹃J2EEプログラミング講座﹄︵いずれもアスキー刊︶などがある。
注1‥日本オラクルの佐藤裕之氏による優れた解説記事をOTN Japanサイトで読むことができる。

 注2‥Ruby on Rails。日本Rubyの会発行のWeb雑誌﹃るびま﹄で，もりきゅう氏による紹介記事を読むことができる。また，高橋氏によるプレゼン資料を高橋氏のサイトで読むこともできる。

 注3‥同様にもりきゅう氏による紹介記事。

 注4‥Java開発者のコミュニティ・サイトであるTheServerSide.COMで，Ruby on Railsで検索すると111ドキュメントもヒットする。

 注5‥Seasarプロジェクトのサイト

 注6‥S2DAO

 注7‥多くのO/Rマッピング・フレームワークではフレームワーク独自に定めたSQLのサブセットを設定ファイルに記述する。
この記事の目次へ戻る