top / index / prev / next / target / source

2005-07-16 diary: Eclipseプラグイン開発技術に取り組むにあたり、GUI関連技術およびデザインパターン利用を解禁

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

Eclipseプラグイン開発技術に取り組むにあたり、GUI関連技術およびデザインパターン利用を解禁

リソースの集約に関する戦略的な都合、私は 意図的に GUI関連技術およびデザインパターン利用を制限していました。今回、Eclipseプラグイン開発技術に取り組んでいくにあたり、GUI関連技術およびデザインパターン利用について 制限を解除します。

Eclipseプラグイン開発技術に取り組むにあたり、GUI関連技術およびデザインパターン利用を解禁

私は 持ち合わせている能力リソース集約の戦略的な都合として、普段から いくつも自分に制限をかけています。私は基本的に ネットワークプログラミングとかミドルウェア関連技術とかの、裏の技術に対して自らのリソースを集中配分してきています。このため、例えば前世紀から Java言語に従事しているのにもかかわらず、JSP+Strutsのプログラミングについて、ほとんどスキルを持っていないのはそのためです。私は自らに GUI関連技術には時間を割り当てないと制限をかけているのです。JSP+Struts専門家は別に専門家を育てているのです。しかし一方で Java Servletに関するプログラミングスキルについては、積極的に身につけてきました。それは Java Servletが 本当の基盤技術のひとつであると判断したからです。(しかしどこを基盤技術たるものとして判断するかについては、人によって、立場によって異なります。そこがおもしろいところです)

今回 Eclipseプラグイン開発技術について考えを巡らせた結果、Eclipseプラグイン開発技術は 私の立場にとっては重要な基盤技術であることが判断し、そして理解できてきました。私にとってはEclipseプラグイン開発技術が Java言語の登場や Java Servletの登場、JDBCドライバの登場などと同じくらいインパクトのある基盤技術として普及していくものと予測したからです。ここで重要なのは、Eclipseプラグイン開発技術は昔から存在する技術であるということです。新たに登場したということに価値があるのでは無く、Eclipseプラグイン開発技術が 次の世代のコンピュータソフトウェア開発技術の中で中核となる基盤技術として普及するための各種条件が整った、ということにあるのです。私は新技術に興味があるのでは無くって、それら新技術がある程度枯れた技術になり、そして収穫の時期が訪れたそのタイミングに 関連する開発技術を身につけておいて対応できるような体制を取っておきたいのです。とにかく重要なことは、Java ServletやJDBCといったインタフェースと同等のものとして Eclipseプラグイン開発技術が位置づけられるという点です。(そしておそらく私は GUI関連はほどほどに、根っこの方の技術に やはり注力していくのでしょうね…)

次に Eclipseプラグイン開発技術に手を染めるためには、デザインパターンについて これを理解して利用する必要があります。今まで私は私自身にデザインパターンに対して時間を割り当てないように制限をかけてきました。少なくともデザインパターンによって実装・構築されたナニカを利用するために 最低限の理解は行おうとは考えていましたが、みずからが ナニかデザインパターンを適用したクラスを作成することは極力避けてきました。これは自分でなにかデザインパターンを適用した新しいクラスを作成すると、それに対して説明のためのドキュメントやサンプルプログラムそして教育など、各種の周囲の導入のためのコストが発生することと認識していたからです。原則として、デザインパターンの導入はコスト高のリスクがとても高いのです。しかし Eclipseプラグイン開発技術の利用・理解のためには デザインパターン導入は必須です。それは構造上の都合からくるものなのです。そして Eclipseプラグイン開発技術の実現のためには こってこてのデザインパターンの導入はどうしても必要なものだったことだとも追認できます。デザインパターンというものが存在しているからこそ、Eclipseプラグイン開発技術があのように整理されてシンプルに提供できているのです。そのような背景から、私は Eclipseプラグイン開発技術に関してだけは、みずからにデザインパターンの利用を許可することとします。Eclipseプラグイン開発技術に結びついたデザインパターンについては、いくつかのサンプルが提供されていて、書籍も提供されており、そして何よりもそれを利用して開発された具体的なプロダクトである Eclipseが ソースコード付きで公開されているのです。こんな頼もしい デザインパターン適用サンプルは私は今まで見たことがありません。

そのようなことで、私は 自分自身に課していた GUI関連技術およびデザインパターン利用に関する制限を、限定付きながら解除することとします。(そのように宣言しないと、自分自身で自分のスキルマップを見失いがちなのです) Eclipseプラグイン開発技術は 天変地異に近いものがあるものですからね…。

関連する日記

DIやAOPは リッチクライアント駆動のための技術としても重要

某 著名なライターさんと話をしていて、「DIやAOPは リッチクライアント駆動のための技術としても重要」ということに気がつきました。この目的の実現のためには、DIコンテナはリッチクライアント側でも動作させることが必要になります。例えば リッチクライアントの動作を DIの機能によって 単体試験の際にはダミーのクラスを、結合試験の際には Webサービスを それぞれ呼び出させる、なんてことが自然に しかし効果的に実現できます。これに気がついたときには、目から鱗でした。それまでは DIコンテナについて、ついついサーバサイドで駆動させることという先入観が働いていたのです。DIコンテナは リッチクライアントの際にはクライアントサイドとしても重要な実装技術のひとつになる可能性が高いのです。

Eclipseプラグイン開発のためには、ずいぶんと贅沢な開発環境が必要なことが判明…

Eclipseプラグイン開発のためには、ずいぶんと贅沢な開発環境が必要なことがわかってきました…これはパソコンを更新する必要があるかも、ってくらい重い処理であるようです。

Eclipseプラグインにおける印刷環境の考察

2005.07.20追記 Eclipseプラグインベースの業務システムを開発する際には、何かしら帳票ツールが必要であることに気がつきました。そういえば、先日 Eclipseプロジェクトに帳票ツールが加わったというニュースを見たような見なかったような… (苦笑)

ようやく某記事の構成案作成に着手しました

編集者さま、ごめんなさい。ようやく某記事の構成案作成に着手しました。いましばらくお待ちください。

世間のニュースから

この日記について