ゲッターとセッター/アクセサーを使用する理由

単にそれらの変数にパブリックフィールドを使用する代わりに、取得と設定のみを行うゲッターとセッターを使用する利点は何ですか？

getterとsetterが単純なget / setだけではない場合、これをすぐに理解できますが、その方法は100％明確ではありません。

public String foo;

より悪い：

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

一方、前者は必要なコードが大幅に少なくなります。

実際には、クラスのフィールドを直接公開するのではなく、アクセサを使用することを検討する多くの正当な理由があります。

ここに私が知っているいくつかの理由があります：

• プロパティの取得または設定に関連する動作のカプセル化-これにより、検証などの追加機能を後で簡単に追加できます。
• 代替表現を使用してプロパティを公開しながら、プロパティの内部表現を非表示にします。
• パブリックインターフェイスを変更から隔離する-既存のコンシューマに影響を与えることなく実装が変更される間、パブリックインターフェイスを一定に保つことができます。
• プロパティの存続期間とメモリ管理（破棄）セマンティクスの制御-特に管理されていないメモリ環境（C ++やObjective-Cなど）で重要です。
• 実行時にプロパティが変更されたときのデバッグインターセプトポイントを提供する-一部の言語では、これがなければ、プロパティが特定の値に変更されたときと場所のデバッグが非常に難しい場合があります。
• プロパティゲッター/セッターに対して動作するように設計されたライブラリとの相互運用性の向上-モッキング、シリアル化、およびWPFが思い浮かびます。
• ゲッター/セッターメソッドをオーバーライドすることで、継承者がプロパティの動作と公開方法のセマンティクスを変更できるようにします。
• ゲッター/セッターが値ではなくラムダ式として渡されることを許可します。
• ゲッターとセッターは異なるアクセスレベルを許可できます。たとえば、ゲットはパブリックである可能性がありますが、セットは保護できます。

2週間（月、年）後、セッターが値を設定する以上のことを行う必要があることに気づくと、プロパティが他の238のクラスで直接使用されていることにも気付くでしょう:-)

パブリックフィールドは、フィールドを返し、フィールドに割り当てる以外に何もしないゲッター/セッターのペアよりも悪くはありません。まず、（ほとんどの言語で）機能的な違いがないことは明らかです。違いは、保守性や可読性などの他の要因にあるはずです。

ゲッター/セッターのペアのよく言われる利点はそうではありません。実装を変更でき、クライアントを再コンパイルする必要がないという主張があります。おそらく、セッターを使用すると、検証などの機能を後で追加でき、クライアントはそれについて知る必要すらない。ただし、検証をセッターに追加すると、前提条件が変更され、以前のコントラクトに違反します。これは、簡単に言うと、「ここに何でも置くことができ、後でゲッターから同じものを取得できる」ということです。

だから、契約を破った今、コードベースのすべてのファイルを変更することは、避けてはならないことです。これを回避すると、すべてのコードがこれらのメソッドのコントラクトが異なると想定したことになります。

それが契約ではないはずの場合、インターフェースはクライアントがオブジェクトを無効な状態にすることを許可していました。それはカプセル化の正反対です。そのフィールドを最初から実際に何にも設定できなかった場合、なぜ最初から検証が行われなかったのですか？

この同じ議論は、これらのパススルーゲッター/セッターペアの他の想定される利点にも適用されます。後で設定する値を変更することを決定した場合、契約を破っています。派生クラスのデフォルトの機能をオーバーライドすると、いくつかの無害な変更（ロギングやその他の監視不能な動作など）を超えて、基本クラスの規約に違反することになります。これは、OOの信条の1つと見なされているLiskov代入性原理の違反です。

クラスがすべてのフィールドに対してこれらのダムゲッターとセッターを持っている場合、そのクラスは不変条件がまったくなく、コントラクトもありません。それは本当にオブジェクト指向のデザインですか？すべてのクラスがそれらのゲッターとセッターである場合、それは単なるデータホルダーであり、ダムデータホルダーはダムデータホルダーのように見えるはずです。

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

このようなクラスにパススルーゲッター/セッターのペアを追加しても、価値はありません。他のクラスは、フィールドがすでに提供している操作だけでなく、意味のある操作を提供する必要があります。これが、有用な不変条件を定義して維持する方法です。

クライアント：「このクラスのオブジェクトで何ができるか？」
デザイナー：「いくつかの変数を読み書きできます。」
クライアント：「あぁ……かしこまりましたね」

ゲッターとセッターを使用する理由はありますが、それらの理由が存在しない場合、偽のカプセル化の神の名前でゲッターとセッターのペアを作成することは良いことではありません。ゲッターまたはセッターを作成する正当な理由には、検証やさまざまな内部表現など、後で行うことができる潜在的な変更としてしばしば言及されるものが含まれます。または、値はクライアントによって読み取り可能であるが書き込み可能ではない（たとえば、辞書のサイズを読み取る）必要があるため、単純なゲッターが適切な選択です。しかし、これらの理由は、後で選択する可能性があるだけでなく、選択するときにも存在するはずです。これはYAGNI（You Ai n't Gonna Need It）のインスタンスです。

多くの人がゲッターとセッターの利点について話しますが、私は悪魔の支持者を演じたいです。現在、プログラマーがすべてをゲッターとセッターにすることを決めた非常に大きなプログラムをデバッグしています。それは良いように思えるかもしれませんが、それはリバースエンジニアリングの悪夢です。

たとえば、数百行のコードを調べていると、次のような問題が発生します。

person.name = "Joe";

セッターに気付くまでは、美しくシンプルなコードです。次に、そのセッターをフォローして、person.firstName、person.lastName、person.isHuman、person.hasReallyCommonFirstNameも設定し、データベースにクエリを送信するperson.update（）を呼び出す、などです。メモリリークが発生していた場所。

ローカルのコードを一目で理解することは、読みやすさの重要な特性であり、ゲッターとセッターは壊れやすい傾向があります。だからこそ、私はできる限りそれらを避けようとし、私がそれらを使うときに彼らがすることを最小限にしようとします。

多くの理由があります。私のお気に入りは、動作を変更したり、変数に設定できるものを調整したりする必要がある場合です。たとえば、setSpeed（int speed）メソッドがあるとします。ただし、設定できるのは最大速度100だけです。次のようにします。

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

コードのどこにでもpublicフィールドを使用していて、上記の要件が必要であることに気付いた場合はどうでしょうか。セッターを変更するだけでなく、パブリックフィールドのすべての使用法を探して楽しんでください。

私の2セント:)

純粋なオブジェクト指向の世界では、ゲッターとセッターはひどいアンチパターンです。この記事を読む：ゲッター/セッター。悪の。期間。簡単に言えば、データ構造としてオブジェクトについて考えることをプログラマに奨励し、このタイプの考え方は純粋な手続き型（COBOLやCのような）です。オブジェクト指向言語では、データ構造はありませんが、動作を公開するオブジェクトのみです（属性/プロパティではありません！）

それらについては、エレガントオブジェクトのセクション3.5 （オブジェクト指向プログラミングに関する私の本）を参照してください。

アクセサーとミューテーターの利点の1つは、検証を実行できることです。

たとえば、foopublicの場合、簡単にに設定してnull、他の誰かがオブジェクトのメソッドを呼び出そうとする可能性があります。しかし、それはもうありません！ではsetFooこの方法、私はそのことを確認できたfooに設定していませんでしたnull。

アクセサーとミューテーターもカプセル化を許可します。一度設定した値を確認する必要がない場合（おそらくそれはコンストラクターで設定され、メソッドで使用されますが、変更されることはありません）、誰にも表示されません。ただし、他のクラスに表示または変更を許可できる場合は、適切なアクセサーやミューテーターを提供できます。

あなたの言語に依存します。「Java」ではなく「オブジェクト指向」のタグを付けたので、ChssPly76の回答は言語に依存することを指摘しておきます。たとえばPythonでは、getterとsetterを使用する理由はありません。動作を変更する必要がある場合は、基本的な属性アクセスにゲッターとセッターをラップするプロパティを使用できます。このようなもの：

class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)

まあ、変数/オブジェクトのカプセル化とセキュリティに必要な場合があっても、それを追加したいだけです。実際のオブジェクト指向プログラムをコーディングする場合は、ACCESSORSの過剰な使用をやめる必要があります。それらが本当に必要でない場合、それらは、変数を公開する場合とほとんど同じになります。

ありがとう、それは私の考えを本当に明確にしました。ここに、ゲッターとセッターを使用しない（ほぼ）10（ほぼ）正当な理由があります。

1. 値を設定して取得する以上のことを行う必要があることに気付いた場合は、フィールドをプライベートにすることができます。これにより、直接アクセスした場所がすぐにわかります。
   
2. そこで実行する検証は、コンテキストフリーでのみ可能です。この検証は実際にはめったに行われません。
   
3. 設定する値は変更できます。これは、発信者が[ショックホラー]に現状のまま保存してほしい値を渡した場合の絶対的な悪夢です。
   
4. 内部表現を非表示にすることができます-素晴らしいので、これらすべての操作が対称的であることを確認していますか？
   
5. シートの下の変更からパブリックインターフェースを隔離しました。インターフェースを設計していて、何かへの直接アクセスが問題ないかどうかわからない場合は、設計を続けるべきでした。
   
6. 一部のライブラリはこれを期待しますが、多くはそうではありません-リフレクション、シリアル化、モックオブジェクトはすべて、パブリックフィールドで正常に動作します。
   
7. このクラスを継承すると、デフォルトの機能をオーバーライドできます。つまり、実装を非表示にするだけでなく、一貫性をなくすことで、呼び出し元を本当に混乱させることができます。
   

私が残している最後の3つ（N / AまたはD / C）...

少し遅いと思いますが、パフォーマンスに興味のある方もいらっしゃると思います。

少しパフォーマンステストを行いました。Integerを保持するクラス「NumberHolder」を作成しました。getterメソッドを使用してその整数を読み取るか、を使用しanInstance.getNumber()て数値に直接アクセスすることができます anInstance.number。私のプログラムは、両方の方法で1,000,000,000回数値を読み取ります。このプロセスが5回繰り返され、時間が印刷されます。次の結果が得られました。

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

（時間1は直接的な方法であり、時間2はゲッターです）

ほら、ゲッターは（ほとんど）常に少し高速です。次に、異なるサイクル数で試してみました。100万ではなく、1,000万と10万を使用しました。結果：

1000万サイクル：

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

1000万サイクルで、時間はほぼ同じです。以下は10万（0.1百万）サイクルです。

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

また、サイクル数が異なる場合、ゲッターは通常の方法よりも少し高速です。これがお役に立てば幸いです。

現在の配信に必要な場合を除いて、ゲッターセッターを使用しないでください。つまり、ほとんどの運用アプリケーション、システムで変更要求がある場合、将来何が起こるかについてあまり考えないでください。

シンプルで簡単に考え、必要に応じて複雑さを加えます。

私はそれが正しいと思うか、私がアプローチが好きだという理由だけで、深い技術的ノウハウの事業主の無知を利用しません。

アクセス修飾子とビズロジックを実行することを検証するいくつかのメソッドのみを使用して、ゲッターセッターなしで記述された大規模なシステムがあります。あなたが絶対に必要な場合。何でも使ってください。

ゲッターとセッターを使用します。

• 再利用性のために
• プログラミングの後の段階で検証を実行する

getterメソッドとsetterメソッドは、プライベートクラスメンバーにアクセスするためのパブリックインターフェイスです。

カプセル化のマントラ

カプセル化のマントラは、フィールドをプライベートにし、メソッドをパブリックにすることです。

ゲッターメソッド： プライベート変数にアクセスできます。

セッターメソッド： プライベートフィールドを変更できます。

getterメソッドとsetterメソッドは新しい機能を追加しませんが、後で戻ってそのメソッドを作成するように考えを変えることができます

• より良い;
• より安全; そして
• もっと早く。

値を使用できる場所ならどこでも、その値を返すメソッドを追加できます。の代わりに：

int x = 1000 - 500

使用する

int x = 1000 - class_name.getValue();

素人の言葉で

これの詳細を保存する必要があるとしPersonます。これにPersonは、フィールドname、ageおよびがありsexます。これを行うにはname、ageおよびのメソッドを作成する必要がありsexます。我々は他の人が作成する必要があれば今、それがためのメソッドを作成することが必要になりますname、age、sexすべての繰り返し。

これを行う代わりにclass(Person)、getterメソッドとsetterメソッドを使用してBean を作成できます。したがって、明日はclass(Person class)、新しい人物を追加する必要があるときはいつでも、このBeanのオブジェクトを作成できます（図を参照）。したがって、Beanクラスのフィールドとメソッドを再利用しています。

私はこれをJavaのケースについて考え直すのにかなりの時間を費やしましたが、本当の理由は次のとおりだと思います。

1. 実装ではなくインターフェースへのコード
2. インターフェイスはフィールドではなくメソッドのみを指定します

つまり、インターフェイスでフィールドを指定できる唯一の方法は、新しい値を書き込むメソッドと現在の値を読み取るメソッドを提供することです。

それらのメソッドは悪名高いゲッターとセッターです...

遅延読み込みに役立ちます。問題のオブジェクトがデータベースに保存されていて、必要でない限り取得したくないとします。オブジェクトがゲッターによって取得される場合、内部オブジェクトは誰かが要求するまでnullになる可能性があり、ゲッターへの最初の呼び出しでそれを取得できます。

いくつかの異なるWebサービス呼び出しから一部のデータをロードするプロジェクトに渡されたベースページクラスがありましたが、それらのWebサービス呼び出しのデータがすべての子ページで使用されるとは限りませんでした。Webサービスは、すべての利点について、「遅い」の新しい定義を開拓しているため、必要がない場合にWebサービスを呼び出す必要はありません。

パブリックフィールドからゲッターに移動し、ゲッターがキャッシュをチェックします。キャッシュがない場合は、Webサービスを呼び出します。したがって、少しラッピングすることで、多くのWebサービス呼び出しが防止されました。

したがって、ゲッターによって、各子ページで何が必要かを理解する必要がなくなります。必要な場合は、getterを呼び出します。まだ取得していない場合は、getterを探しに行きます。

    protected YourType _yourName = null;
    public YourType YourName{
      get
      {
        if (_yourName == null)
        {
          _yourName = new YourType();
          return _yourName;
        }
      }
    }

これまでの回答で見逃した1つの側面、アクセス仕様：

• メンバーの場合、設定と取得の両方に対して1つのアクセス仕様しかありません
• セッターとゲッターの場合は、微調整して個別に定義できます

編集：私はこの質問に回答しました。プログラミングを学んでいる人々がこれを求めているので、その答えのほとんどは非常に技術的に有能ですが、初心者の場合はそれほど簡単には理解できません。私たちは皆初心者だったので、もっと初心者にやさしい答えを試してみようと思いました。

2つの主なものは、ポリモーフィズムと検証です。それが単なる愚かなデータ構造であっても。

次の単純なクラスがあるとします。

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

液体の量と容量（ミリリットル）を保持する非常に単純なクラス。

私が行うとどうなりますか：

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

まあ、あなたはそれがうまくいくとは思わないでしょう？ある種の健全性チェックが必要です。さらに悪いことに、最大容量を指定しなかった場合はどうなりますか？ああ、私たちは問題を抱えています。

しかし、別の問題もあります。ボトルがコンテナの1つのタイプにすぎない場合はどうなりますか？容量と量が液体で満たされた複数のコンテナがある場合はどうなりますか？インターフェースを作成することができれば、プログラムの残りの部分にそのインターフェースを受け入れさせることができ、ボトル、ジェリカン、およびあらゆる種類のものは交換可能に機能します。それはもっと良いのではないでしょうか？インターフェースはメソッドを要求するので、これも良いことです。

最終的には次のようになります。

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

すごい！そして今、私たちはボトルをこれに変更します：

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

読者への演習として、BottleOverflowExceptionの定義は残しておきます。

これがいかに堅牢であるかに注意してください。ボトルの代わりにLiquidContainerを受け入れることで、コード内のあらゆるタイプのコンテナーを処理できるようになりました。そして、これらのボトルがこの種のものをどのように処理するかはすべて異なります。状態が変化したときにディスクに状態を書き込むボトルや、SQLデータベースに保存するボトルや、GNUが他に何を知っているボトルを持つことができます。

そしてこれらすべては、さまざまなフーピーを処理するための異なる方法を持つことができます。ボトルは単にチェックし、オーバーフローしている場合はRuntimeExceptionをスローします。しかし、それは間違っているかもしれません。（エラー処理については有益な議論がありますが、ここでは意図的に非常に単純にしています。コメントの人々は、この単純なアプローチの欠点を指摘するでしょう。;））

そして、はい、私たちは非常に単純なアイデアから、はるかに優れた答えをすばやく得るようになっているようです。

また、ボトルの容量は変更できませんのでご注意ください。それは今では固まっています。これをfinalと宣言することにより、intでこれを行うことができます。ただし、これがリストの場合は、空にしたり、新しいものを追加したりできます。内部に触れることへのアクセスを制限することはできません。

誰もが対処していない3番目の問題もあります。ゲッターとセッターはメソッド呼び出しを使用します。つまり、他のどこでも通常の方法のように見えます。DTOなどに奇妙な構文を使用する代わりに、どこでも同じことができます。

「プロパティ」をサポートしていない言語（C ++、Java）またはフィールドをプロパティに変更するときにクライアントの再コンパイルが必要な言語（C＃）では、get / setメソッドを使用する方が簡単に変更できます。たとえば、setFooメソッドに検証ロジックを追加する場合、クラスのパブリックインターフェイスを変更する必要はありません。

"実際の"プロパティをサポートする言語（Python、Ruby、Smalltalkなど）では、メソッドを取得/設定する意味がありません。

OO設計の基本原則の1つ：カプセル化！

これには多くの利点があります。その1つは、バックグラウンドでゲッター/セッターの実装を変更できることですが、データ型が同じである限り、その値のコンシューマーは引き続き機能します。

次の場合はゲッターとセッターを使用する必要があります。

• あなたは概念的には属性である何かを扱っていますが、
  • 言語にプロパティ（またはTclの変数トレースなどの同様のメカニズム）がない、または
  • この使用例では、言語のプロパティサポートでは不十分です。または
  • 言語の（場合によってはフレームワークの）慣用的な規則により、このユースケースのゲッターまたはセッターが推奨されます。

したがって、これがオブジェクト指向の一般的な質問になることはほとんどありません。これは言語固有の質問であり、異なる言語（および異なる使用事例）に対して異なる回答があります。

OO理論の観点からは、ゲッターとセッターは役に立たない。クラスのインターフェイスは、クラスの状態ではなく、クラスの機能です。（そうでない場合は、間違ったクラスを記述しました。）非常に単純なケースでは、クラスが行うことは、たとえば、直角座標の点を表すだけです*。属性はインターフェースの一部です。ゲッターとセッターはそれを曇らせます。しかし、非常に単純な場合を除いて、属性もゲッターやセッターもインターフェースの一部ではありません。

別の言い方をすると、クラスのコンシューマーがspam属性を持っていることさえ知らなければならないと思っている場合、属性を自由に変更することはできず、set_spamメソッドを提供することが最後に行います。

_{*その単純なクラスでも、xおよびy値の設定を許可したくない場合があります。これは本当にクラスであれば、それはのような方法で持つべきではないtranslate、rotateなど？言語にレコード/構造体/名前付きタプルがないためクラスだけの場合、これは実際にはオブジェクト指向の問題ではありません…}

しかし、誰も一般的なOO設計を行っていません。彼らは特定の言語で設計と実装を行っています。一部の言語では、ゲッターとセッターはまったく役に立たない。

言語にプロパティがない場合、概念的には属性であるが実際に計算または検証されるものを表す唯一の方法は、ゲッターとセッターを使用することです。

言語にプロパティがある場合でも、不十分または不適切な場合があります。たとえば、サブクラスが属性のセマンティクスを制御できるようにする場合、動的アクセスのない言語では、サブクラスは属性の計算されたプロパティを置き換えることができません。

「後で実装を変更したい場合」は 質問（OPの質問と承認された回答の両方で、異なる表現で複数回繰り返されます）：それが本当に純粋な実装の変更であり、属性から始めた場合は、インターフェイスに影響を与えずにプロパティに変更できます。もちろん、あなたの言語はそれをサポートしていなければ。つまり、これは本当にまったく同じケースです。

また、使用している言語（またはフレームワーク）のイディオムに従うことも重要です。美しいRubyスタイルのコードをC＃で書くと、あなた以外の経験豊富なC＃開発者はそれを読むのに苦労するでしょう、それは悪いことです。一部の言語は、その慣習に関して他の言語よりも強い文化を持っています。そして、慣用的なゲッターがどのようにスペクトルの反対側にあるJavaとPythonが偶然にも2つの最も強い文化を持っているのは偶然ではないかもしれません。

人間の読者のほかに、規則に従うことを期待し、従わない場合は人生をより困難にするライブラリやツールがあります。Interface BuilderウィジェットをObjCプロパティ以外にフックしたり、ゲッターなしで特定のJavaモックライブラリを使用したりすることは、あなたの生活をより困難にしているだけです。ツールがあなたにとって重要である場合、それらと戦わないでください。

オブジェクト指向の設計の観点から、クラスのカプセル化を弱めることにより、両方の選択肢がコードのメンテナンスに悪影響を与える可能性があります。ディスカッションについては、次の優れた記事をご覧ください。http：//typicalprogrammer.com/？p = 23

ゲッターメソッドとセッターメソッドはアクセサーメソッドです。つまり、これらのメソッドは通常、プライベートクラスメンバーを変更するためのパブリックインターフェイスです。プロパティを定義するには、getterメソッドとsetterメソッドを使用します。メソッドとしてクラス内で定義しても、クラス外のプロパティとしてゲッターおよびセッターメソッドにアクセスします。クラス外のプロパティには、クラスのプロパティ名とは異なる名前を付けることができます。

プロパティのようにアクセスできる高度な機能を持つメンバーを作成できるなど、ゲッターメソッドとセッターメソッドを使用することにはいくつかの利点があります。また、読み取り専用プロパティと書き込み専用プロパティを作成することもできます。

getterメソッドとsetterメソッドは便利ですが、他の問題の中でも、特定の状況ではコードのメンテナンスがより困難になる可能性があるため、これらを使いすぎないように注意する必要があります。また、パブリックメンバーのように、クラス実装へのアクセスを提供します。OOPの実践では、クラス内のプロパティへの直接アクセスを推奨していません。

クラスを作成するときは、インスタンス変数をできるだけ多くプライベートにし、それに応じてゲッターメソッドとセッターメソッドを追加することを常にお勧めします。これは、クラス内の特定の変数をユーザーに変更させたくない場合があるためです。たとえば、特定のクラスに対して作成されたインスタンスの数を追跡するプライベート静的メソッドがある場合、ユーザーがコードを使用してそのカウンターを変更することは望ましくありません。コンストラクターステートメントだけが呼び出されるたびにその変数をインクリメントする必要があります。この状況では、プライベートインスタンス変数を作成し、カウンター変数に対してのみゲッターメソッドを許可します。つまり、ユーザーはゲッターメソッドを使用することによってのみ現在の値を取得でき、新しい値を設定することはできません。 setterメソッドを使用します。

コードは進化します。 データメンバーの保護が必要privateな場合に最適です。結局のところ、すべてのクラスは、の内部をねじ込むことができない明確に定義されたインターフェースを持つ一種の「ミニプログラム」である必要があります。

とはいえ、ソフトウェア開発は、クラスのその最終バージョンを、最初の試みで鋳鉄の像を押しているかのように設定することではありません。作業している間、コードは粘土のようになります。 それはあなたがそれを開発し、あなたが解決している問題領域についてさらに学ぶにつれて進化します。開発中、クラスは必要以上に相互に影響し合ったり（分解する予定の依存関係）、マージしたり、分割したりすることがあります。ですから、この議論は、宗教的に書こうとしない人たちにまで及ぶと思います。

int getVar() const { return var ; }

だからあなたは持っています：

doSomething( obj->getVar() ) ;

の代わりに

doSomething( obj->var ) ;

getVar()視覚的にうるさいだけでなく、この錯覚をgettingVar()実際のプロセスよりも複雑なプロセスにしています。（クラスライターとして）の神聖さをどのように考えるvarかは、パススルーセッターがある場合、クラスのユーザーを特に混乱させます-主張するものを「保護」するためにこれらのゲートを設置しているように見えますが、 （の神聖さvar）ですがvar、だれもがset var何をしているかを覗き見することなく、だれもが自分の好きなだけの価値を手に入れることができるので、あなたがの保護を認めるだけの価値はありません。

したがって、私は次のようにプログラミングします（「アジャイル」タイプのアプローチを想定しています-つまり、正確に認識していないコードを書くとき）何をするのない/手の込んだウォーターフォールスタイルのインターフェイスセットを計画する時間や経験がない場合）：

1）データと動作を備えた基本オブジェクトのすべてのパブリックメンバーから始めます。これが、C ++のすべての「サンプル」コードstructで、classどこでも使用する代わりに使用していることに気付く理由です。

2）データメンバーに対するオブジェクトの内部動作が十分に複雑になると（たとえば、内部std::listをなんらかの順序で保持したい場合）、アクセサー型関数が記述されます。私は自分でプログラミングしているので、常にprivateすぐにメンバーを設定するわけではありませんが、クラスの進化のどこかで、メンバーはprotectedまたはに「昇格」されますprivate。

3）完全に具体化されており、内部について厳格なルールがあるクラス（つまり、クラスは何をしているのかを正確に把握しており、内部で「技術的用語」を使用しない）にはclass、デフォルトのプライベートメンバーという指定が与えられます。選択できるメンバーはごく一部publicです。

このアプローチにより、クラスの進化の初期段階で多くのデータメンバーが移行したり、移動したりする場合など、そこに座ったり、getter / setterを熱心に書いたりすることを回避できます。

プロパティの継承がないため、アクセサの使用を検討する十分な理由があります。次の例を参照してください：

public class TestPropertyOverride {
    public static class A {
        public int i = 0;

        public void add() {
            i++;
        }

        public int getI() {
            return i;
        }
    }

    public static class B extends A {
        public int i = 2;

        @Override
        public void add() {
            i = i + 2;
        }

        @Override
        public int getI() {
            return i;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.i);
        a.add();
        System.out.println(a.i);
        System.out.println(a.getI());
    }
}

出力：

0
0
4

ゲッターとセッターは、オブジェクト指向プログラミングの2つの基本的な側面を実装するために使用されます。

1. 抽象化
2. カプセル化

Employeeクラスがあるとします。

package com.highmark.productConfig.types;

public class Employee {

    private String firstName;
    private String middleName;
    private String lastName;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
       this.firstName = firstName;
    }
    public String getMiddleName() {
        return middleName;
    }
    public void setMiddleName(String middleName) {
         this.middleName = middleName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getFullName(){
        return this.getFirstName() + this.getMiddleName() +  this.getLastName();
    }
 }

ここでは、パブリック属性とは異なり、フルネームの実装の詳細はユーザーから隠されており、ユーザーが直接アクセスすることはできません。

（プロパティをサポートする言語での）もう1つの使用法は、セッターとゲッターが操作が重要であることを意味する場合があることです。通常、プロパティで計算コストのかかる処理は行わないようにします。

ゲッター/セッターの比較的現代的な利点の1つは、タグ付き（インデックス付き）コードエディターでコードを簡単に参照できることです。たとえば、誰がメンバーを設定したかを確認したい場合は、セッターの呼び出し階層を開くことができます。

一方、メンバーがパブリックである場合、ツールはメンバーへの読み取り/書き込みアクセスをフィルタリングすることを可能にしません。ですから、メンバーのすべての使用法をごまかす必要があります。

オブジェクト指向言語では、メソッドとそのアクセス修飾子は、そのオブジェクトのインターフェースを宣言します。コンストラクターとアクセサーメソッドおよびミューテーターメソッドの間で、開発者はオブジェクトの内部状態へのアクセスを制御できます。変数が単にpublicと宣言されている場合、そのアクセスを規制する方法はありません。また、セッターを使用している場合は、必要な入力に対してユーザーを制限できます。その非常に可変的なフィードは適切なチャネルを介して送信され、チャネルは事前に定義されています。したがって、セッターを使用する方が安全です。

さらに、これはあなたのクラスを「将来を保証する」ことです。特に、フィールドからプロパティへの変更はABIブレークであるため、後で「フィールドを設定/取得」するだけではなく、より多くのロジックが必要であると判断した場合は、ABIをブレークする必要があります。それ以外の場合は、クラスに対してすでにコンパイルされています。

@getterと@setterのアノテーションのアイデアを放りたいと思います。@getterを使用すると、obj = class.fieldはできるが、class.field = objはできないはずです。@setterを使用すると、逆も同様です。@getterと@setterを使用すると、両方を実行できるはずです。これは、カプセル化を維持し、実行時に簡単なメソッドを呼び出さないことで時間を短縮します。