3

私は非常に一般的な質問をしていますが、答えは要件ごとに異なる可能性がありますが、「一般的」または「経験則」の場合、次のことが適切な設計ルールであると言えます。

キャッシュされるクラス（静的/参照データ）は、理由のある例外を除いて、不変として設計する必要があります。

これが当てはまらない場合、上記のステートメントの設計/パフォーマンスの問題は何でしょうか？

4

3 に答える 3

2

@JohnBは、基礎となるデータについて良い答えを持っています。

ただし、質問がキャッシュされたクラス自体（キャッシュにデータを保持している）の不変性に言及している場合、答えは、クラスのインスタンスが複数によって参照されている場合、可変クラスがスレッドセーフの問題を引き起こす可能性があるということですスレッド（キャッシュを介して共有されるデータでよく発生する可能性があります）。さらに、データの「偶発的な」変更が発生する可能性があります。この場合、共有インスタンスが意図せずに変更されます（変更コードがデータが共有されていることを認識していなかったため）。

于 2012-08-22T18:04:13.613 に答える
2

これは、データソースからデータを再度取得するのではなく、データを保持するキャッシュの機能が原因です。たとえば、データベースに値を照会してから、その値をメモリベースのキャッシュに配置すると、DBに再度照会する必要がなくなります。ただし、DBの値が変更される可能性がある場合は、キャッシュの値が古くなり、アプリケーションが間違ったデータを使用することになります。

したがって、アプリケーションの稼働中にデータを変更できない場合は、キャッシュが最適です。データが変更される可能性がある場合は、データが変更されたかどうかを定期的に確認するための戦略を策定する必要があります。

于 2012-08-22T17:42:24.417 に答える
0

jtahlbornが説明していること、つまり、不変クラスは「静的」データを取得するためのメソッドを提供します。

クラスが不変である場合、コンストラクターのパラメーターを除いてセッターはありません。

これを作成する際は注意してください。不変クラスは1回だけ使用されるようには作成されません。get ...メソッドにアクセスするたびに内部属性のコピーを実行する必要があるため、パフォーマンスが低下します。

例 ：

class MyImmutableThing {

  private final String myProperty;

  MyImmutableThing(String myProperty) {
    this.myProperty = myProperty;
  }

  String obtainMyProperty() {
    return myProperty;
  }

    // note there is no mean to modify the myProperty value : the original value remains ;)
    // That's it !
}
于 2012-08-22T18:25:50.210 に答える