クラス属性宣言：プライベートvs公開

Question

パブリック属性の代わりにプライベート属性を定義する利点は何ですか？プライベート属性を公開することができれば、プライベート属性にアクセスして変更するためのメソッドを作成する余分な作業はなぜ必要ですか？

Answer 1

ゲッター/セッターを使用すると、変更またはアクセス時にロジックを実行できます。入力が正しいと仮定するのではなく、入力を検証することができます。値がフェッチされた回数を追跡できます。

何よりも、それは良いデザインです。クラスの開発者であるあなたに、使用方法をより詳細に制御し、誤用、濫用、または間違ったことをしている人を防ぐより大きな能力を与えます。

Answer 2

アクセス方法を作成する場合は、実装をインタフェースから分離します。

Answer 3

インターフェイスから実装を守るために常に努力する必要があるためです。アトリビュートをパブリックにすると、そのアトリビュートの実装がどのように実装されているかをクライアントに知らせることになります。

これは、インターフェイスだけでなく実装も維持することにつながります。あなたがこの方法を使用する場合

また、あなたは、バリデーション、アクセス制御、会計などの他のスマートなものを実行することができます。あなたが属性を公開する場合は、あなたが

Answer 4

クライアントがその属性で何ができるかのはるかに少ない制御を持っているプラ​​イベート属性は、その属性のために、あなたのクラスのユーザーからの保護のレベルを提供します。パブリックアトリビュートを使用する場合は、無効な値が正当なものかどうかをテストするためにロジックを追加する必要があります。

パブリック属性でもインターフェイスが「クラッタ」します。あなたが提示する公共の属性が少ないほど、よりクリーンで簡単にあなたのオブジェクトを扱うことができます。いくつかの属性をプライベートにすると柔軟性が得られますが、それ以外の場合は使用し易い使いやすさが提供されます。

Answer 5

C＃では慣用です。つまり、パブリックフィールドは驚くべきことであり、他の人があなたのコードを理解するのに少し時間がかかるようになります。

慣用である理由は、人々が与えている他の説明と関係がありますが、慣用的であるという事実は、フィールドを使用する魅力的な理由がない限り、公共のフィールド上のプロパティを好むべきであるということです。

Answer 6

短期的にはOOPの純粋主義者が不幸作っ以外のどれも、ありません。

（私はあなたがそうでなければゲッター/セッターを使用するプロパティを公開意味と仮定している - すべてのあなたの属性は、公開のままならば、明らかに大きな違いがあります）。

長期的には、それを行うには本当に良い理由がいくつかあります。

は、まず、それは、後でハードウェアブレークポイントと黒魔術の組み合わせで原点を逆追跡することの代わりに、ソースが入力を検証することを可能にします。

など。

void Foo::setWeight(float weight) 
{ 
    ASSERTMSG(weight >= 0.0f && weight <= 1.0f, "Weights must fall in [0..1]"); 
    mWeight = weight; 
} 

また、後でクライアントコードをリファクタリングせずにオブジェクトの動作を変更することもできます。

など。

void Foo::setSomething(float thing) 
{ 
    mThing = thing; 
    // 2009/4/2: turns out we need to recalc a few things when this changes.. 
    ... 
} 

Answer 7

主にOOのカプセル化の概念のためです。 privateを使用すると、オブジェクト変数へのアクセスをカプセル化し、オブジェクトの状態を制御できます。外部オブジェクトが、認識していないオブジェクトのステータスを変更することを許可しません。

単純な例はPocketオブジェクトです。

class Pocket { 
public int numberOfCoins = 10; 
private boolean haveMoney = true; 

public void giveOneCoin(){ 
    if(stillHaveMoney()){ 
    numberOfCoins--; 
    if(numberOfCoins=<0){ 
     haveMoney=false; 
    } 
    } 
} 

public boolean stillHaveMoney(){ 
    return haveMoney; 
} 

} 

そして今、以下のように別のクラスを想像：確かに、それは簡単な例です

class PickPockets { 
    public void getSomeMoney(Pocket pocket){ 
     pocket.numberOfCoins=0; 
    } 
} 

。ただし、これはクラスフィールド/属性へのアクセスを制御することが重要であることを示しています。 はるかに複雑な状態制御を持つより複雑なオブジェクトを想像してください。カプセル化は、オブジェクトの抽象性と一貫性を向上させます。

Answer 8

通常、必要と思われる場合にのみ、プログラムのロジック内で分離したいフィールドに対してプライベート宣言を使用します。

パブリック宣言を使用すると、独自のプログラムのフローをより詳細に制御できます。あなたはいつでもパブリックフィールドを変更することができます。あなたは家の中の男です。

なぜ、ほとんどの人がプライベート宣言にBIG YESと自発的に反応するのでしょうか？

ので：

• 彼らはそれを行うには教えられた大学で「ちょうどそのよう」。 （最も賢明な理由）
• 彼らは最終的に、愚かにもすぐにコードライブラリを構築し、他の人が消費するためのソフトウェアコンポーネントを構築したり、いくつかの暗号実装で作業していると仮定します。このような場合にのみ、自分の分野で何が起こるのか分からないでしょうか。

ボトムラインは驚くほど「商業」です！あなたがそれを "売っている"なら、プライベートに行く、そうでなければ好きなことをする。

Answer 9

すべての属性がプライベートである場合は、長期的にはより効果的です。それはゲッターを使用しないことを含む。オブジェクトの属性にアクセスしている場合、カプセル化が破られており、実際にOOPを行っているわけではありません。その時点で、クラスを構築する理由の大半は無駄になっています。侵入者から守るために城を建てるのはなぜですか？または（ゲッターと）は、リクエストに応じて常に侵入者を歓迎します。

"Law of Demeter"と "Tell ask not ask"の方法論は、プロダクションコードのバグ率を低減することが示されています。パブリックアトリビュートを使用しても、オブジェクト指向の純粋主義者は不幸になることはありません。コードを使用するだけで回避できます。

属性に何をするかをオブジェクトに指示し、値を要求したり、操作したり、書き戻したりしないでください。それは、散歩に犬を連れて、それを動かすために足を一つずつ拾うようなものです。

ところで、逆に、行動はすべて公開する必要があります。それがプライベートでなければならないような方法は、実際には別のクラスの抽出されていないメソッドです。そのクラスとメソッドを抽出し、あなたの目の前で簡単にデザインを見てください。