質問編集履歴
5
typo
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
すいません。まず、この話題はC++言語限定とさせて下さい。広げると収
|
|
1
|
+
すいません。まず、この話題はC++言語限定とさせて下さい。広げると収拾がつかなくなる予感がしますので。
|
|
2
2
|
|
|
3
3
|
下記のようなメンバ変数mMemberへのアクセス方法について、皆さんはどちらで定義しますか？
|
|
4
4
|
たぶんケースバイケースと思います。どんな時にprivate定義してアクセサを提供(Foo型)し、どんな時にpublic定義(Bar型)しますか？
|
|
@@ -65,7 +65,7 @@
|
|
|
65
65
|
あくまでも方針なのでそれなりに例外もあるとは思いますが、これで罪悪感を感じず(笑)にpublic定義できます。
|
|
66
66
|
|
|
67
67
|
######ところで、何故にC++限定だったのか？
|
|
68
|
-
最初に「この話題はC++言語限定とさせて下さい。広げると収
|
|
68
|
+
最初に「この話題はC++言語限定とさせて下さい。広げると収拾がつかなくなる予感がしますので。」と記載させて頂きました。いまいち明確に表現できてなかったのですが、今回の議論を通じてやっと言語化できました。
|
|
69
69
|
|
|
70
70
|
C++言語でのプログラミングでは、可読性やメンテナンス性も当然熟慮しますが、高速性もかなり重視しており、多少（場合によっては大きく）可読性／メンナナンス性を劣化させてでも速度を取る言語です。ポインタはその典型例と思います。更に参照とかconst参照とか右辺値参照とかもうパニック・レベルですね。まして、テンプレート・メタ・プログラミングと来た日にはorz。
|
|
71
71
|
|
4
微修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -30,7 +30,7 @@
|
|
|
30
30
|
ベストアンサーは、C++らしい方針を最も明確に記載して頂けたcatsforepawさんにさせて頂きました。
|
|
31
31
|
また、「ブレーク貼れるようにアクセサ」という使い方に気づかせて頂けたこともありがたいです。
|
|
32
32
|
|
|
33
|
-
【検討のポイント】
|
|
33
|
+
**【検討のポイント】**
|
|
34
34
|
私はシンプルイズベスト信者なので、メリットのない複雑さは悪と考えます。
|
|
35
35
|
なので、メリットもないのにアクセサを設けるのは悪なわけです。
|
|
36
36
|
ということは、アクセサを設けるメリットは何か？がポイントになります。
|
|
@@ -39,7 +39,7 @@
|
|
|
39
39
|
また、そのような機能の追加も含め、何らかの変更が予想されるケースでは、アクセサを設けるメリットが明確ですので、こちらも検討不要です。
|
|
40
40
|
変更が予想されない時でも、アクセサ化するメリットがあるのか？が検討のポイントとなります。
|
|
41
41
|
|
|
42
|
-
【アクセサを設けるメリットのまとめ】
|
|
42
|
+
**【アクセサを設けるメリットのまとめ】**
|
|
43
43
|
皆さんの意見のうち、【検討のポイント】的にメリットが明確なものを選択させて頂き、私が理解した内容で纏めてみました。（多少違っているかも知れません。その時はごめんなさい。）
|
|
44
44
|
|
|
45
45
|
**raccy**さん
|
|
@@ -57,7 +57,7 @@
|
|
|
57
57
|
逆に、変更しても影響範囲が狭い場合はアクセサを設けるメリットが小さいのでpublicのままでも十分ということです。
|
|
58
58
|
そして、C++の場合は比較的熟練したプログラマが担当するケースも少なくないと思います。そのようなケースでは密結合部分についてpublicとして開示した方が、見通しも良くなりポインタ経由アクセス等、使えるテクニックも増えるのでより好ましいと感じます。
|
|
59
59
|
|
|
60
|
-
【私的な方針のまとめ】
|
|
60
|
+
**【私的な方針のまとめ】**
|
|
61
61
|
私自身が担当しているプロジェクトは小規模・少数精鋭型が多いです。
|
|
62
62
|
そこで、下記方針を選択することにしました。
|
|
63
63
|
- メンバ変数が少しの場所（数カ所程度？）からしかアクセスされないものについては、publicとする。
|
3
結果報告追記
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -23,7 +23,53 @@
|
|
|
23
23
|
しかし、構造体(データを保持することが主目的)として設計したクラスであれば良いのですが、オブジェクト指向的に設計したクラスでは抵抗を感じてしまい、躊躇してます。
|
|
24
24
|
そこで、参考にさせて頂きたく、皆さんのご意見をお聞かせ下さい。
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
##結果報告
|
|
27
|
+
この議論を通じて、やっと自分なりの方針を明確にできました。
|
|
28
|
+
皆さん、ありがとうございます。
|
|
27
29
|
|
|
30
|
+
ベストアンサーは、C++らしい方針を最も明確に記載して頂けたcatsforepawさんにさせて頂きました。
|
|
31
|
+
また、「ブレーク貼れるようにアクセサ」という使い方に気づかせて頂けたこともありがたいです。
|
|
32
|
+
|
|
28
|
-
【
|
|
33
|
+
【検討のポイント】
|
|
34
|
+
私はシンプルイズベスト信者なので、メリットのない複雑さは悪と考えます。
|
|
35
|
+
なので、メリットもないのにアクセサを設けるのは悪なわけです。
|
|
36
|
+
ということは、アクセサを設けるメリットは何か？がポイントになります。
|
|
37
|
+
|
|
38
|
+
なお、アクセスされたタイミングで何らかのアクションを行うようなケースはメリットもなにも必須事項なので検討不要ですね。
|
|
39
|
+
また、そのような機能の追加も含め、何らかの変更が予想されるケースでは、アクセサを設けるメリットが明確ですので、こちらも検討不要です。
|
|
40
|
+
変更が予想されない時でも、アクセサ化するメリットがあるのか？が検討のポイントとなります。
|
|
41
|
+
|
|
42
|
+
【アクセサを設けるメリットのまとめ】
|
|
43
|
+
皆さんの意見のうち、【検討のポイント】的にメリットが明確なものを選択させて頂き、私が理解した内容で纏めてみました。（多少違っているかも知れません。その時はごめんなさい。）
|
|
44
|
+
|
|
45
|
+
**raccy**さん
|
|
46
|
+
メンバ変数へのアクセスは原則Read Onlyとするので、常にアクセサを使う。
|
|
47
|
+
|
|
48
|
+
私的な見解：
|
|
49
|
+
この基準（コーディング規約かも？）により、多少不慣れな人がいても比較的安全に開発を進めることができると言うメリットがあると感じます。
|
|
50
|
+
大勢の人がメンテナンスするようなプロジェクトで特に有用ですね。
|
|
51
|
+
|
|
52
|
+
**catsforepaw**さんと**yohhoy**さん
|
|
53
|
+
変更が予想されないとはいえ可能性は0ではないので、アクセス時の処理変更の影響範囲が大きい場合、その影響を軽減するためにアクセサを設ける。
|
|
29
|
-
|
|
54
|
+
また、多くの場所からアクセスされる時はアクセサを設けるとデバッグしやすい。
|
|
55
|
+
|
|
56
|
+
私的な見解：
|
|
57
|
+
逆に、変更しても影響範囲が狭い場合はアクセサを設けるメリットが小さいのでpublicのままでも十分ということです。
|
|
58
|
+
そして、C++の場合は比較的熟練したプログラマが担当するケースも少なくないと思います。そのようなケースでは密結合部分についてpublicとして開示した方が、見通しも良くなりポインタ経由アクセス等、使えるテクニックも増えるのでより好ましいと感じます。
|
|
59
|
+
|
|
60
|
+
【私的な方針のまとめ】
|
|
61
|
+
私自身が担当しているプロジェクトは小規模・少数精鋭型が多いです。
|
|
62
|
+
そこで、下記方針を選択することにしました。
|
|
63
|
+
- メンバ変数が少しの場所（数カ所程度？）からしかアクセスされないものについては、publicとする。
|
|
64
|
+
- 外部に公開する部分も含め、これに該当しない場合はアクセサ化する。
|
|
65
|
+
あくまでも方針なのでそれなりに例外もあるとは思いますが、これで罪悪感を感じず(笑)にpublic定義できます。
|
|
66
|
+
|
|
67
|
+
######ところで、何故にC++限定だったのか？
|
|
68
|
+
最初に「この話題はC++言語限定とさせて下さい。広げると収集がつかなくなる予感がしますので。」と記載させて頂きました。いまいち明確に表現できてなかったのですが、今回の議論を通じてやっと言語化できました。
|
|
69
|
+
|
|
70
|
+
C++言語でのプログラミングでは、可読性やメンテナンス性も当然熟慮しますが、高速性もかなり重視しており、多少（場合によっては大きく）可読性／メンナナンス性を劣化させてでも速度を取る言語です。ポインタはその典型例と思います。更に参照とかconst参照とか右辺値参照とかもうパニック・レベルですね。まして、テンプレート・メタ・プログラミングと来た日にはorz。
|
|
71
|
+
|
|
72
|
+
この辺がスピードを犠牲にして可読性やメンテナンス性に注力しているJavaやC#のような言語と大きく使い方が異なる部分と思います。
|
|
73
|
+
その結果、アクセサを定義する／しないの判断基準もそれなりに異なっていることが予想できるため、C++での方針を形作りたい自分にとっては、言語を限定した方がよいということだったのです。
|
|
74
|
+
|
|
75
|
+
それでは、最後にもう一度、Stripeさんも含め、ご回答頂いた皆さんありがとうございました。
|
2
getMember\(\)にconst修飾漏れ追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -8,7 +8,7 @@
|
|
|
8
8
|
private:
|
|
9
9
|
int mMember;
|
|
10
10
|
public:
|
|
11
|
-
int getMember() {return mMember;}
|
|
11
|
+
int getMember() const {return mMember;}
|
|
12
12
|
void setMember(int iMember) {mMember=iMember;}
|
|
13
13
|
：
|
|
14
14
|
};
|
1
追記
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -21,4 +21,9 @@
|
|
|
21
21
|
```
|
|
22
22
|
FooもBarと同様にmMemberを事実上全て開示してます。ですので、Foo型を用いるメリットはmMemberがアクセスされる際に何か処理を追加してもI/Fを変えないで済むことだけです。ですので、処理を追加する可能性がほぼ想定されないなら、無駄に複雑にしないためにBar型を使うべきです。
|
|
23
23
|
しかし、構造体(データを保持することが主目的)として設計したクラスであれば良いのですが、オブジェクト指向的に設計したクラスでは抵抗を感じてしまい、躊躇してます。
|
|
24
|
-
そこで、参考にさせて頂きたく、皆さんのご意見をお聞かせ下さい。
|
|
24
|
+
そこで、参考にさせて頂きたく、皆さんのご意見をお聞かせ下さい。
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
【追記】
|
|
29
|
+
もう少し多くの方のご意見を聞きたいので、今しばらく未解決のままにさせて下さい。
|