ゲッターとセッターはいつ正当化されるのか

ゲッターとセッターは、適切なオブジェクト指向ではないとしばしば批判されます。一方、私が見たほとんどのオブジェクト指向コードには、広範なゲッターとセッターがあります。

ゲッターとセッターはいつ正当化されますか？それらの使用を避けようとしていますか？それらは一般的に使い古されていますか？

お気に入りの言語にプロパティがある場合（私の場合）、そのようなものもこの質問のゲッターおよびセッターと見なされます。オブジェクト指向の方法論の観点からは同じです。より良い構文を持っています。

Getter / Setter Criticismの情報源（コメントを見やすくするためにコメントから引用したものもあります）：

• http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
• http://typicalprogrammer.com/?p=23
• http://c2.com/cgi/wiki?AccessorsAreEvil
• http://www.darronschall.com/weblog/2005/03/no-brain-getter-and-setters.cfm
• http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and
• http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

批判を簡単に述べると、ゲッターとセッターを使用すると、オブジェクトの外部からオブジェクトの内部状態を操作できます。これはカプセル化に違反します。オブジェクト自体のみがその内部状態に注意する必要があります。

そして、コードの手続きバージョンの例。

struct Fridge
{
    int cheese;
}

void go_shopping(Fridge fridge)
{
     fridge.cheese += 5;
}

コードのミューテーターバージョン：

class Fridge
{
     int cheese;

     void set_cheese(int _cheese) { cheese = _cheese; }
     int get_cheese() { return cheese; }
 }

void go_shopping(Fridge fridge)
{
     fridge.set_cheese(fridge.get_cheese() + 5);        
}

ゲッターとセッターは、適切なカプセル化を行うことなく、コードをより複雑にしました。内部状態は他のオブジェクトからアクセス可能であるため、これらのゲッターとセッターを追加することで多くを得ることはありません。

この問題は、以前にStack Overflowで説明されています。

• https://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil
• https://stackoverflow.com/questions/996179

ゲッターとセッターを持つこと自体はカプセル化を壊しません。カプセル化を解除するのは、データメンバー（java lingoのすべてのフィールド）にゲッターとセッターを自動的に追加することです。これは、すべてのデータメンバーをパブリックにするよりも優れていますが、ほんの少しの距離です。

カプセル化のポイントは、オブジェクトの外部からオブジェクトの状態を知ることも変更することもできないことではなく、それを行うための合理的なポリシーを持っていることです。

• 一部のデータメンバーは、オブジェクトの内部に完全に存在する場合があり、ゲッターもセッターも持たない必要があります。

• 一部のデータメンバーは読み取り専用である必要があるため、ゲッターは必要ですがセッターは必要ない場合があります。

• 一部のデータメンバーは、互いに一貫性を保つ必要がある場合があります。そのような場合は、それぞれにセッターを提供するのではなく、値を一貫してチェックできるように、それらを同時に設定する単一の方法を提供します。

• 一部のデータメンバーは、一定の量だけ増分または減分するなど、特定の方法でのみ変更する必要がある場合があります。この場合、セッターではなくincrement()and / or decrement()メソッドを提供します。

• しかし、実際には読み取り/書き込みが必要な場合があり、ゲッターとセッターの両方を持っています。

の例を考えてみましょうclass Person。人に名前、社会保障番号、年齢があるとします。人々が名前や社会保障番号を変更することを許可しないとしましょう。ただし、その人の年齢は毎年1ずつ増やす必要があります。この場合、名前とSSNを指定された値に初期化し、年齢を0に初期化するコンストラクターを提供incrementAge()します。また、年齢を1増やすメソッドを提供します。 3つすべてのゲッター。この場合、セッターは必要ありません。

この設計では、オブジェクトの状態をクラスの外部から検査できるようにし、クラスの外部から変更できるようにします。ただし、状態を任意に変更することはできません。ポリシーがあります。これは、名前とSSNをまったく変更できないこと、および年齢を一度に1年ずつ増やすことができることを効果的に示しています。

今、人も給料を持っているとしましょう。そして、人々は自由に仕事を変えることができます。つまり、給与も変わります。この状況をモデル化するには、setSalary()方法を提供する以外に方法はありません！この場合、給与を自由に変更できるようにすることは、完全に合理的なポリシーです。

ところで、あなたの例では、私はクラス与えるだろうと代わりの方法を、と。その後、カプセル化がまだあります。FridgeputCheese()takeCheese()get_cheese()set_cheese()

public class Fridge {
  private List objects;
  private Date warranty;

  /** How the warranty is stored internally is a detail. */
  public Fridge( Date warranty ) {
    // The Fridge can set its internal warranty, but it is not re-exposed.
    setWarranty( warranty );
  }

  /** Doesn't expose how the fridge knows it is empty. */
  public boolean isEmpty() {
    return getObjects().isEmpty();
  }

  /** When the fridge has no more room... */
  public boolean isFull() {
  }

  /** Answers whether the given object will fit. */
  public boolean canStore( Object o ) {
    boolean result = false;

    // Clients may not ask how much room remains in the fridge.
    if( o instanceof PhysicalObject ) {
      PhysicalObject po = (PhysicalObject)o;

      // How the fridge determines its remaining usable volume is a detail.
      // How a physical object determines whether it fits within a specified
      // volume is also a detail.
      result = po.isEnclosedBy( getUsableVolume() );
    }

     return result;
  }

  /** Doesn't expose how the fridge knows its warranty has expired. */
  public boolean isPastWarranty() {
    return getWarranty().before( new Date() );
  }

  /** Doesn't expose how objects are stored in the fridge. */
  public synchronized void store( Object o ) {
    validateExpiration( o );

    // Can the object fit?
    if( canStore( o ) ) {
      getObjects().add( o );
    }
    else {
      throw FridgeFullException( o );
    }
  }

  /** Doesn't expose how objects are removed from the fridge. */
  public synchronized void remove( Object o ) {
    if( !getObjects().contains( o ) ) {
      throw new ObjectNotFoundException( o );
    }

    getObjects().remove( o );

    validateExpiration( o );
  }

  /** Lazily initialized list, an implementation detail. */
  private synchronized List getObjects() {
    if( this.list == null ) { this.list = new List(); }
    return this.list;
  }

  /** How object expiration is determined is also a detail. */
  private void validateExpiration( Object o ) {
    // Objects can answer whether they have gone past a given
    // expiration date. How each object "knows" it has expired
    // is a detail. The Fridge might use a scanner and
    // items might have embedded RFID chips. It's a detail hidden
    // by proper encapsulation.
    if( o implements Expires && ((Expires)o).expiresBefore( today ) ) {
      throw new ExpiredObjectException( o );
    }
  }

  /** This creates a copy of the warranty for immutability purposes. */
  private void setWarranty( Date warranty ) {
    assert warranty != null;
    this.warranty = new Date( warranty.getTime() )
  }
}

Javaのゲッターとセッターの基本的な理由は非常に簡単です。

• インターフェイスでは、フィールドではなくメソッドのみを指定できます。

したがって、フィールドがインターフェイスを通過できるようにするには、リーダーメソッドとライターメソッドが必要です。これらは従来、フィールドxに対してgetXおよびsetXと呼ばれています。

http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_andから

JavaBeanスタイル：

connection.setUser("dukie");
connection.setPwd("duke");
connection.initialize();

オブジェクト指向スタイル：

connection.connect("dukie","duke");

まあ、明らかに、後者のアプローチを好む。実装の詳細に影響を与えず、よりシンプルで簡潔であり、必要なすべての情報がメソッド呼び出しに含まれているため、簡単に正しく実行できます。可能な限り、コンストラクターのパラメーターを使用してプライベートメンバーを設定することも好みます。

あなたの質問は、ゲッター/セッターが正当化されるのはいつですか？おそらく、モードの変更が必要な場合、または何らかの情報を得るためにオブジェクトを調べる必要がある場合です。

myObject.GetStatus();
myObject.SomeCapabilitySwitch = true;

それについて考えると、私が最初にC＃でコーディングを始めたとき、上記のJavabeansスタイルで多くのコードを書きました。しかし、言語の経験を積むにつれて、コンストラクターでより多くのメンバーの設定を行い、上記のオブジェクト指向スタイルに似たメソッドを使用し始めました。

ゲッターとセッターはいつ正当化されますか？

動作 "get"および "set"が実際にモデルの動作と一致する場合（実際にはそうではありません）。

ビジネスドメインの動作が明確ではないため、他のすべての使用は不正です。

編集

その答えはフリッパートとして出会ったかもしれないので、拡大させてください。上記の答えはほとんど正しいですが、オブジェクト指向設計のプログラミングパラダイムと全体像を見逃しているものに焦点を当てています。私の経験では、これにより、getsとsetterを避けることがOOプログラミング言語の学問的なルールであると考えるようになります（たとえば、ゲッターをプロパティに置き換えることは壮大だと思う人）

実際、それは設計プロセスの結果です。これらのパラダイムを破るのか、破らないのか、そしてオブジェクト指向プログラミングの良い点と悪い点について議論して、インターフェースやカプセル化、パターンに入る必要はありません。最終的に重要なのは、ドメインに何も存在しない場合、それらを配置することでこのように機能するのはドメインをモデル化しないことです。

現実には、ドメイン空間のどのシステムにもゲッターとセッターがあることはほとんどありません。給与計算を担当する男性または女性に近づいて、単に「この給与をXに設定」または「この給与を取得」と言うことはできません。このような動作は単に存在しません

これをコードに組み込む場合、ドメインのモデルに一致するようにシステムを設計しているわけではありません。はい、それはインターフェイスとカプセル化を壊しますが、それはポイントではありません。ポイントは、存在しないものをモデリングしているということです。

さらに重要なステップやプロセスが欠落している可能性があります。これはおそらく、給与を支払ってこの給与をXに設定するだけではいけない理由があるからです。

ゲッターとセッターを使用する場合、このプロセスのルールを間違った場所にプッシュする傾向があります。これは、ドメインからさらに離れています。現実世界の例を使用すると、入ってきたランダムな人がこれらの値を取得する許可を持っていると仮定した場合の給与に似ています。そうでなければ、彼はそれらを求めません。それは、ドメインがどうであるかではないだけでなく、実際にはドメインがどうであるかについて嘘をついています。

原則として、ゲッターとセッターは悪い考えです。フィールドが論理的にインターフェイスの一部ではなく、プライベートにした場合、それは問題ありません。論理的にインターフェイスの一部であり、それを公開する場合、それは問題ありません。しかし、それをプライベートにしてから向きを変えて、ゲッターとセッターを提供することで効果的に再び公開すると、コードはより冗長で難読化されていることを除いて、元の場所に戻ります。

明らかに、例外があります。Javaでは、インターフェイスを使用する必要がある場合があります。Java標準ライブラリには、コード品質の通常の測定値を上回るほど極端な下位互換性要件があります。インターフェースを壊さずに、後で保存されたフィールドをオンザフライの計算で置き換える可能性が高い、伝説的ではあるがまれなケースを実際に処理している可能性さえあります。しかし、これらは例外です。ゲッターとセッターは、特別な正当化を必要とするアンチパターンです。

フィールドに直接アクセスできるか、メソッドを介してアクセスできるかは本当に重要ではありません。

クラスの不変式（有用なもの）は重要です。そして、それらを保存するために、外部から何かを変更できないようにする必要がある場合があります。例えば。幅と高さが別々のクラスSquareがある場合、それらのいずれかを変更すると、正方形以外のものになります。したがって、changeSideメソッドが必要です。これがRectangleの場合、setter / publicフィールドを持つことができます。しかし、セッターはゼロより大きい方が良いかどうかをテストします。

そして、具体的な言語（例えば、java）では、これらのメソッド（インターフェース）が必要な理由です。メソッドのもう1つの理由は、互換性（ソースとバイナリ）です。したがって、それらを簡単に追加してから、パブリックフィールドで十分かどうかを考えます。

ところで。私は、public finalフィールドを持つ単純な不変の値保持クラスを使用するのが好きです。

インターフェイスを同じに保ちながら、内部を何にでも変更したい場合があります。インターフェイスが変化しない場合、コードは壊れません。必要に応じて内部を変更できます。

私のアプローチはこれです-

後でデータをいじるつもりなら、ゲッター/セッターが正当化されます。また、変更が発生している場合は、データをゲッター/セッターにプッシュすることがよくあります。

POD構造の場合、スロットは使用可能のままにします。

より抽象的なレベルでは、問題は「誰がデータを管理するか」であり、それはプロジェクトに依存します。

ゲッターとセッターの使用が複雑に感じる場合、問題は言語ではなく概念そのものである可能性があります。

次に、Rubyで記述された2番目の例のコードを示します。

class Fridge
  attr_accessor :cheese
end

def go_shopping fridge
  fridge.cheese += 5
end

Javaの最初の例によく似ていることに注意してください。ゲッターとセッターがファーストクラスの市民として扱われる場合、それらは使用するのは面倒ではなく、追加された柔軟性は時には大きな恩恵になることがあります-たとえば、新しい冷蔵庫でチーズのデフォルト値を返すことができます：

class Fridge
  attr_accessor :cheese

  def cheese
    @cheese || 0
  end
end

もちろん、まったく公開されるべきではない多くの変数があります。内部変数を不必要に公開するとコードが悪化しますが、ゲッターとセッターでそれを責めることはほとんどできません。

Size幅と高さをカプセル化するクラスを考えてください。コンストラクタを使用してセッターを削除できますが、どのようにして長方形を描くのに役立ちますSizeか？幅と高さはクラスの内部データではありません。サイズの消費者が利用できる共有データです。

オブジェクトは、動作と状態（または属性）で構成されます。公開された状態がない場合、動作のみが公開されます。

状態がなければ、オブジェクトのコレクションをどのようにソートしますか？オブジェクトの特定のインスタンスをどのように検索しますか？コンストラクタのみを使用する場合、オブジェクトに属性の長いリストがあるとどうなりますか？

検証なしでメソッドパラメータを使用することはできません。したがって、書くのは怠です：

setMyField(int myField){
    this.myField = myField;
}

そのように記述すれば、少なくともセッターを検証に使用する準備ができています。パブリックフィールドよりも優れていますが、かろうじてです。ただし、少なくとも一貫したパブリックインターフェイスがあり、顧客のコードを壊すことなく戻って検証ルールを設定できます。

ゲッター、セッター、プロパティ、ミューテーター、それらをあなたが望むものと呼びますが、それらは必要です。

ゲッターとセッターがカプセル化と真のオブジェクト指向に違反する場合、私は真剣に困っています。

私はいつも、オブジェクトは、あなたがそれをするために必要だと思い浮かぶ最高のものを表しています。

JavaでMazeを生成するプログラムの作成を終えたばかりで、「Maze Squares」を表すクラスがあります。このクラスには、座標、壁、ブール値などを表すデータがあります。

このデータを変更/操作/アクセスするには何らかの方法が必要です！ゲッターとセッターなしで何をしますか？Javaはプロパティを使用せず、このクラスのローカルにあるすべてのデータをパブリックに設定することは、明らかにカプセル化とオブジェクト指向の違反です。

まず、私がコメントするオブジェクトには、値とサービスのタイプの2種類があります。

サービスタイプにセッターを含めることはできません。必要な依存関係は取得できません。依存関係を渡す最良の方法は、コンストラクターまたはファクトリーを使用することです。この方法では、すべてのインスタンスが最初から完全に形成され、単純で単純です。

値の型も不変である必要があります。一方で、ORMのように実用的ではない場合や、ウィジェットからオブジェクトへのマッピングなど、他のマッピングもあります。あるレイヤーまたはパーツから別のレイヤーまたはシステムにシステムを渡される他のすべての値タイプは不変である必要があり、セッターを持つべきではありません。

ゲッター/セッターは、他のパブリックメソッドが正当化されるように正当化されます。正当化の主な理由は、クラスが他のクラスと相互作用する方法を定義する外部世界へのインターフェイスを提供するためです。これは主に、個別のエンティティ間の結合を減らしたいためです。カップリングを減らすことは多くの理由で良いことです：

• 現在のコードから同じクラスインターフェイスを使用できますが、そのクラスは新しいメソッドを追加しました（ただし、古いインターフェイスは保持されます）
• 消費者に影響を与えることなく、クラスの内部表現を変更できます
• バグの可能性を減らす：内部データをプライベートにすると、外部コードが内部データを混乱させないことが確実にわかります。

はい、ゲッターとセッターは、オブジェクト指向プログラミングにおけるアンチパターンであるとすべき決して使用しないこと：http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html。簡単に言えば、オブジェクトをデータ構造のように扱うことを奨励するため、オブジェクト指向のパラダイムには適合しません。これは大きな誤解です。

プログラミング言語の自動生成を行う会社が開発したIDEが「オブジェクト指向の原則」に違反しないことを願っています。

そうは言っても、パブリックスコープ変数を取得したら、ゲッターとセッターを使用してください。私は、非常にオブジェクト指向のカプセル化の原則の必要な要素であるように思えます-たとえ多くのジャンクコードのように見えても。

それらを使用する理由は、適切なカプセル化がまだ行われている可能性があり、オブジェクトと猿をしている人があなたのオブジェクトを感じることができるレイヤーを抽象化する限り、彼は正しいことさえ知らずにそのオブジェクトを取り去ることができますか？

分割された家は我慢できず、OOのテナントの1つはオンにならず、カプセル化と時期尚早な最適化の両方を提供することはできません。

ここでもっと普通の答えがあると思いましたか？

ゲッターとセッターは一般的に極端にOOPです（他の何かが間違っていると言う人は誰でも、そのように単純です）。

オーバーエンジニアしないように注意する必要がありますが、必要のないゲッターやセッターを作成しないでください。別のクラスで使用する予定のない情報で、ゲッターやセッターを使用しないでください。

ただし、フィールドをパブリックにせず、代わりにゲッターとセッターを持つ理由はほとんどです：

• フィールドを使用して適切なテストを行うことはできません。ゲッター/セッターはその点ではるかに優れています。

• リアルタイムプログラミング設定でフィールドを適切に使用することは不可能です。同期ゲッター/セッターを使用する方法です。

• インターフェイストピック（既に説明しているので、説明しません）。

• システムを適切に再利用するときに使いやすくなります。

• クラスを使用しているクラスと、フィールドを変更した場合に破損するものをゲッター/セッターよりも知ることははるかに困難です。

そのため、ゲッター/セッターの代わりにパブリックフィールドを使用するのは、公式プロジェクトを作成するのではなく、単に楽しみのためにゲッター/セッターに煩わされないときだけです。