[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends] Re: ローカル変数とフィールド


高橋です。

こっち(jfriends)はアーカイブされないので、訳のURLを載せます。
http://www.jws.sis.ne.jp/~torutk/maneuver/1999/CodingStandard/javacodingstyle.html

> Numakuraです。
:
> 高橋さん訳
> 一般にローカル変数はフィールドの命名と同じ規約に従って
> 命名される。すなわち、最初を除く単語の最初の一文字を大
> 文字とする完全英語記述である。
> ---
> というのは、受け入れがたいなあ。先頭、末尾にアンダース
> コアは使うな、というルールも提案されているので、たとえば
> "xxx_"みたいなフィールドもダメってことになるし...
最初はそう思いました。メソッド記述内で、ローカル変数とフィールド
の区別がつかないのでかなり読むのに苦労するからです。しかし、この
AmbySoftの基準では、同じクラス内で宣言されるフィールドですら直接
使用せずにgetter/setterメソッドを介してアクセスせよとあるので、
それはそれで一貫性が備わっていると考えます。
また、別な部分で、"lazy initialization"という方法を使ってフィールド
を初期化するといいことを唄っています。この設計を行うと、フィールド
を参照するときは必ず初期化されていること（すなわちnullでない）が
保証できるので、nullチェックが不要になる等のメリットがあります。
また、必要時に初期化するという考え方もいいですね。

public class HoHo {
  private HaHa haHa = null;

  protected HaHa getHaHa() {
    if (haHa == null) {
      haHa = new HaHa();
    }
    return haHa;
  }

  public Something someService() {
       :
    // 同じクラスのフィールドにもgetterを使ってアクセス
    HaHa anHaHa = getHaHa();
    anHaHa.somethingToDo();
       :
  }
}

上記例ではクラスの見通しがよいのであまりメリットが感じられない
ですが、たとえばフィールドをinterface型で宣言しておいて、getter
メソッド内でnewするときはinterfaceをimplementsするクラス型を指定
すると、柔軟なクラスが設計できます。たとえばCollectionなんかを
フィールドに持っておいて、条件によって実装するクラスを変えてやる
といった応用が考えられます。

-- 
Toru TAKAHASHI :-O    torutk@xxxxxxxxxx
http://www.alles.or.jp/~torutk/