M12i.

学術書・マンガ・アニメ・映画の消費活動とプログラミングについて

AngularJSのAPIを眺めながらふと思うに

近ごろの関心対象はAngularJSで、HTML5──というかその総称のもとにある各種の技術をサポートしたブラウザの普及──を前提にしつつも、サーバサイドとクライアントサイドの疎結合、クライアントサイドのコード断片のカプセル化を推し進めるところに好印象を持っている。

それにしても、こうして久しぶりにクライアントサイドのコーディングを真剣に眺めてみると、スクリプトの分量の増加にともない、JavaScriptのプロトタイプ・ベースのオブジェクト指向、変数の動的型付けや(結局のところ)オプションでしかない仮引数宣言の柔軟性といった諸特徴がいよいよもって面倒のもとになりつつある感がある。

おなじ感覚はPythonRubyでつくられたライブラリやツールのコードを見ていても思うことである。少なくともそれらのコードを眺めて何をか読み取ろうとしている人間からすれば、コードがカプセル化されていなかったり、「カプセル」の「かたち」が不鮮明であったり、あげくそんなクラゲか何かのようにフニャフニャとして隠蔽性も低いものが継承ツリーを構成しているかと思えば、実行時に拡張されていたりするのを見せられると辟易させられてしまう。

多重定義(オーバーロード)の代わりに動的型付け引数で値を受け取る関数の内側をのぞくたび、型チェックの煩雑な手続きや(それよりはエレガントであるにしても)ダック・タイピングのための何かしら「慎重な」手続きを目にすることになる。それを繰り返すうちにむくむく大きくなってくる残念な気持ち。この気持ちははたしてクラス・ベースのオブジェクト指向言語に慣れた人間にしか共感を期待できないのだろうか? (ようするに、いくつものモジュールやオブジェクトなど──「カプセル」の具体的な名前はなんでもいいけれど、それらからなるプログラムをつくる場合、ある引数や変数が参照している"モノ"が「別になんだっていいんだ」なんてことはないのである。引数や変数が参照する「カプセル」には、かならず期待される値や想定されるメンバがあり、予想される振る舞いと予期された例外がある。それがあらかじめ宣言されていれば、コードを読み解く人間も開発をアシストするツールも無駄な労力を費やさずに済むし、何よりもそのコードを書く人間自身からして型チェックやダック・タイピングのために神経質なコードを書かなくて済むのである。そういう「神経質」なことはクラス定義を解析するコンパイラなりランタイムなりが引き受けてくれるからである。スクリプト言語は初発のモチベーションに関する障壁こそ低いかもしれないが、その学習曲線はJavaC#などとくらべて必ずしも緩やかではないし、コーディングやメンテナンスの際の手間はかえって多くなるという問題がある。今さら言うまでもないことではある。*1

こうして動的型付け言語に対する不満を吐き出さずにいられなくなったのも、AngularJSで名前ベースのDIを目にしたためである。この仕組み自体はモジュール間の疎結合を推し進めるから、非常に好ましいものである。しかし仮引数宣言が一種の「オプション」でしかないこの言語ならではというか、その実装はリフレクションのようなメタ・データの解析によるのではなく、Function#toString()に対する正規表現パターンマッチによるのだという。そしてこの名前ベースのDIは、コードの minify により不可能になってしまう。

動的型付けを含むJavaScriptの種々の特徴について、クラス・ベースのオブジェクト指向言語に慣れた開発者がしばしば懐く不安や嫌悪は(これまた)しばしばあまり根拠がないものであるにしても(しかし次々細分化し世代交代する情報技術の世界において、そうした保守的姿勢はデメリットばかりでなくある種のメリットをももたらし得るのだから、彼らのことを安易に非難しないでほしい)、そうであるにしてもやはりJavaScriptの諸特徴がコードの容易なモジュール化の阻害要因となっていることはこの言語の欠点として指摘できると思う。

*1:2015/02/24 15:45 追記