2011-10-21 15 views
1

一部のドメインオブジェクトのメソッドでは、属性を直接使用せずにgetメソッドを使用します。どうして ?一例として次のように属性を直接使用せずにgetXXX()メソッドを使用する理由

private List<String> errorCodeList = new ArrayList<String>(); 

/** 
* Add all errors to the error list. 
*/ 
public void addAllErrors(Collection<String> theErrorStrings) { 
    if (errorCodeList == null) { 
     errorCodeList = new ArrayList<String>(); 
    } 

    for (String aString: theErrorStrings) { 
     getErrorCodeList().add(aString); 
    } 
} 


/** 
* @return the errorCodes 
*/ 
public List<String> getErrorCodeList() { 
    return errorCodeList; 
} 
/** 
* Set the error strings. 
    */ 
public void setErrorCodeList(List<String> allErrors) { 
    this.errorCodeList = allErrors; 
} 
+0

一つの利点は、あなたがゲッターとセッターを導入するときにこれは単にEclipseのリファクタリングの結果であるかもしれない代わりに、ArrayListの Blem

+0

のリストを返すことができるということです。 –

答えて

0

カプセルである:

カプセル化は、ランダムに他のコードによってアクセスされる コードおよびデータを防止する保護バリアとして記述することができ、クラス外 を定義しました。データとコードへのアクセスは、インターフェイスによって厳密に制御されます。

詳細情報はhereです。

+1

フィールド/ゲッターが定義されているクラス内からのアクセスに関する質問です。 –

0

ゲッターが存在するため、コール内でゲッターを使用することをお勧めします。これは、ゲッターの背後にある実装が、ゲッターを使用するクラスの残りのコードを変更する場合、変更する必要がないためです。

フィールドへのすべてのアクセス(クラス内またはなしのいずれか)が単一の方法で行われるため、静的コード分析も容易になります。

もちろん、余分なメソッド呼び出しのトレードオフがあります(コンパイラーが変換を行うのに十分スマートでない限り)。

私はアダムスキーに同意しましたが、私はこれもファンではありません。

2

カプセル化の問題です。ゲッターとセッターを介してのみインスタンス変数にアクセスできるようにすると、内部表現が隠されます。したがって、インターフェイスを変更せずに後で実装を変更することができます。 HashMapを使用してエラーコードを保存すると便利です(何らかの理由で)。これを変更すると、フィールドにアクセスするすべてのコードが中断します。しかし、ゲッターとセッターを提供した場合は、変更された内部表現にもかかわらず、ゲッターとセッターをそのまま保つことができます。

さらに、不変式が適切に保持されていることを保証することは簡単です。誰もがフィールドにアクセスできる場合、これはできませんでした。

+0

がseconded。 (クラス内であっても)インターフェイスを満たしている限り、内部表現は変更されず、コードを読む人からの良いコーディング慣行をサポートしています – darkphoenix

+2

質問は同じフィールド内のフィールドの使用に関するものでしたクラスとgetterが定義されています。 –

+0

私の答えは同様に対処します。フィールドにアクセスするためにgetterとsetterのみを使用することで(クラス内からでも外部からでも)、インバリアントを強制することができます。フィールドを直接使用する場合は、すべてのコードのフィールドへのアクセスごとに、すべての制限を守ることを考える必要があります。 –

2

私は個人的に彼らのgetterメソッドを経由して同じクラス内のフィールドにアクセスするためのファンではない:カプセル化は、あなたが同じクラス定義内のコードを書いているので、ゲッターを呼び出して回避することにより、破壊されていません。また、getterを使用すると、コードがより複雑に見えるようになり、効果的な構文の強調表示ができなくなります。あなたがゲッターを通じてフィールドにアクセスする必要があり、例外は明らかにあります

それはあとで生成だ
  • ゲッターがオンザフライで値を計算するとき。
+0

別の理由、疑わしい:ゲッターがサブクラスでオーバーライドされる場合 –

0

カプセル化はデータメンバーに直接アクセスすることで壊れることはありませんが、数ヶ月後にデータメンバーの変更のセマンティクスについてはどうでしょうか?そのフィールドがアクセスされた100の派生クラスを検索する必要があります何も壊れないことを確かめるために直接?アクセスがゲッターを介してのみ行われる場合は、各フィールドがどこにアクセスされたかを追跡する方がはるかに簡単です。

2

私はサンプルコードがこれを行う最良の方法ではないと考えています。同じメソッドでゲッターを使って直接変数にアクセスしています。この混乱は混乱します。
リストの怠惰な作成がゲッターで行われた場合、ゲッターを使用する理由が明確になるでしょう。例:あなたのコードから見ることができます

public void addAllErrors(Collection<String> theErrorStrings) { 
    for (String aString: theErrorStrings) { 
     getErrorCodeList().add(aString); 
    } 
} 

public List<String> getErrorCodeList() { 
    // TODO synchronization? 
    if (errorCodeList == null) { 
     errorCodeList = new ArrayList<String>(); 
    } 

    return errorCodeList; 
} 
関連する問題