問題タブ [encapsulation]

Eclipseでセッターとゲッターを生成する場合、オプションの1つは、クラスメンバーに直接アクセスするのではなく、クラス内でゲッターとセッターを使用することです。このレベルのクラス内部カプセル化は有用ですか、それとも一歩先を行くのは良い考えですか？

DUPE：クラス内から、またはクラス外からアクセサプロパティを使用する必要がありますか？

C++ のバックグラウンドを持つ私は、Java の世界とそのフレームワークの複雑さを習得する必要があります。DIのSpringフレームワークを見ていると、DIの対象となる各セッター関数を公開する必要があるとは信じがたいです。その要件は、情報隠蔽の原則を破っていませんか?

もちろん、Spring でクラスのプライベート パーツを設定できるようにしたいのですが、すべてのクライアント クラスで同じことができるようにしたくはありません。

ここで何が欠けていますか？

「抽象化とカプセル化は補完的な概念です。抽象化は、オブジェクトの観察可能な動作に焦点を当てています...カプセル化は、この動作を引き起こす実装に焦点を当てています...カプセル化は、ほとんどの場合、すべてを隠すプロセスである情報隠蔽によって達成されます本質的な特性に寄与しないオブジェクトの秘密の。」-オブジェクト指向の分析と設計におけるGrady Booch

情報を隠すことによるカプセル化の利点について、説得力のある例をいくつか教えていただけますか?

検証、変更追跡などを行うために、プロパティのバッキング フィールドにアクセスする方法はありますか?

次のようなことは可能ですか？そうでない場合、.NET 4 / C# 4 で使用する予定はありますか?

私が抱えている主な問題は、自動プロパティを使用すると、明示的なバッキングフィールドを持つプロパティと同じように検証などの柔軟性が得られないことです。ただし、明示的なバッキング フィールドには、アクセスしている可能性のある他のクラスと同様に、プロパティの検証、変更追跡などにアクセスして再利用する必要があるときに、それが含まれているクラスがバッキング フィールドにアクセスできるようにするという欠点があります。プロパティを外部に。

上記の例では、バッキング フィールドへのアクセスのスコープがプロパティに限定されるため、プロパティの検証や変更の追跡などの回避が防止されます。

編集: < Backing Field > を < Keyword > に変更しました。価値に似た新しいキーワードを提案します。フィールドはうまく機能しますが、多くの既存のコードで使用されていると確信しています。

オブジェクト指向設計 (OOD) は、データとそのメソッドを組み合わせます。私が見る限り、これは 2 つの素晴らしいことを達成します: カプセル化 (データが何であるかは気にせず、必要な値を取得する方法のみを気にしません) とセマンティクス (データを名前と関連付け、そのメソッドは一貫して当初の意図どおりにデータを使用します)。

では、OOD の強みはどこにあるのでしょうか。対照的に、関数型プログラミングでは、豊かさを名詞ではなく動詞に帰するため、カプセル化とセマンティクスの両方がデータ構造ではなくメソッドによって提供されます。

私はスペクトルの機能の端にあるシステムで作業しており、OO のセマンティクスとカプセル化を絶えず切望しています。しかし、OO のカプセル化が、オブジェクトの柔軟な拡張に対する障壁になる可能性があることがわかります。したがって、現時点では、セマンティクスがより大きな強みであると考えています。

それとも、カプセル化はすべての価値のあるコードの鍵ですか?

編集: 具体的には、OO がここで提供するカプセル化のタイプを意味します。changeColor(door,blue)になりdoor.changeColor(blue)ます。

Bar参照タイプを含むプライベートフィールドを持つクラスがありますFoo。公共の財産で公開したいFooのですが、財産の消費者が変更できるようにしたくありませんFoo...ただし、内部で変更可能である必要があります。Barつまり、フィールドを作成できませんreadonly。

だから私が欲しいのは：

...もちろん無効です。のクローンを返すこともできますがFoo（それがそうであると仮定してIClonable）、これは消費者には明らかではありません。プロパティの名前をFooCopy??に変更する必要があります。GetCopyOfFoo代わりにそれは方法であるべきですか？ベストプラクティスは何だと思いますか？ありがとう！

カプセル化と抽象化の正確な違いは何ですか？

ある種のRPGのコーディングを任されているとしましょう。これは、たとえば、インテリジェンス、ダメージボーナス、ヒットポイントなどのaとその統計を追跡したいことを意味します。Character GameCharacter

プロジェクトの終わりまでに、非常に多くのフィールドを処理することになりかねないことを前向きに恐れています。それぞれについて、非常によく似た一連の制約と動作に従うようにする必要があります（たとえば、最小値と最大値の間に制限されるようにしたい;「基本値」と「一時的なボーナス」を区別できるようにしたい;セッターとゲッターを経由せずに両方をインクリメントおよびデクリメントできるようにしたい） 。突然、すべてのフィールドに1つ（2つ？）のゲッターと4つのセッター、そしておそらく2つのリセッターも必要になります。10のフィールドでも、多くのメソッドが同じように意味します。

DRYnessの場合、クラスでこれらの統計をいじるロジックをカプセル化して、 or （返される値が範囲内にあることに注意）Fieldなどのコードを記述できるようにしました。クラスを作成するために、このような長さまで行ってきました。それらのフィールドをグループ化することですが、それは今のところ重要ではありません。intelligence.applyBonus(10)hitpoints.get()

さて、私は「プラグイン」しているときにこの問題にぶつかりましたField。GameCharacterほとんどのJava教科書では、各クラスにはパブリックゲッターとセッターを備えたプライベートフィールドが必要であると書かれています。それは理論的には良さそうです、そして私はすでにint;の周りにクラス全体を構築しました。ただし、ゲッターを呼び出して取得する場合、アイデアはそれほど堅実に聞こえません...ゲッター：

フィールドに直接アクセスしたいです。たぶんそれは私のPython/VB [1]の「背景」ですが、私にとっては、よりクリーンで、より明確で、より単純です。

パブリックフィールドの（理論上の）問題は、私がそれに対するすべての制御を放棄していることです。たとえば、コードベースの他のポイントで、不幸により、次のことが発生する可能性があります。

微妙なバグのように聞こえます...しかし...つまり、私は本当にそれについて心配する必要がありますか？私は直接割り当てる予定はありませんField[2]。これは実行すべきことではないことをJavadocに文書化していますが、それでも私はここで新しいので少し引き裂かれています。

それで、私はこのトピックについてのあなたの見解を聞きたいです。カプセル化の利点は非常に大きいので、先に進んでゲッターゲッターやセッターゲッターなどを用意する必要がありますか？それとも、健康的な対策でカプセル化を行い、フィールドFieldとして残す必要がありますか？public

[1]はい、わかっています。私は忘れようとしてきました。しかし、最近、C＃とmanも少し見ましたが、プロパティは甘くありません。しかたがない。

[2]コンストラクターを除く！そして、ゲッターは欠陥のあるコンストラクターから私を救うことはありません。