netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-01-15 古い日記からの変換データ ▲
_ Cygterm ▲
Cygterm を Guevara からつついてみた． http://www.dd.iij4u.or.jp/~nsym/cygwin/cygterm/cygterm.cc を適当に置き換えてみた．怒られそうな変更してるけど．ポートはデフォルトの値１個だけを使うようにしてる． cygterm.cc cygterm.cfg Guevara 側の設定例．（cygterm.cfg で設定したポート番号をつつくようにする） cygterm.cfg2006-01-15 ▲
_ [論文] Micro Patterns＝クラス単位の実装コードのパターン ▲
Gil, J. and Marman, I.: Micro Patterns in Java Code. [ACM site]
Proceedings of the 20th annual ACM SIGPLAN Conference on Object Oriented Programming Systems Languages and Applications (OOPSLA2005), pp.97-116, San Diego, CA, USA., October 2005.
デザインパターンよりも実装に近いレベルでのパターンについて，ソースコードを分析してカタログを作ってみたという論文．設計の良し悪しの判断は難しいので，まず設計の違いについて調べてみる，といったことを言っている．
デザインパターンでは自動的なパターンの適用・認識が困難であることを踏まえて，Micro Pattern の特徴は，機械的に判定できるように定義してあること．たとえば「メンバーを持たないインタフェース」のように，属性，型名，メソッドのシグネチャなどから決定する．また，１つのモジュール単位で，パターンにマッチするかどうかを判定できるようになっている．
Micro Pattern を共通の語彙として使うといった使い方はデザインパターンと同じだが，Micro Pattern はそれぞれ，特定の設計問題に対する解法というわけではなく，もっと一般的な道具のようだ，とも述べている．
どんなパターンがあるか，なんかいずれ使うかもしれないのでいちおう日本語版っぽいものを作ってみた．
統計調査では，JDKやTomcat，Antなどを集めてきて，それらの中から各クラスがどの micro pattern に該当するかを調べている．統計によって，言語による制約ではなくちゃんと設計から生じたものであることを確認し，また，１つの仕様に対して，違う実装でも同じパターンを使っている傾向があることを確認している．
結果として，約75％のモジュールは少なくとも１つのmicro patternに該当する．登場回数では，Sink，Stateless，Implementor，Overrider，Pure Type の５つで約58％を占めた．
一方で，パターンごとの条件は排他的ではないので，２個以上のパターンに属するものも数多く，最大では６個のパターンに該当していたらしい．同じパターン群に属したクラスは互いに構造的に類似していたようで，Canopy/Restricted Creation/Overrider/Sink/Functional Object/Data Manager の６個セットに該当した１２個のクラスとか，Joiner/Pure Type/Stateless/Sinkにマッチした30個のクラスの例が挙げられていた．ある意味では，これらのパターンの組で，１つのパターンを定義しているといえる．
その他の調査としては，パターン群への分類の偏りを調べて，そこから得られる情報量を計算しており，定義したパターンによる分類には意味があることを確認していたり，複数の JRE ライブラリを比較して，パターンの出現率が同じ傾向であることを確認していたりする．
2007-01-15 ▲
_ [AspectJ] 誰が処理を行うかを隠蔽するアスペクト ▲
最近，Java で大規模なデータ構造を操作していて，呼び出したいメソッドを持ったオブジェクトへの参照をデータ構造のメンバー全員に行き渡らせるにはどうしたらいいか，などと悩んでいるうちの思いつきです．
メソッド呼び出しには，いつ処理を実行するか（その文をどこに置くか），誰が処理を実行するか（対象となるオブジェクト），どう処理を実行するか（その処理内容）という情報があります．このうち，「どう処理を行うか」については，インタフェースを使って隠蔽することができますが，「いつ，誰が」処理を実行するかというのはそのまま明記されています．
しかし，AspectJ のポイントカット＋アドバイスを使うと，元のコードからメソッド呼び出しを取り除くことができます．こうすると，「いつ，誰が」という情報が丸ごと隠蔽されます．AspectJ のポイントカットだと，主に「いつ」実行するかという情報を一箇所にまとめるのが主な役割としているんですが，一方の「誰が」という情報を隠す（呼び出し先への参照の管理をオブジェクトから取り除く）ことも大きな役割ではないのかなーという感覚がしています．
「誰が」だけを隠蔽するアプローチとしては，ASE 2006 のポスター発表で教えてもらった Zhi＃の人々の方法があります．この人たちは，あるオブジェクトから employee という関連を逆方向にたどって見つかるオブジェクト（company.employee == this が成り立つ company オブジェクト）を「this.^employee」というような形で参照できるようにしていました（データモデルの情報や，関連の名前についての ontology が与えられているという仮定はありますが）．
AspectJ でこれと似たような記述を少ない手間でやろうとするなら，空のオブジェクト参照フィールドを用意しておいて，before(): get アドバイスを使ってそのフィールドを実行コンテキストの値に応じた適切なオブジェクトで埋める，とかいう形になりそうです．これは，Dependency Injection でやってるようなことを，実行時の情報を使って動的にやろうとしている，という気もします．
