プログラマメモ2 - programmer no memo2

[java]コンストラクタ引数が嫌い 2006/02/26
2008/01/28

コンストラクタ引数が嫌いです。



わがままかもしれませんが、コンストラクタ引数が好きになれません。

Java APIでコンストラクタ引数が必要なものは別に嫌いではないです。それは何故かと考えてみたのですが、Java APIで定義されていクラスはプログラムを書く上で基本になるからなのでしょう。



自分で作成するクラスでコンストラクタ引数がでてくるとそのクラスが疑わしくなります。

おそらく、コンストラクタ引数がなにかと想像できないようなクラスを作ってしまうからなのでしょうか。



嫌いだと強く思うコンストラクタ引数は、2つ以上の引数をもつものがおおいようです。



コンストラクタを利用する際に、その使い方を思い出さないといけない場合は悲しくなります。

コンストラクタ引数の意味が直感的に思い出せないような設計になるとため息をつきながAPIを 調べます。

例えば、



A(Object object, int a, int b, int c)



というコンストラクタ引数があった場合、第一引数はともかくその他変数が何のために必要かしらないと使えなようなものはツライ。

エクリプスのようなツールでは、ソースコードがライブラリにアタッチされたいない場合は、引数の型をコードアシストに表示します。上記のメソッドの場合は、A(Object, int, int, int)と表示されます。これでは、引数の意味するところがわかりません。



プログラムを書く上で記憶力はあまり使いたくないです。。。



もちろん嫌いだからといって使わないということはないです。

[徒然]全てを満足させるのは不可能 2006/02/19
2006/11/26

開発を進めながら、はじめからすべてを把握することはできないなぁと考えていて、最後にはプログラムの進化(システムではなく)が止まり、だんだんコードがわけわからなくなっていくのか考えてみたけど、答えはです。



疑ってかからないといけないのは、はじめから不可能と言い切ってしまうことだけども、結論からのべるという習慣にしたがっていえば、全てを満足させるのは不可能だと思う。



ここで満足させるといっているのは、

1.システムの変更の容易さ

2.プログラムの対称性の維持



システムの変更要求は、ふってわいたようにでてくる。しかし、そんなに不条理なものでもない。開発者の立場からいえば、非常に面倒な場合が多いと思うけども、ユーザからの立場からいえば、至極もっともなもののが多い。突然、コンピュータが空を飛ぶようにしてほしいというようのことはもちろんない。何らかの変更要求は必ずある。



プログラムの対称性の維持といっているのは、抽象的な言い方になってしまうが、プログラムのどこをみても全体を想像できるようなイメージ。仕様書と対称となっているプログラム。対称性は容易にこわされる。テンポラリなフラグをもたせてみたり、オブジェクトを注入してみたりすることによってでも、簡単に対称性を壊すことができる。

[java]javaとyacc 2006/02/16
2006/11/26

http://byaccj.sourceforge.net/



https://javacc.dev.java.net/



http://www2.cs.tum.edu/projects/cup/



lex

http://www.cs.princeton.edu/~appel/modern/java/JLex/



いろいろまとめてある

http://www.ultrasync.net/yofune/?%A5%B3%A5%F3%A5%D1%A5%A4%A5%E9%C0%BD%BA%EE



有限状態機械

http://www.nurs.or.jp/~sug/soft/super/fsm.htm



SableCC

http://sablecc.org/

http://shylips.at.infoseek.co.jp/2002/seminar/sablecc/





ASN.1の定義(JavaCC)

http://www.cobase.cs.ucla.edu/pub/javacc/AsnParser.jj



ASN.1の定義

http://grammatica.percederberg.net/grammar/asn1/asn1.grammar



Jparsec 再利用可能なパーサを作成する

http://jparsec.codehaus.org/

Jaskell Haskell風スクリプト

http://jaskell.codehaus.org/



//-------------------

電卓をつくってみよう

http://kmaebashi.com/programmer/c_yota/calc.html

[java] jdk1.5 tiger static importは便利 2006/02/15
2006/11/26

オブジェクトの比較で、"AAA".equals("BBB")という書き方が好きではないです。
なぜだか好きでないです。
なので、eqメソッドを用意して比較させています。

protected static boolean eq(Object object, Object object2) {
return object == null ? object2==null:object.equals(object2);
}

このメソッドを毎回用意するのがいやなので、eclipseのコードテンプレートに
eqとうつとこのメソッドを補完するようにしていたりしてます。
実装しているクラスに親がある場合は、親クラスに実装したり、
継承をしないようなクラスでは、クラスにこのメソッドを入れたりしていたのですが、
同じコードが散乱するのが嫌でした。

ならば、ユーティリティクラスを用意して、
Util.eq(a,b);
として使えばよいのかというとそうではなくて、
eqという二文字だけで、使用するのが字面的に好きなのです。

あとよく使うのがStringUtils.hasLength()というものがあります。
文字列チェックで、
if(a != null && 0 < a.length())......
という書き方が好きでないので、
StringUtilsを利用して文字列が長さをもつかチェックさせています。
上記の文字列チェックは
if(StringUtils.hasLength(a))....
というふうになります。

StringUtilsを自前で用意するか、ライブラリにあるもの使用しています。
エクリプスのようなコードアシストをもつツールを使用する場合、
多少長くても補完してくれますのでコードをうつのは面倒ではないです。

しかし、正直なところ、StringUtils.hasLength(a)という字面も好きではありません。
この好きでないという感覚は、大文字ではじまるディレクトリ名、ファイル名が好きでないは感覚と近いかもしれません。

java2 standard edition5.0からとりいれられているコードの書き方で、static importというものがあります。
この文法を利用するとユーティリティメソッドを利用するコードの書き方が自分的にスマートになるということがわかりました。

import static Util.eq;
import static StringUtils.hasLength;

というにすると、

if(eq(a,b)).....
ですとか、
if(hasLength(a))....
というふうにメソッドを宣言しているクラス名をつけなくてもよくなっています。

これは非常にうれしいです。
これから積極的に利用していきたいです。

でも、
お仕事のコーディングでは他の開発者との歩調をとるためにjdk1.4をしばらく使うという場合があったりすると思います。
そういう場合、ストレスになりますね。

[java]今後のjava 2006/02/05
2006/11/26

http://jcp.org/ja/home/ja JCP(Java Community Process)今後のjavaの動向を追うならこのサイトをチェックしたほうがよいかもしれない。

[java-swing]jgoodies,JDNC 2006/02/03
2006/11/26

ライセンスはBSD

https://jgoodies.dev.java.net/

サブプロジェクトは、5つ。

animation 更新されていないようです。

binding

forms

looks

validation



ダウンロードするのにはhttp://www.jgoodies.com/downloads/libraries.htmlが便利なようです。





製品

http://www.jgoodies.com/



JDNC

https://jdnc.dev.java.net/

http://swinglabs.org/index.jsp/

http://www.enode.com/



いろいろまとめられていた

http://d.hatena.ne.jp/cedar2004/200509