ある種のRPGのコーディングを任されているとしましょう。これは、たとえば、インテリジェンス、ダメージボーナス、ヒットポイントなどのaとその統計を追跡したいことを意味します。CharacterGameCharacter
プロジェクトの終わりまでに、非常に多くのフィールドを処理することになりかねないことを前向きに恐れています。それぞれについて、非常によく似た一連の制約と動作に従うようにする必要があります（たとえば、最小値と最大値の間に制限されるようにしたい;「基本値」と「一時的なボーナス」を区別できるようにしたい;セッターとゲッターを経由せずに両方をインクリメントおよびデクリメントできるようにしたい） 。突然、すべてのフィールドに1つ（2つ？）のゲッターと4つのセッター、そしておそらく2つのリセッターも必要になります。10のフィールドでも、多くのメソッドが同じように意味します。
DRYnessの場合、クラスでこれらの統計をいじるロジックをカプセル化して、 or （返される値が範囲内にあることに注意）Fieldなどのコードを記述できるようにしました。クラスを作成するために、このような長さまで行ってきました。それらのフィールドをグループ化することですが、それは今のところ重要ではありません。intelligence.applyBonus(10)hitpoints.get()
さて、私は「プラグイン」しているときにこの問題にぶつかりましたField。GameCharacterほとんどのJava教科書では、各クラスにはパブリックゲッターとセッターを備えたプライベートフィールドが必要であると書かれています。それは理論的には良さそうです、そして私はすでにint;の周りにクラス全体を構築しました。ただし、ゲッターを呼び出して取得する場合、アイデアはそれほど堅実に聞こえません...ゲッター：
thisCharacter.getIntelligence().get() //eeek
フィールドに直接アクセスしたいです。たぶんそれは私のPython/VB [1]の「背景」ですが、私にとっては、よりクリーンで、より明確で、より単純です。
thisCharacter.intelligence.get()
パブリックフィールドの（理論上の）問題は、私がそれに対するすべての制御を放棄していることです。たとえば、コードベースの他のポイントで、不幸により、次のことが発生する可能性があります。
thisCharacter.intelligence = somethingThatReallyIsNull;
微妙なバグのように聞こえます...しかし...つまり、私は本当にそれについて心配する必要がありますか？私は直接割り当てる予定はありませんField[2]。これは実行すべきことではないことをJavadocに文書化していますが、それでも私はここで新しいので少し引き裂かれています。
それで、私はこのトピックについてのあなたの見解を聞きたいです。カプセル化の利点は非常に大きいので、先に進んでゲッターゲッターやセッターゲッターなどを用意する必要がありますか？それとも、健康的な対策でカプセル化を行い、フィールドFieldとして残す必要がありますか？public
[1]はい、わかっています。私は忘れようとしてきました。しかし、最近、C＃とmanも少し見ましたが、プロパティは甘くありません。しかたがない。
[2]コンストラクターを除く！そして、ゲッターは欠陥のあるコンストラクターから私を救うことはありません。