6

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Function_Names#Function_Names

通常の関数には大文字と小文字が混在しています。アクセサーとミューテーターは、変数の名前と一致します：MyExcitingFunction（）、MyExcitingMethod（）、my_exciting_member_variable（）、set_my_exciting_member_variable（）。

カプセル化の要点は、実装の詳細をユーザーから隠して、アクセサー/ミューテーターメソッドがメンバー変数を返す/変更するかどうかをユーザーが認識しないようにすることではないでしょうか。変数名を変更したり、オブジェクト内に格納する方法を変更したりするとどうなりますか？

編集：

インスタンス変数がある場合、int foo_それは簡単に思えます

int foo() const { return foo_; }

しかし、を返す別のメソッドを追加する場合、ifまたは？foo_ + 2に名前を付ける必要があります。barGetBar

int bar() const { return foo_ + 2; }
int GetBar() const { return foo_ + 2; }

GetBar戻り値を別のメンバー変数にキャッシュすることを選択し、後で決定した場合bar_、メソッドの名前を？に変更する必要がありbarますか？

4

4 に答える 4

5

実際、カプセル化のポイントは、クラスの内部動作を非表示にすることであり、必ずしも物の名前を非表示にすることではありません。メンバー変数の名前は重要ではありません。これは、アクセサーまたはミューテーターが提供する 間接参照のレベルです。

アクセサを使用すると、クラスの外部とのインターフェイスを壊すことなく、クラスの内部動作（メンバー変数の名前を含む）を変更できます。クラスのユーザーは、クラス内で名前が付けられているものなど、実装の詳細に気を配る必要はありませんが、外部から見た場合のクラスの動作にのみ気を配る必要があります。

言い換えると、クラスのユーザーは、メンバー変数を変更しているかどうかを判断するためにGoogleのスタイルガイドに依存するべきではありません。

于 2013-02-05T16:41:50.720 に答える
5

グーグルスタイルガイドはグーグルの従業員が従うことだけを意図しているからです。むしろ-それはスタイルガイドとしてはそれほど良くありません。

適切な例-「混乱」する可能性があるため、非定数参照による通過を明示的に禁止します。

そうです、それはカプセル化の目的を打ち負かします。それで自分を導いてはいけません。

于 2013-02-05T16:40:18.967 に答える
2

クラスを検討するとき、クライアントがアクセスできる可視状態を概念的に持っている場合があります。この状態がクラス内でどのように表されるかは別の問題であり、それがアクセサー（ゲッターとセッター）が隠すものです。私自身の命名規則でもこの区別があります。関数が概念的にゲッターまたはセッターである場合、属性の名前があり、通常は名詞になります。それ以外の場合は動詞です。そして、私は、関数が概念的にクラスの一部ではないもの（たとえば、部分的に引数に依存するもの）を取得または設定している場合と、動詞getまたはset名前が含まれている場合と、関数が実際に変更している場合を区別します概念的には属性であり、その場合はそうではありません。

残りの部分については、ほとんどのスタイルガイドのように、誰もがこれに完全に同意しているわけではありません。たとえば、それらの命名規則が好きかどうかはわかりません。それらは、任意の規則であるため、命名規則と呼ばれます。唯一の本当の厳しいルールは、タイプ、マクロ、その他のものを区別する必要があり、名前がアンダースコアで開始または終了してはならないということです。（よりソフトなルールもいくつかあります。ローカル変数の名前がグローバル変数の名前よりも長くなるという規則には非常に疑いがあります。）

于 2013-02-05T17:16:56.190 に答える
1

私は常識を過度に想定しているかもしれませんが、公開されたインターフェースを保持することは、ネーミングガイドに従うことよりも優先されると確信しています。

元のbar/GetBar関数はアクセサーではないのでGetBar、通常の名前ガイドに従って、と呼ばれるべきだと思います。

bar_後で、ある意味で関数がアクセサーになるように導入する場合は、削除しないでくださいGetBar。同じことをするように定義された関数も追加できると思いますが、スタイルガイドでそれを要求するとは思いbar()ません。

また、公開されたインターフェイスに、ユーザー（および呼び出し元）が「アクセサー」と見なす関数が含まれるとすぐに、カプセル化はある程度ウィンドウの外に出ます。これは、その動作の代わりにオブジェクト。関数が現在の実装でメンバー変数の値を返すからといって、それがアクセサーとして文書化されなければならないという意味ではありません。しかし、アクセサとして公に認められている関数を書くことを主張する場合、Googleはそれらに名前を付ける方法を教えてくれます。古典的な例は、クラス全体がフィールドのバンドルとして公に定義されており、動作が少しある可能性があるため、十分にダムなデータレコードオブジェクトにアクセサが合理的に含まれている可能性があることです。

私はそのスタイルガイドを数回読んだことがありますが、私はGoogleで働いたことがないので、彼らのコードレビューが実際にそれをどのように適用するかについては知りません。その規模の組織は、細部にわたって完全に一貫しているとは限らないと思います。だからあなたの推測はおそらく私のものと同じくらい良いです。

于 2013-02-05T17:14:56.470 に答える