[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfriends] Re: [jfriends] Re: [jfriends] Re: Javaの開発生産性について
前橋です。
高橋さん:
>>>・データ構造がメソッドの実装に埋もれてしまい、読みにくい(ま、
>>> これはツールを使えば抽出できるだろうけど)。
>>
>>XMLを使いましょう。
>Collection APIを使いましょう、というのも追加。
templateのないJavaの Collection APIでは(以下略)
>データ構造などの設計情報はUMLで見ましょう、というのも追加。
ソースからツールで抽出でしょうか?
そうでなくて、設計段階に描いた図を参照しましょう、ということ
でしょうか?
後者だとすると... ドキュメントは常に現実とズレているものなので...
個人的な考えですけど、UMLのクラス図みたいなものは、要点*だけ*
をざっと説明する時にはわかりやすくていいんですが、どうやったっ
てアレに全ては盛り込めないので、補助的な役割しか果たせないの
では、と思ってます。もちろん、それはそれで重要なんですが。
>また、データ構造は裸で見るのもいいですが、データ構造をどう扱うかを
>語ってくれるメソッドの仕様を通して見ることがポインだと思います。
これは賛成しますが、
# だからってメソッドの実装までは見たくないけど。
># C言語のソースで一番理解が難しいことは、配列のインデックスを通して
># データ構造を追わねばならないことでした。
FORTRANならいざしらず、Cならポインタを使うべきですし、普通
そうしませんか?
>>> ・typedefがないので、intみたいな謎の型が散乱し、わけがわからん。
>>> (ま、これはCでも、エラーチェックが入らないのでさほど効果は
>>> ないけど、コメントやドキュメントに比べればだいぶマシ)
>>
>>よくわかりません。
>typedefしたくなるデータ型は、ほとんどclassとして扱ってしまうのでは？
>int型変数が入り乱れるのはむしろC言語の方ではないかと思います。
># 年令、西暦、和歴、月、日、などなど
年齢の場合、Cなら、
typedef int Age;
で済みますが、Javaだと、intを使ってしまいそうな気がするんで
すけれども。
日付なら、DateなりCalenderなりを使うのでしょうが、それはC++
なら全然問題なくできますし、Cでも、一応できます。
Xtだと、DimensionとかCardinalとか使ってますが、Cardinal相当
品は、JavaのAWTではintになってます。
# でも、これは、typedefの乱用のような気もする(^^;
ついでですが、typedefは、
typedef double Point3D[3];
みたいな使い方もできるので、複雑な型を簡潔に表現するには重要
だったりします。
># 所持金をintにすると、実行系によっては３万円ちょっとしか持てないことも・・
これは純粋に実行系の問題です。
不安なら、Cの場合、それこそtypedefで隠蔽しておけばいいんです
が、Javaだと...
32bit int だと、20億円ちょっと入るわけですが、今後何かのはず
みで超インフレになって、10億円札が発行されるような事態になっ
ちゃうときのことを考えるのなら、Cなら、
typedef int Yen;
しておけば、足りなくなったときにlongにすることもできますが。
>他人にとって読みやすいコードを書くということが、一番重要なことだと
>考えます。ただ、Javaの方が読みにくいという理由が分かりません。できれば
>具体例を交えて教えていただけないでしょうか？
Javaでちょっとプログラムを書くと、enumがないことによる
「読みにくさ」にはすぐに直面しますよね?
たとえば、AWTのLabelですけれども、文字列のアライメントを
こんなもん↓で指定するものだから、
public static final int LEFT = 0;
public static final int CENTER = 1;
public static final int RIGHT = 2;
これを与えるときのメソッドの引数はこんなふう↓になっちゃうわけで、
public Label(String label, int alignment)
これじゃ、alignmentに何を渡していいのだか、インタフェースを
見ただけではさっぱりわかりません。
# *やむを得ず* コメントなりドキュメントなりで補うわけですが、
# コメントやドキュメントは常に実体とズレているものです(切実)。
ところで、Labelのalignmentについては、*Javaの言語仕様上では*
こうなっちゃってもしょうがないのですが(私は許せんけど)、
もっと酷いのがBorderLayoutのコレ↓ (-_-;
↓↓ここから↓↓ここから↓↓ここから↓↓ここから↓↓
public void addLayoutComponent(String name, Component comp) {
if ("Center".equals(name)) {
center = comp;
} else if ("North".equals(name)) {
north = comp;
} else if ("South".equals(name)) {
south = comp;
} else if ("East".equals(name)) {
east = comp;
} else if ("West".equals(name)) {
west = comp;
}
}
↑↑ここまで↑↑ここまで↑↑ここまで↑↑ここまで↑↑
現存するコーディングを見る限りでは、C/C++では、確かにかなり
酷いコーディングも存在します。古いGNUやBSDのカーネルなんか読
んでると泣けてきます。変数名短いです。関数名も短いです。ポイ
ンタ演算使いまくりです。++が複雑な式の中にまぎれこんでます。
これは、これらのコーディングが、「古い」スタイルだから、読み
にくいわけです。
# ま、今でも古いスタイルで書きたがる人は多いんですけど...
# これについては、K&Rなんて困った本が、未だにバイブルになっ
# てしまっている現実に問題があるわけなんですけれども。
C++は、機能をいろいろ盛り込んだおかげで、面白がって乱用する
奴が後を絶たず、おかげで変なコーディングが幅を効かせているよ
うな気がします。
CにせよC++にせよ、読みにくいコーディングは確かに存在するけれ
ども、それはどちらかと言えば書く奴の問題です。
変な書き方はしなければいいわけで、いくつかの単純な規則に基い
てコーディングすれば、C/C++で読みやすいコードを書くことはあ
る程度可能ですが、Javaだと、少なくともC++に比べれば、機能自
体が足りてませんし、しかも、逃げ道が存在しない... って、これ
は昔 Dennis Ritchie がPascalについて言った文句と同じですね。
#defineは、乱用するとムチャクチャ危険ですが、うまく使えばか
なり便利です。Javaでデバッグライトはどうやって挿入するの?
------------------------------------------------------------
前橋 和弥 maebashi@xxxxxxxxxx
中部ソフトエンジニアリング(株)
〒450 名古屋市中村区名駅4-10-25(名駅IMAIビル 5F)
Tel:(052)583-4511(代) 内線 252 Fax:(052)583-4566
------------------------------------------------------------