西尾泰和のブログ

現状ではMediatorがデフォルトでのバネの長さや反発力の強さなどを持っていますが、これは本来個々の物理法則が持つべきものです。今までなぜMediatorが持っていたかというと、個々の物理法則にアクセスする手段がなかったからで、本来なら個々の物理法則にアクセスしてそこから取得すべき。

大幅なリファクタリングなので一度今までの結果をCVSにコミットしてから。website visualizetion as *interactive* graphはできたのだけど、そこで「反発力をもうちょっと強くしておいたら見栄えがいいなぁ」と思ったのです。でそれを変更するためにそれ専用のAPIを作るのは設計がよろしくない、と。

自分のためのメモ書き。頂点、辺、物理法則などのフィールドをXML-RPCで操作できるようにするには。

• setter
  • public void rpc_****(Object o) を作る。引数の型やrpc_で始まるあたりはリフレクションで必要になるので変えちゃいけない。なんとなく****部分は小文字とアンダーバーで構成されているけど必要性は微妙。
    • やっぱりフィールド名と一本化した方がいろいろ自動生成できていいかもしれない。Eclipseのコードアシストとかドキュメントとか。javadocの出力にさらにフィルタを書けてXML-RPC用ドキュメントを生成とか。
    • なんでコードスタイルが変わったんだろう。rpc_にアンダーバーがついているからその後ろにキャメルケースを続けるのを無意識にためらったんだろうか。他の所は全部キャメルケースなのに。
  • 再利用できそうな型変換はUtilXMLRPCにstaticな関数として入れて再利用する。
    • ((Double) o).doubleValue() ですら UtilXMLRPC.ToDouble(o) に置き換えるのはやりすぎか？？
• getter
  • getterは何も受け取らずにハッシュを返す設計になっている。名前はrpc_getParams(ってアンダーバーにキャメルケースを続けてるじゃん！)
  • public Hashtable rpc_getParams()
  • 1行目はHashtable result = new Hashtable();かHashtable result = super.rpc_getParams();

	public void rpc_defaultNormalLength(Object o){
		defaultNormalLength = UtilXMLRPC.ToDouble(o); 
	}
	public void rpc_defaultSpringStrength(Object o){
		defaultSpringStrength = UtilXMLRPC.ToDouble(o); 
	}
	public Hashtable rpc_getParams(){
		Hashtable result = new Hashtable();
		result.put("defaultNormalLength", Double.valueOf(defaultNormalLength));
		result.put("defaultSpringStrength", Double.valueOf(defaultSpringStrength));
		return result;
	}

Javadocの結果からAPIリファレンスを作るスクリプトか…。来週の課題にしよう。