top / index / prev / next / target / source
日記形式でつづる いがぴょんコラム ウェブページです。
Eclipseが十分に普及してデファクトになっていくと、新時代は「Eclipse指向Javaプログラム設計」というパラダイムシフトが訪れると考えます。 , 結局 土・日は出勤して結合試験を実施しました。
Eclipseが十分に普及してデファクトスタンダードになってきました。Eclipse 3.0.xになって、様々な操作性も向上してきました。そうすると、今までは想像もできなかったパラダイムシフトが発生すると私は考えます。言うならば「Eclipse指向Javaプログラム設計」というパラダイムシフトです。
Eclipseが十分に普及すると このフィクションのようなパラダイムシフトは実際に発生すると考えます。重要なのは、未来において この日記を振り返り「これって普通のことだよね」と思えたとしても、現時点で「Eclipse指向Javaプログラム設計」というのを提唱するのは、突拍子もないアイデアであるように考えられるという点です。
2005.03.28追記 なんと Eclipse指向という用語そのものは新語ではありませんでした。これには結構 驚きました。まあ、さすがに Eclipse指向パラダイムとか Eclipse指向設計、そしてその英文については、まだ世間的には新語ではある模様です。
原文の方には、「The Eclipse-oriented tools」との一文がありました。
関連する日記
エンドユーザが基本的に Eclipseを使うという前提を加えると、Javaプログラム設計は 今までとは異なるアプローチで行う必要があります。設計を Eclipse指向に行っていく必要があります。
コード自動補完やインポート文の自動編成のために、他パッケージ内のクラス名とは衝突させないようにします。
業務クラス名には パッケージ名の一部をそのままクラス名の先頭に利用します。 一方でユーティリティ系クラスなどは、普通のJavaクラス命名を行う。
コード自動補完が適切に動作するように、クラス名は意味を持ってソートできるようにする。(コード付けとか命名の過程で、構造化を適切に行っておく)
Eclipseが適切に動作する単位を見極めてモジュール分割を行います。
Javaコーディング規約も、Eclipseに適した物に変えていかなくてはなりません。
コーディングスタイルは Eclipseのデフォルトのものを利用します Eclipse 3.0では パッケージのルートを選択して コードフォーマッタを行うことが出来ます。原則 Eclipseのコードフォーマッタを用いて Javaソースコードのコード整形を行いましょう。Eclipseのコードフォーマッタは デフォルトでSunのコーディング規約をベースとしたものになっています。これをそのまま利用しましょう。なぜなら、それがEclipseのデフォルト設定だからです。
JavaDocは適切に記述します なぜなら JavaDocとして書いた情報がEclipseのツールチップに表示されるからです。
TODOなどを有効活用します なぜならTODOなどは Eclipseにデフォルト設定されていてEclipseのタスクに表示されるからです。
import文の並びは Eclipseのimport自動編成に委ねます。 必ず Eclipseにデフォルト設定のimport自動編成順序を選択します。
アウトライン表示ですぐに理解できるようなクラス構造にします。アウトライン表示で すぐには意味がわからないクラスはリファクタリングが必要です。当然ですが、リファクタリングは Eclipseの機能を利用して実施します。
Eclipseに対応したコーディング規約チェックプラグインの導入を検討することも良いでしょう。ただしプラグインを多くインストールすると Eclipseの操作感が悪化するおそれがあります。適度に、そして適量のチェック用プラグインを選定します。
白兵戦になってしまいました。効率化をもっと工夫しないといけませんね。反省です。