jFD開発したりしなかったり日誌

_ うー

左右の膝を紐で結んで膝から下しか動かない状態でのフルマラソン。

フレームワークとは制約を課す代わりにメリットを与えてくれるが、

思慮の足りずメリットが無いフレームワークは足かせでしかない。

誰だよ、これ作ったやつ。

_ ってゆーか、

あんたらインターフェイスって知らないだろ。

_ ソースコード自動生成について

僕の持論をば。

自動生成だからって、コピペしたような同じコードを長々と出力するもんじゃない。

想定される機能を親の抽象クラスできっちり作りこみ、それに与えるパラメータだけを

子に記述するくらいじゃないといけない。

じゃないとソースコードジェネレーターのコードは複雑怪奇な代物になり、

メンテナンス性がグダグダになる。

また、自動生成されたソースに直接人間の手を入れてはならない。

普通ソースコードジェネレーターは、以前のソースで人間が手を入れた部分だけ

残すなんて器用な真似は出来ないので、ソースコードジェネレーターに渡す

パラメーターを変更してソースを生成しなおすには

１、以前のソースのバックアップ

２、新しいソースの自動生成

３、古いのと新しいソースの手動のマージ作業

という手順が必要になり非常に効率が悪い。

これを防ぐためにはジェネレーターは親と子の二つのクラスを出力するようにし、

ソースコードジェネレーターは全ての機能を親クラスに記述するようにして、

プログラマーは子クラスに記述するようにしてファイルを分けてやる必要がある。

_ どこかさんのフレームワーク、どっちもやってないんだよな・・・

_ あと、そもそも僕はソースコードジェネレーターは嫌いです。

ソースコードは人間が書くのに最適化されてるのであって、

プログラムで出力するようには出来てない。

パラメーターファイルの自動生成くらいで何とかするべき。

_ Swingを使ったアプリについて

Swingでクライアントアプリを書くには色々知っておかないといけないことがあるが、

その中の一つにシングルスレッドであるということがある。

これはSwingに限らず、けっこう他のGUIライブラリでも共通することだけど、

イベントディスパッチスレッドで時間のかかる処理をしてはいけない。

イベントディスパッチスレッドはマウスやキーボードからの入力を受け付け、

処理を行うスレッドだが、Swingの場合（同様のGUIライブラリは多いが）、

イベントディスパッチスレッドが描画もこなしている。

だから、イベントディスパッチスレッドで時間のかかる処理を行うと完全にロックし、

再描画も行われないのでその上を別のウインドウが通ると跡が残り、

非常にレスポンスの悪いシステムになる。

通常、ユーザーはここで不快感を感じて、体感速度は実際の速度より遅く感じる。

また、いらいらしてボタン連打をしたりして、その後の誤操作に繋がったりもする。

_ で、どこかさんのアプリ、検索中思いっきり固まるんだよな。

こういうのがあるからSwingは遅いって言われるんだよ。

_ まあ、

色々とヤケクソなんです、最近。

景気よくいこう。

これから整体受けにいってきます。