規約が合わない場合も…ある

通常のコピペでおわるようなWebアプリではなく、SwingとかリッチクライアントとかあとはたぶんGWTとかWicketとかイベントが飛び交うようなアプリ（海外のデモとか見てるとWebアプリでも普通にイベント飛ばしあってるのもみますけどね）もそうなんだろうけど、そういう場合の規約って難しいな。

もちろん言語も関係ない。

Webアプリ用の規約だと制限が多すぎて満足に扱えない場合も多くなるはず。Webアプリはやれることを大幅に制限した特殊な形状のアプリなのだからそこを基準に考えるとどうにもならないことがある。

たとえばJavaBeansだけみても、Webアプリだったらこんなのでよい。

private Hoge hoge;

public Hoge getHoge(){
  return hoge;
}
public void setHoge(Hoge hoge){
  this.hoge = hoge;
}

でも、通常こういうのはイベントが飛び交うので以下のようになる。

protected Hoge hoge;

public Hoge getHoge(){
  return hoge;
}
public void setHoge(Hoge newValue){
  Hoge oldValue = this.hoge;
  this.hoge = newValue;
  change.firePropertyCahnge("hoge" , oldValue , newValue);
}

protectedになってるのは継承構造になることが多い（というかSwingの場合ならざるを得ない場合が多い）場合に必要。イベント発行しないで値をセットしたい場合とかはよくあることだし、継承先で初期化されることも多い。

おそらくこの書き方だとWebアプリの規約だとひっかかる。

ほかにもこんな単純な値のやりとりではなくて、ロジックがセッターやゲッターに掛かることは珍しくないし、例外もある条件を満たす場合出すこともある。そうなるとthrowsで明示したいがだいぶ怪しくなってくる。

protected Hoge hoge;

public Hoge getHoge(){
  return new Hoge(hoge){
    public String toString(){
      return "なんかフィールドの値そのものじゃないと思いねぇ";
    }
  };
}
public void setHoge(Hoge newValue)throws HogeException{
  if(newHoge.isWrap() == false){
    thorw new HogeException(newValue);
  }

  Hoge oldValue = this.hoge;
  this.hoge = newValue.unwrap();

  //この辺にロジックが入ってくるとかも

  change.firePropertyCahnge("hoge" , oldValue , newValue);
}

むー。