2013-07-15 12 views
6

今、自分の設定を保持するクラスのロードを作成しています。それはそれです。私が行うのは、設定ファイルの値を保存することだけです。最終変数のゲッター

コードの半分以上がゲッターであり、ゲッターを持っているのか、直接変数にアクセスしているのか不思議です。

ので、この:

public myClass 
{ 
    public myClass(String name) 
    { 
     this.name = name; 
    } 

    final String name; 

    public final String getName() 
    { 
     return name; 
    } 
} 

または:

public myClass 
{ 
    public myClass(String name) 
    { 
     this.name = name; 
    } 

    public final String name; 
} 

彼らが実際に何もしていないときそこにすべてのゲッターを持っていますが、変数を返すために、本当に愚かなようです。しかし、私は、ゲッターをとにかく持っているのが一般的なJavaの習慣であると言われています。ゲッターとデータをカプセル化

+1

コンパイラはとにかくインライン展開します。あなたがやっていることに対して 'java.util.Properties'を利用していますが。 – jlordo

+2

最終的な変数は愚かに見えるかもしれませんが、最終的な変数がなく、サブクラスに同じ変数名が定義されていて、これらの変数にアクセスしようとすると、get/setなしでどのように混乱するかがわかります。適切なカプセル化は常にベストプラクティスです。 – kosa

+0

@jlordoそれは私が与えていた非常に簡単な例でした。 'Properties'は私がやっていることにはまったく適していません:) – Cheetah

答えて

11

には、いくつかの利点を提供することができます。

  • あなたが発信者に影響を与えずに、いくつかの他の表現にフィールドを変更することができます。
  • ゲッタにコードを追加できます。
  • getterを提供するインターフェイスを実装できます。
  • finalでなくても、フィールドへの読み取り専用アクセスを提供できます。
+1

これを行う最も重要な理由は、あなたの答えで説明した[カップリング](http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29)です。 –

+0

@LuiggiMendoza getters/setterに関するカップリングについてさらに説明できますか? –

+2

より多くのコードをクラスの表現に結合すると、その表現を変更する作業が増えます。カプセル化は、内部表現をインターフェースの背後に隠します。これは表現が変わると一定に保たれます。 –

0

私が知っている練習は、インスタンスのためにSystem.outのように、不変種類の公共静的 finalフィールドを使用することです。しかし、私はインスタンスフィールドにゲッタを追加します。

最終的にはStringが公開されていることにはほとんど影響しませんが、私はあなたに同意します。しかし、変更可能な型に注意してください。さらに、IDEにインライン展開とコード生成があるため、ゲッターのコストは、コードを書くことと実行時にどちらかというとはるかに軽い傾向があります。

関連する問題