0

クラス内で変数を公開しないように言われました。私は常にget関数とset関数を作成する必要があります。例えば ​​：

class Whatever
{

public:
  void setSentence(const std::string &str) { sentence = str; }
  void setAnInteger(const int integer) { anInteger = integer; }

  std::string getSentence() { return sentence; }
  int getAnInteger() { return anInteger; }

private:
  std::string sentence;
  int anInteger;

};

なぜそれをすべきなのか？これらの変数を使用するだけで便利ではありませんか? また、それは良い C++ プログラミング スタイルですか?

4

7 に答える 7

5

主な理由は、カプセル化を増やすことです。クラスがこれらのメンバー変数を公開する場合、クライアント コード内の多くの関数はそれらの変数に依存します。

ある日、これらの変数の名前を変更したい、またはクラスの実装を変更して、メンバー変数の型と数が現在のものとは異なるようにしたいとします。この変更によって影響を受ける関数の数: ? (少なくとも部分的に) 書き直さなければならない関数はいくつありますか?

そうです、潜在的に無限です。それらすべてを数えることはできません。一方、ゲッターとセッターがある場合、これら 4 つの関数だけがクラスの内部表現にアクセスできます。内部表現を変更しても、クライアント関数のコードを変更する必要はありません。これらの 4 つのメンバー関数のみを変更する必要があります。

一般に、カプセル化により、将来の変更が容易になります。特定の時点で、特定のプロパティが設定されるたびにメッセージをログに記録したい場合があります。特定のプロパティが設定されるたびにイベントを発生させたい場合があります。キャッシュデータメンバーから毎回読み取るのではなく、その場で特定の値を計算したり、データベースから読み取ったりしたい場合があります。

ゲッターとセッターを使用すると、クライアント コードを変更することなく、これらの変更を実装できます。

于 2013-06-06T17:16:26.857 に答える
2

一般的な設計哲学に関する限り、アクセサーを実装する場合とアクセサーを実装しない場合について、コミュニティ全体が同意する「常に」または「決して」というものはありません。

private多くの人は、すべてのデータ メンバーを作成し、アクセサーとミューテーターを提供するようにアドバイスします。いつも。

privateクライアント コードからデータ メンバーを変更することが望ましくない場合はデータ メンバーを作成し、それ以外の場合はそのままにしておくように指示する人もいpublicます。

さらに、クラスには複数のデータ メンバーを含めるべきではなく、すべてのデータをさらに別のオブジェクト (できればstruct.

どちらが正しいかは、自分のアプローチだけでなく、所属する組織のアプローチにも依存することを念頭に置いて、自分で判断する必要があります。

あなたが私に尋ねると、私の好みはpublic、理由がなくなるまですべてを作ることです. 単純。しかし、それは私だけです。

于 2013-06-06T17:15:27.740 に答える
1

将来の開発のための健全な計画として、明示的なゲッターとセッターを作成します。クラスのユーザーがそのメンバーに直接アクセスしており、その習慣と互換性のない方法でクラスを変更する必要がある場合は、この方法でインターフェイスするコードのすべてのチャンクを変更する必要があります。ゲッターとセッターを作成すると、コンパイラはそれを直接アクセスと同等の時間になるように最適化し (それがすべての場合)、後で必要に応じてロジックを変更できます。他のコードを大量に変更する必要はありません。 .

于 2013-06-06T17:15:12.693 に答える
0

The textbook-ish answer recalled from me taking the first OOP class was: Get and set methods are used to wrap around private variables. Usually people compare between having get and set or just simply set those variables to be public; in this case, get and set approach is good because it protects those variables from being modified accidentally due to bugs and etc..

People (me when I took that class) might ask "isn't get and set also modify those variables, if so, how is that different than being modified as a public variable".

The rationale is: to have get and set function, you are asking the user or yourself to explicitly specify they want to modify the variable by calling those functions. Without calling those functions, the private variables will be less likely (still possible depends on implementation) modified unwillingly or accidentally.

于 2013-06-06T17:15:54.290 に答える
0

データのカプセル化は、OOP の主要な原則の 1 つです。これは、データと関数をクラスと呼ばれる 1 つの単位に結合するプロセスです。カプセル化の方法を使用すると、プログラマはデータに直接アクセスできません。クラス内に存在する関数を介してのみデータにアクセスできるため、クラスの実装の詳細はユーザーから隠されています。これは、メソッドの動作を誤って変更したり、メソッドの動作を知る必要がないように、呼び出し元と関数の両方を保護するためです。

于 2013-06-06T17:11:36.567 に答える
0

get または set メソッドを作成し、それをコード内で 40 回使用すると、将来の変更をより簡単に処理できます。パブリック変数を使用し、コードで 40 回使用するとします。プログラムを 1 か月開発した後、すばらしいアイデアが思い浮かびます。この変数を 1000 で割ると、計算に適した値が得られるのではないでしょうか。うわー、素晴らしいですが、今では、それを使用して変更するすべての行を見つけなければなりません。get メソッドしかなかった場合:(

これがゲッターとセッターの主な理由です。非常に単純なものであっても、ある方がよいでしょう。あなたは一度自分自身に感謝します。

于 2013-06-06T17:16:18.817 に答える
0

要するに、あなたはそれをすべきではありません。

一般に、ファウラーのリファクタリングを読むことをお勧めします。そうすれば、裸のデータを持つことによって何が妨げられるのか、どのようなアクセスが適切に調整されるのかがわかります。そして重要なことは、すべてがあなたのケースに当てはまるかどうかです。

そして、長所と短所を知っているので、この回答や他の回答の冒頭のような「すべき/すべきでない」ことは安全に無視できます。

于 2013-06-06T17:17:04.113 に答える