ゲッターとセッターのメソッドとカプセル化について、インターネットで興味深い議論をしました。誰かが彼らがしなければならないのは、彼らを「純粋」に保ち、カプセル化を確実にするための割り当て（セッター）または可変アクセス（ゲッター）だけだと言いました。
この質問を重複して閉じる前に：私はここで検索するのに多くの時間を費やしましたが、これらの特定の質問に対する答えは見つかりませんでした。それらに答える質問を見せていただければ、喜んで削除します。
私は完全に同意します。ただし、検証はアクセサー (特にセッター) の正当なビジネスの一部であると言えます。検証されていないセッターを許可することは、非常に悪い習慣です。
オブジェクトが無効なデータを伝播するということは、オブジェクトの外部にあるそのプロパティについて心配する必要があることを意味し、カプセル化を深刻に破っています。
未チェックのアクセサーに正当な理由がある場合は、私の好みのオブジェクト指向言語の行に沿って、名前付きなどの両方を指定して、どちらが優先されるかを明確にしてgetください。unchecked_GetUnchecked_Access
ファウラーの「リファクタリング」を読み直したところ、生のアクセサのみを持つクラスはおそらく削除して、値を追加しないものとしてリファクタリングする必要があるという意見です。
具体的な回答：（私の意見）
はい、アクセサーの目的を無効にします。インスタンス変数を公開するのと同じくらい悪いです...
構築と設定を検証するのが最善です。その後、オブジェクトを信頼できます。
セッターは値を変更できますか? ケースバイケースで判断する必要があると思います。一般的な答えは、いくつかの詳細では間違っています。場合によっては、セッターが失敗して根本的な問題を指摘し、それを修正してもらいたいことがあります。
これは、そもそもゲッターとセッターを持つ目的を完全に無効にし、検証やその他のロジック (もちろん、奇妙な副作用なし) を許可する必要があるというのは正しいですか?
はい。取得と設定を行っている場合は、将来的にロックや変換ルーチンを導入できるので便利ですが、必要がない場合は、メンバーを公開してください。
検証はいつ行う必要がありますか? 値を設定するとき、セッターの内側 (オブジェクトが無効な状態にならないように保護するため - 私の意見) 値を設定する前、セッターの外側 オブジェクトの内側、値が使用されるたびに
これはあなた次第です。すべてを前もって評価して検証することは償却と呼ばれ、状態が常に有効であることがわかっているので便利です。ただし、後で行う場合は遅延検証と呼ばれ、実際にデータを使用することがない場合は、パフォーマンスを向上させることができます。
セッターは値を変更できますか (有効な値を正規表現に変換するなど)?
確かに、これはそれらを使用する大きな理由です。突然 2 種類の入力 (メトリックと標準など) をサポートする必要がある場合は、プロジェクト全体でその使用の各インスタンスを変更するのではなく、ロジックを 1 か所でセッターに追加できます。