Processing – 絵をプログラムする言語

Processing(本家 Java 版. ライセンスは LGPL)
 
Processing.js(jQuery作者による JavaScript 実装版。IEでは要 ExCanvas.js. MIT ライセンス)
 
Java 言語に似た平易なプログラミング言語で、画像処理に優れている。
ユーザの入力を受け付けたり動的な処理もできるので、ゲームなどインタラクティブなプログラムも制作可能です。
 
参考:
絵をプログラムする言語「Processing 1.0」が正式リリース(マイコミジャーナル)
ブラウザでお絵描きプログラミング! Processing.js 登場!(IT戦記)

よくある描画処理l。中心に描画する時の Tips

絵を中心に表示させたい時など、

int x = (nWidth – img.getWidth() ) / 2;

みたいなことをよくするが、人のコードを見ていて

int x = nWidth – img.getWidth() >> 1;

とかやってて、ビットシフトいいかもと思いました。優先順位が + – より低いのがミソ。使うかどうかは好み次第。

頑健な Java プログラムの書き方

<http://www.alles.or.jp/~torutk/oojava/codingStandard/
writingrobustjavacode.html
>
– Writing Robust Java Code(2000.1.15) の邦訳版.
 
改めてこういうものを読んで、コーディング習慣の曖昧な部分を直していこうと思う。
個人的によくやるのは、

final Set listCustomers;
final Set customerList;

とかを曖昧な基準で使ってしまう。(前者はハンガリアンの流れのつもり、後者は英語の語順)
 
複数の単語から成る変数名の場合にどういう順序にするか、という点が曖昧だったが、ハンガリアン記法で定義されていない型に対してはやは

バイナリエディタ

– 昔から PowerWitch The Royal というバイナリエディタを使っている。高機能でフリー。ただしもれなくバニーさんがついてくる。スクラッチパッド編集で使いたくなったので久しぶりにダウンロードしてみた。
<http://www.nx.sakura.ne.jp/~elysium/software/pwtr/>
– PowerWitch The Royal

連番入力の自動化

– 自分ではよくやるけど、あまり見ないため、書き方をメモ。
– 言語共通の配列処理や、 Java の JDBC で使う PreparedStatement.setXxx() 等、パラメータで連番(1,2,3,4 …)にして複数同じ処理をする必要がたびたびある。
これをそのまま手入力すると、数が増えると手間で、入れ換えが面倒で、この煩雑さがミスも誘発する、ということもある。これを楽するには、変数を使ってインクリメントしていくとよい。たとえば次の通り:

foo(0, “abc”);
foo(1, “def”);
foo(2, “ghi”);
// :

というのを、

int i = 0;
foo(i++, “abc”);
foo(i++, “def”);
foo(i++, “ghi”);

とする。入れ換えも1文を差し替えるだけで済むし、制御文をはさんでも順序が崩れたりしないので便利。加算用の数値変数が残るのが気になるので自分ではスコープ区切って使ってます。

{
  int i = 0;
  foo(i++, “abc”);
  foo(i++, “def”);
  foo(i++, “ghi”);
}

途中で変数を宣言できない C でも、スコープを切ったバージョンは使える。

委譲とコンポジション(Effective Java の間違い)

Effective Java には、自身を参照にして渡さないと委譲とは呼べない、とあるが、これは間違い。Effective Java にも挙げられている [GoF P32] には次のようにある。

委譲では、1 つの要求を 2 つのオブジェクトが扱う。要求を受け取ったオブジェクトは委譲者へオペレーションを委譲する。これは、サブクラスが親クラスに要求を渡すことと同様である。

Effective Java にある自身の参照渡しはどこからでてきたのかというと、多分次の文の誤解から。

しかし継承の場合は、継承されたオペレーションは、C++ ならば this メンバ関数、Smalltalk ならば self を用いて、要求を受け取ったオブジェクトを参照できる。委譲でこれと同じ効果を実現するには、要求を受け取ったオブジェクトが自身を委譲者に渡す。そうすれば、委譲したオペレーションが受け手のオブジェクトを参照できるようになる。

その他参考:
<http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/200005.month/767.html>
– オージス総研 ML

DAO パターン

Core J2EE Patterns – Data Access Object
データソースや製品依存の処理を隠蔽して、例えばテーブル単位でアクセス用の API を作り、insert, delete, find, update など必要な処理はインターフェイスにして、それを実装する。複数の形式に対応するにはこの DAO インターフェイスを実装すればいいだけなのがメリット。
 
DAO だけでなく、シリアル化可能な値オブジェクトの、 Transfer Object も用意しておけば、DAO とクライアントの通信では Transfer Object がレコードの代用になるため抽象度が増す。
 
説明では、複数のソースと複数のテーブルが存在するため、利便性のために Abstract Factory Method Pattern でソースタイプ毎に階層を作り、メソッドでテーブルを作れるようにしている。
 
難点は、簡易的な実装だと条件をしぼりきれずオーバーヘッドがかかりそうなことや、どうしても JDBC とかを直接さわるより開発コストがかかること。単純な実装では select で全てとって Collection にしてしまえば楽だけど、たとえば数万行のテーブルが毎回格納されるとなると大変。単純な実装とは別にシステム特化のメソッドを実装すればいいかも。