なぜゲッターとセッターのメソッドをプライベートと宣言するのですか？
Gettersメソッドとsettersメソッドがプライベートとして宣言されているコードを見ました。私はその背後にある論理を理解しようとしていますが、なぜそれらをプライベートとして宣言するのか理解するのに本当に苦労していますか？これは、ゲッターやセッターを通じて達成しようとしていることとは正反対です。
私はいくつかの理由を考えることができます：
- 将来のパブリックアクセスを防止したい。
別のプログラマーがあなたのコードを見て変数にアクセスしたいが、セッターとゲッターがいない場合、彼はあなたがそれらを忘れたと思って、自分で追加するかもしれません。ただし、それらをprivateとして宣言すると、それは意図のステートメントであり、これらの変数を変更したり外部からアクセスしたりしたくないと言います。
- 設定と取得を他のアクションに関連付けたい
publicアクセサーが必要ないとします。ただし、プライベート変数が変更された回数をカウントしたい場合があります。その変数にアクセスするたびにカウントをインクリメントするよりも、セッターを使用する方が簡単です。
- 中央アクセスポイントが必要
繰り返しになりますが、publicアクセスは必要ありませんが、デバッグ中に、privateメンバーが変更されるすべての場所にブレークポイントを設定することをお勧めします。したがって、クラスのどこにでもブレークポイントを設定する代わりに、アクセサーにブレークポイントを設定するだけです。
これは、ゲッターやセッターを通じて達成しようとしていることとは正反対です。
実際にはそうではありません。ゲッターとセッターを宣言する理由は、フィールドを非表示にするためです。これは、不要な結合を回避するために行われます。つまり、APIの実装の詳細に応じたAPIのクライアント。 （その結合は、いくつかの理由で問題になる可能性があります。）
ゲッターとセッターを作成する理由privateは、オブジェクトの抽象状態の対応する部分をプライベートにするためです。それは大部分は独立していますゲッターとセッターを使用するかどうかの決定です。
ゲッターとセッターを使用する場合は、民間の州ほど強力ではありませんが、それでも具体的なメリットがあります。例えば：
Getter/setterメソッドは、動作やエラーチェックコードを追加する場所を提供します。
それらは、状態の変化をログに記録したり、フィールドにアクセスしたりする場所を提供できます。
テスト中にデバッグコードを追加する場所を提供できます。 （おそらく、デバッグの最良の方法ではありません。）
ゲッターとセッターはオーバーライドできます。フィールド（プライベートかどうか）ではそれを行うことはできません。