コーディング規約第3条

インデント幅とタブ幅は全く別問題だな。
タブ幅は一般的には幅8だが、これはエディタ依存で4に設定してる奴もいるだろう。
インデント幅はあくまでコーディングスタイル。

インデントにタブを使ったり、それどころかスペースと混ぜるなんてアホすぎる。
もっとマトモなエディタ使えよ、と。
俺はEmacs使ってるが・・・Emacs自体はGNUのウンココーディングスタイルで書かれてんだよなぁ。。

13 ：デフォルトの名無しさん：2007/02/06(火) 17:35:42

俺はタブを使ってインデントしてるんだが（ハードタブっていうのか？）
こうしておけば各自見やすいタブ幅に設定しておけるしいいんじゃないかと思っている。

14 ：デフォルトの名無しさん：2007/02/06(火) 18:23:12

要は
スペース派 == これが俺のインデント幅だ。従え。
タブ派 == インデント幅は各自好きにしろ。

15 ：デフォルトの名無しさん：2007/02/06(火) 18:42:19

あとは、さしずめ
混在派: 考えたこともない。
てとこか?

16 ：デフォルトの名無しさん：2007/02/06(火) 19:32:25

コピペするからスペースにしとこ派

17 ：デフォルトの名無しさん：2007/02/06(火) 19:39:50

VCのデフォルト派

18 ：デフォルトの名無しさん：2007/02/06(火) 21:05:15

こういう風に書く人なら、ハードもソフトも関係ないが
　int i;
　char c;
　struct dirent dirs;

こういう風に書く奴が多いじゃん？
　int　　　　　　 i;
　char　　　　　 c;
　struct dirent dirs;

タブストップの設定が違うと
　　int　　　　　　　　　　　　　 i;
　　char　　　　　　　　　　 c;
　　struct dirent dirs;

19 ：デフォルトの名無しさん：2007/02/06(火) 21:14:59

タブとスペース使い分けたいんだけどね。
>>18 みたいなケースではスペース使って、
インデントにはタブ。
□をタブ、_ をスペースとして、↓みたいに。

□□func(a, b, c,
□□______d, e, f);

20 ：デフォルトの名無しさん：2007/02/06(火) 21:58:24

>>19
すこしずれてる

21 ：デフォルトの名無しさん：2007/02/06(火) 22:29:53

>>18
俺は

func() {
<TAB>int<SP><SP>i;
<TAB>char<SP>c;
}

みたいにする。
要するに、TABは必ず行頭から連続しているようにする。

言ってることは>>19と同じ罠

22 ：デフォルトの名無しさん：2007/02/06(火) 23:12:34

>>18
2番目の書き方は C の構造体のメンバ変数宣言とかでよく見るけど
最高に自己満足な気がする。
後で長い名前の変数作ることになったら
シコシコとスペースなりタブなり追加するんだろうか。

時間の無駄だからさっさとやめろと言いたい。
規約で強制されそうになったら頑として抵抗する。

23 ：デフォルトの名無しさん：2007/02/06(火) 23:34:43

へ? 普通そういうのってエディタのマクロでやるでしょ。
プログラマなんだからさ。

24 ：デフォルトの名無しさん：2007/02/06(火) 23:46:51

漏れもIDEで変数宣言の部分を範囲選択して整形コマンド一発かとオモタ。
でも簡単にリファクタリングできるからって意味もなくしまくっていいわけでもないだろ。
本質的でない変更がdiffに混ざったりすると混乱する
(リファクタリングだけでちゃんとコミットしてればいいんだが)

25 ：デフォルトの名無しさん：2007/02/07(水) 00:52:06

>>24
最近のdiff/merge系のツールは賢いから、
そーゆー本質的でない変更は無視できるように設定できるだろ。

26 ：デフォルトの名無しさん：2007/02/07(水) 01:00:41

それよりも。ここで何故
リファクタリング
という言葉が出てくるのかがわからない

27 ：デフォルトの名無しさん：2007/02/07(水) 03:21:27

さういうツールがろくに普及してないから
インデントの設定とかが、議論のネタになるんだろｗ

ソースだけ引き継ぐこともあるしなあ
（完成品だけ引き継いで、バージョンアップしたこともあるがｗ）

28 ：デフォルトの名無しさん：2007/02/07(水) 03:30:31

おまいら、三項演算子をどう思うよ。

29 ：デフォルトの名無しさん：2007/02/07(水) 03:38:16

・アホは三項演算子使用禁止（そして、お前はアホだ）

・「( 論理式 ) ? 式1 : 式2」という書き方は禁止
　全体を括弧でくくって、「( 論理式 ? 式1 : 式2 )」と書け

30 ：デフォルトの名無しさん：2007/02/07(水) 07:54:28

>>26
リファクタリングを、コードの整形レベルのことだと思ってるってこと
だろう。

31 ：デフォルトの名無しさん：2007/02/07(水) 09:22:23

>>28
普通に使うよ。使った方がコードが読みやすくなると思ったら迷わず使う。

32 ：デフォルトの名無しさん：2007/02/07(水) 10:09:26

>>29
なんで、三項演算子使っちゃいけないの？

33 ：デフォルトの名無しさん：2007/02/07(水) 10:51:29

よく言われるのは、「読みにくいから」かな・・・
まー使ったほうが綺麗に読みやすくなる場合もあると思うんだが、
アホに使用を許すと場をわきまえずバンバン使って、えらく読みにくくなる場合が多い。
どうせ構文砂糖なんだから、禁止しても害は無いので禁止しちまえ、という事らしい。

34 ：デフォルトの名無しさん：2007/02/07(水) 10:52:26

はいはい、そうですか。

35 ：デフォルトの名無しさん：2007/02/07(水) 12:10:12

ふたこと、言わせててくれ

三項演算子より条件演算子が正しい表現ではないのか
条件演算子はネスト禁止

36 ：デフォルトの名無しさん：2007/02/07(水) 12:12:32

なるほど、君が言いたい事はよーくわかったぞ。

37 ：デフォルトの名無しさん：2007/02/07(水) 12:37:07

HRESULT hr;
FALSE |
　FAILED(hr = ...) |
　FAILED(hr = ...) |

が30行ぐらい延々とつづくコードをみたことがある。
中で三項演算子もばっちり使ってた。

生暖かく見守ってたらやっぱりメンテで叫んでた。

38 ：デフォルトの名無しさん：2007/02/07(水) 12:38:43

うーむ、そうかそうか。

39 ：デフォルトの名無しさん：2007/02/07(水) 13:21:16

そう言えば、オープンソースのプロジェクトの規約ってどんなんなってんだ？
規約のリンク集みたいなサイトってある？

40 ：デフォルトの名無しさん：2007/02/07(水) 13:25:56

そんなもんあるかボケェ

41 ：デフォルトの名無しさん：2007/02/07(水) 13:42:20

オプソだからといって全体がどこかの規約に従ってるわけじゃなく
プロジェクトごとに定めているのがふつーだわな。

Linux kernel coding style(ソースツリーにも入ってる)
http://pantransit.reptiles.org/prog/CodingStyle.html
1インデント幅が8スペース分のTAB。

GNU Coding Standards
http://www.gnu.org/prep/standards/standards.html
変態的な{}の使い方が特徴。

Code Conventions for the Java Programming Languag
http://java.sun.com/docs/codeconv/
オプソじゃないけどJavaでは有名。

Mozilla Coding Style Guide
http://www.mozilla.org/hacking/mozilla-style-guide.html
いろいろC++の機能の利用を制限しているのがつらそう。

ぐぐるとjakartaのとかもあるな。

42 ：デフォルトの名無しさん：2007/02/07(水) 16:35:13

GNUキモいな

43 ：デフォルトの名無しさん：2007/02/07(水) 17:18:07

>>42
gccとemacsの世話になりっぱなしだが、あれだけはイヤ。

44 ：デフォルトの名無しさん：2007/02/07(水) 18:07:33

あの規約のおかげで、コードが流用されたときに
出所がすぐ分かるとかｗ

ねーか、キモいからか書き換えられる悪寒

45 ：デフォルトの名無しさん：2007/02/07(水) 20:07:06

>41
おー、こんなの読みたかった、thx
しかしGNUのブレースの書き方…ｗ

Mozilla は和訳もあるみたいね。
ttp://www.mozilla-japan.org/hacking/mozilla-style-guide.html

46 ：デフォルトの名無しさん：2007/02/07(水) 22:27:45

>>13
> 俺はタブを使ってインデントしてるんだが（ハードタブっていうのか？）
> こうしておけば各自見やすいタブ幅に設定しておけるしいいんじゃないかと思っている。
>>14
> タブ派 == インデント幅は各自好きにしろ。

　　char *hoge = {"hoge", "piyo",
　　　　　　　　　"fuga"};

　　if (hoge ||
　　　　piyo)

　　function(arg1,
　　　　　　arg2);

行頭だけタブ使っていても、一行が長くなる時には改行入れるでしょ。
その時にどうしてもタブとスペースが混ざったり、混ざらない場合でも
人によっては見苦しい汚いコードになるわけだ。

他人に公開するソースにはタブなんて使うもんじゃないよ。

Tabs are evil
http://www.google.com/search?q=%22Tabs+are+evil%22&hl=en&ie=utf-8&oe=utf-8

47 ：デフォルトの名無しさん：2007/02/07(水) 22:53:35

じゃあ
http://www.jwz.org/doc/tabs-vs-spaces.html
は？

48 ：デフォルトの名無しさん：2007/02/07(水) 23:13:59

TABな人です。

継続行は元の行より1レベル余計にインデントするだけで、
位置あわせは全くやりませんね。

49 ：デフォルトの名無しさん：2007/02/08(木) 00:23:01

>>28
ローカル変数を const にしたいときに使うので良く使う。
こういうときに匿名関数とか欲しくなる。

50 ：デフォルトの名無しさん：2007/02/08(木) 02:47:20

なんで人間がソースコードを整形するんだよ。

インデントなんか何だっていいんだよ、
チェックインする前に自動整形かければ済むことだ。

人様のコードを読む時も、自動整形かければ済むことだ。

まぁ、インデントがスペースだと文句を言う人は、
キーボードの→を押して、ぼーっと画面を眺めるような間抜けだろう。

51 ：デフォルトの名無しさん：2007/02/08(木) 06:34:06

そうかそうか、よーくわかったぞ。

52 ：デフォルトの名無しさん：2007/02/08(木) 14:08:08

>>50
なんで人間がソースコードを整形しないんだよ。

インデントって重要なんだよ、
チェックインする前には、必ず手作業で整形する習慣をつけるべき。

人様のコードを読む時に、自動整形するなんて言語道断。

まぁ、自動整形がいいんだと文句を言う人は、
世の中には例外というものがあって、自動整形することで
醜くなるソースコードがあることすら理解できない間抜けだろう。

53 ：デフォルトの名無しさん：2007/02/08(木) 16:30:10

なるほど、そうかそうか。

54 ：デフォルトの名無しさん：2007/02/08(木) 21:57:34

>>52
一本とれてよかったね。

55 ：デフォルトの名無しさん：2007/02/09(金) 04:31:13

なんか、ソースが世代ごとに、違う整形ツールで整形を受けていって、
しまいにゃあ、いろんなところが崩壊して行きそう
マイケルジャクソンみたいに

56 ：デフォルトの名無しさん：2007/02/09(金) 07:26:37

・使う整形ツールを規約で規定する
・ツール側の非互換な変更に備えて、バージョンまで指定する
・ツールを変更した場合、そのツールで全ソースを整形し直す

くらいで解決できそう。

57 ：デフォルトの名無しさん：2007/02/09(金) 15:12:40

>>46
その例だと、こうする。TABの幅が変わってもずれない。（可変幅fontな奴はさすがにいないだろう）
<TAB>char *hoge = {"hoge", "piyo",
<TAB>　　　　　　　　　"fuga"}; // TABのあとに14文字スペース。前の行のcharのc前までがTAB

まあ個人的なコードで他人関係ないならこう書くけど
<TAB>char *hoge = {
<TAB><TAB>"hoge",
<TAB><TAB>"piyo",
<TAB><TAB>"fuga",
<TAB>};

58 ：デフォルトの名無しさん：2007/02/09(金) 16:13:50

>>57
等幅フォントという前提自体が美しくない。
まぁ、>57の前者程度であれば空白が詰まろうとたいした問題ではないが。
駄菓子菓子、パラメータや型名の後を揃えたがるのはどうにもこうにも美しくない。
Ex.
sumType_t funcName(
int foo, /* この行にfooとbarをそろえるための空白を入れている */
const char * bar
)
{

59 ：デフォルトの名無しさん：2007/02/09(金) 20:07:14

プロポーショナルフォントなど使うスットコドッコイは逝ってしまえ的な

60 ：デフォルトの名無しさん：2007/02/09(金) 20:57:01

>>59
現にここに貼ってもプロポーショナルフォントで見る羽目になるわけで。

61 ：デフォルトの名無しさん：2007/02/10(土) 02:21:33

そういえばプロポーショナルなフォントでソースコード書かないね。
ハードウェア・ソフトウェアとも、十分プロポーショナルフォントで行ける環境はあるのに。

メールなんか、Outlook Expressやらのせいで、どちらかというと等幅の方が劣勢だよね。

62 ：デフォルトの名無しさん：2007/02/10(土) 02:22:05

フォント自体は等幅なのだが、
キーワードが太字になったり斜体になったりして
結局揃わない罠。

63 ：デフォルトの名無しさん：2007/02/10(土) 02:25:49

>>61
フォント変えられるエディタで好きに書けよ

64 ：デフォルトの名無しさん：2007/02/10(土) 03:04:12

double mat[9] = {
　　 1.0,　　10,0, 100.0,
　125.0,　　　1.0,　12.4,
　　45.0, 1250.0,　25.0
};

こんな感じのを書くときとか、やっぱ都合が悪いわけで

65 ：デフォルトの名無しさん：2007/02/10(土) 12:22:00

>>61
等幅等幅いってんのは日本人だけだろ？

66 ：デフォルトの名無しさん：2007/02/10(土) 12:52:45

そりゃそうだろ。アラビア語とか等幅の概念自体ありえないし

67 ：デフォルトの名無しさん：2007/02/10(土) 13:01:35

>>64
Tabを使えとあれほど

68 ：デフォルトの名無しさん：2007/02/10(土) 13:03:21

手持ちの英語で書かれてる本は、コード部分は等幅クーリエの模様だな。
アラビア語の書籍は持ってないので分からん。

69 ：デフォルトの名無しさん：2007/02/10(土) 13:07:45

よく考えたらソースコードにアラビア文字は使わないか。
日本語プログラミング言語が基本的にゲテモノ扱いなのと一緒で

70 ：デフォルトの名無しさん：2007/02/10(土) 13:40:11

プロポーショナルフォントでコーディングはないだろ。
むこうでもタイプライタ系の等幅フォントだよな。Courier NewとかConsolasとか。

71 ：デフォルトの名無しさん：2007/02/10(土) 13:49:46

Pascalのソースってプロポーショナルで印刷したりしない? Delphiは知らないけど

72 ：デフォルトの名無しさん：2007/02/10(土) 14:12:43

ストラウストラップの本のコードは確かプロポーショナルだったような

73 ：デフォルトの名無しさん：2007/02/10(土) 14:38:29

プロポーショナルだったら不要な宗教戦争はなかったかもなあ。

74 ：デフォルトの名無しさん：2007/02/10(土) 15:34:14

Pascal覚え立ての頃、+=の本をまねしてソースコードを
pretty printすることはあったけど今はやらないなぁ。

だいたいソースコードを印刷すること自体まずやらん。

75 ：デフォルトの名無しさん：2007/02/10(土) 16:29:50

COBOLとかRPGとか、桁位置に意味がある言語だとプロポーショナルはつらいなｗ

76 ：デフォルトの名無しさん：2007/02/10(土) 16:30:22

>72
D&Eだっけ？すごく読みにくかった記憶が。

77 ：デフォルトの名無しさん：2007/02/10(土) 16:36:58

印刷されているものだと、実際のソースコードではなく、擬似コードっぽいものだと
プロポーショナルで書かれていることもあるみたい。

今見たら、ソフトウェア博物誌とかそうなってた。

78 ：デフォルトの名無しさん：2007/02/11(日) 01:28:35

>>74
> だいたいソースコードを印刷すること自体まずやらん。
EclipseからわざわざソースをエクスポートしてDFで差分を表示して
印刷してレビューとかしてます。いやさせられてます。もうアホかと

79 ：デフォルトの名無しさん：2007/02/11(日) 02:09:36

>>67
タブじゃ全然無理
場所によって桁数がちがうだろ、よく見ろ

80 ：デフォルトの名無しさん：2007/02/15(木) 11:03:40

コードの整形ツールって皆さん何使ってますか？
http://sourceforge.net/projects/gcgreatcode/
これ？

81 ：デフォルトの名無しさん：2007/03/12(月) 01:51:52

indent

82 ：デフォルトの名無しさん：2007/03/12(月) 03:04:05

手元にあるJavaクイックリファレンスでは
プロポーショナルでびっしり印刷してある。
パッと視界に収まるのは良いけど。

83 ：デフォルトの名無しさん：2007/03/13(火) 23:50:45

ところで、<winnt.h>を見たら、その中で使われている構造体のメンバには
さっぱりハンガリアン記法が使われていなかった。

このヘッダ自体は古くからあると思うんだけど、
そこでハンガリアンが使われていないということが意外だった。

84 ：・∀・）っ-○◎●：2007/03/14(水) 00:44:27

Win 9xのチームとNTチームは元々別で、
ハンガリアンマンセーなのは9xのほう。

ってばっちゃが言ってた

85 ：・∀・）っ-○◎●：2007/03/14(水) 01:31:56

ちなみに,NETではハンガリアン記法一切ない

86 ：デフォルトの名無しさん：2007/03/14(水) 05:29:57

NTカーネルモードのコードにもハンガリアン使われてないしね

87 ：デフォルトの名無しさん：2007/03/14(水) 05:50:47

カトラーがハンガリアンを嫌ってなかったっけ。

88 ：デフォルトの名無しさん：2007/03/14(水) 05:58:41

カーソル合わせりゃ型が出てくる統合環境で
iHoge とか dwFoo とか書く意味はまるでないッ
その変数の「意味」を頭に書き加えるのならやってもいいッ

89 ：デフォルトの名無しさん：2007/03/14(水) 06:15:43

デイヴ・カトﾁｬﾝ

90 ：デフォルトの名無しさん：2007/03/14(水) 08:14:01

本来のハンガリアン記法は型名略記なんかじゃなかったんだよな。

91 ：デフォルトの名無しさん：2007/03/14(水) 09:13:06

↓間違ったコードは間違って見えるようにする
ttp://tinyurl.com/2cgb8n

型名プレフィックスをつけるだけの記法を
ハンガリアンと読んでいる奴はアホ。
その記法をマンセーしてる↓みたいな奴はもっとアホ。
ttp://homepage2.nifty.com/well/HungarianNotation.html

92 ：デフォルトの名無しさん：2007/03/14(水) 14:06:04

>>91
激しく同意

93 ：デフォルトの名無しさん：2007/03/14(水) 23:21:44

ハンガリアンを積極的に使うつもりはないけど、

HWND hWnd;

とか書いちゃってるなあ。

HWND windowHandle;

でいいはずだが。

94 ：デフォルトの名無しさん：2007/03/14(水) 23:41:47

ハンドルのhはむしろアプリケーションハンガリアンに近いものだと俺は思っている。
（やや苦しいかもしれないが）例えばC#なんかだとみんなIntPtrになるからハンドルにhを付けるのも生きてくる。
C/C++のtypedefは型名にアプリケーションハンガリアンを適用するためにも使えるという見方もできる。
（それが行き過ぎて型名とプレフィックスを結び付けるシステムハンガリアンになってしまったのかもしれないが）

そういう訳もあって俺はウィンドウハンドルの変数名・プレフィックスをhWndとするのではなく、hwndとしている。
HANDLE hHoge = hwndHoge;なんて有り得ない。

95 ：・∀・）っ-○◎●：2007/03/15(木) 00:09:41

なにかとATL::CWindow使ってる俺は wnd～もしくは～Window

96 ：デフォルトの名無しさん：2007/03/15(木) 03:32:04

GUI部品に btnHoge や tblFuga はありだと思う。
だってボタンやテーブルなんだし。

97 ：デフォルトの名無しさん：2007/03/15(木) 04:08:24

hogeButton とか fugaTable とか、略さず書くべきだと思うんだ。
妙な略語は読みにくい。
今時の環境なら補完くらいしてくれるから、長くてもtypoは起きにくいし。
へたすると、短くて補完効きづらい名前のがtypoしやすいくらい。

それに、 button とか table とかは接頭辞じゃなくて接尾辞にすべきだと思う。
型より意味のが重要なんだから。

98 ：デフォルトの名無しさん：2007/03/15(木) 05:04:25

できればcamel caseはやめてほしい…
などと言い合いの軸をもう一つ増やしてカオスに追い込んでみようかな。

99 ：デフォルトの名無しさん：2007/03/15(木) 05:25:13

camel caseやめると語のつなぎは_かえ？

100 ：デフォルトの名無しさん：2007/03/15(木) 09:10:00

俺は変数は_繋ぎの小文字で関数はCamelにしてる。
変数に大文字が混入するのは何となく嫌だ。

101 ：デフォルトの名無しさん：2007/03/15(木) 09:51:22

>>97
頭に持ってくるか尻に持ってくるかは、
どっちの意味を重視するか、どっちから探したいかによるかと。
俺の頭の中ではボタンは型ではなくて、単にボタン。
hoge するものであること以上に
画面上のボタンであることをイメージするので
(hoge という意味もボタンという意味も持つ。型はない。)
頭に持ってきたいんです。

なんだけど、hogeButton の方が自然な名称だとは思う。
まぁ規約に従いますよ。

102 ：デフォルトの名無しさん：2007/03/15(木) 10:15:28

ボタン型であるquit(型ハンガリアンだが)じゃなくて
quitボタンという画面部品だから、付けるならquitButtonだなー。
quitButtonで呼ぶ処理ルーティンの名前はquitかもしれぬ。

103 ：デフォルトの名無しさん：2007/03/15(木) 10:21:36

quitButton を見て「変数名に型情報入れるなボケ」
とか言ってくるやつがたまに居るんだが
どうやって対処したらいいんだろ。

型じゃねーよと言っても分かってもらえない。

104 ：デフォルトの名無しさん：2007/03/15(木) 10:31:57

>>103
ボタン型より抽象的な型（コンポーネントとかウィジェットとか）で
保持してやればいいんじゃね？名前はそのまんまで。

で、本当にボタンとして使うときには毎回キャスト。
一回やってみせて、できあがったアフォコード見せてやればきっと
納得してくれるよ。

105 ：デフォルトの名無しさん：2007/03/15(木) 11:02:06

アフォをもってアフォを制す・・・か

106 ：デフォルトの名無しさん：2007/03/16(金) 20:26:03

逆に次からもそうしろってなったら嫌だなｗ

107 ：デフォルトの名無しさん：2007/03/17(土) 23:30:31

C言語だと、

a += 2;
{
懿｡疂nt tmp = a;
懿｡畭 = b;
懿｡畸 = tmp;
}

みたいに{ }を使うこともあると思うけど、これに if else をつけると、

if (a > 0)
懿｡畭 += 2;
else
懿｡痣
懿｡癧疂nt tmp = a;
懿｡癧畭 = b;
懿｡癧畸 = tmp;
懿｡痾

のように、一行コードと{ }のブロックが同じインデントになってるから、
GNUのスタイルは一応理にかなってはいるなと思っただけ。

108 ：デフォルトの名無しさん：2007/03/17(土) 23:34:09

C言語だと、

a += 2;
{
□int tmp = a;
□a = b;
□b = tmp;
}

みたいに{ }を使うこともあると思うけど、これに if else をつけると、

if (a > 0)
□a += 2;
else
□{
□□int tmp = a;
□□a = b;
□□b = tmp;
□}

のように、一行コードと{ }のブロックが同じインデントになってるから、
GNUのスタイルは一応理にかなってはいるなと思っただけ。

#化けたのでもう一度書きます。すんません。。。

109 ：・∀・）っ-○◎●：2007/03/17(土) 23:45:16

& n b s p ;をスペース入れずに使いましょう

110 ：デフォルトの名無しさん：2007/03/18(日) 00:07:54

>>108
GNUの{}がキモイと言っている奴らは
そういう理屈を理解した上でなおキモイと言っているんだと思われ

111 ：デフォルトの名無しさん：2007/03/18(日) 00:20:47

何しろ「キモイ」なんだから理屈じゃないわな

112 ：デフォルトの名無しさん：2007/03/18(日) 00:24:12

>>110
オレは { } を使わない if がそもそもキモイと思う。( >>108 の a += 2; の部分 )

113 ：デフォルトの名無しさん：2007/03/18(日) 00:34:00

ttp://www.linux.or.jp/JF/JFdocs/kernel-docs-2.2/CodingStyle.html

＞まずは「GNU 標準プログラム書法」
＞(GNU coding standards)を入手して印刷してみてください。でも、読むために
＞印刷するのではありません。印刷した物を燃やすのです！この儀式は晴れがま
＞しい決意表明なのです！ V^_^V
By リーナスたん

114 ：デフォルトの名無しさん：2007/03/18(日) 01:23:23

まあ確かに理屈どうこうじゃねーな。
とにかく気持ち悪い。

115 ：108：2007/03/18(日) 02:14:49

>>112
見ていて一番自然なのは K&R のスタイルだとは思うけど、
それでも、{ } を使わない if は普通に出てくるよ。

116 ：デフォルトの名無しさん：2007/03/18(日) 09:17:27

>>115
自分では単文の時も必ず{}で括るようにしているが、
そうでないソースがあったとしてもキモいとまでは思わないな。

117 ：デフォルトの名無しさん：2007/03/18(日) 14:04:35

if (hoge)
　　a = 1;
else {
　　int b;
　　a = 1;
　　b = 2;
}

1行コードと {} のインデントを同じにしなきゃならん理由がわからん
ifとelseの中身が同じインデントレベルの方が見て把握しやすい

GNUはやっぱキモイわ

リーナスたんが言うようにGNUのウンココーディングスタイルなんて燃やすべきだ！

118 ：デフォルトの名無しさん：2007/03/18(日) 15:32:05

別にどっちでも大差ないでしょ

俺様wayに頑なに固執するのは俺的には精神分析の対象だと思う。
どっか幼児性が切断されてないところがあるんじゃないの？

気色悪い、という感情はコードのお作法に対してより、
むしろそういう自分自身をこそ向けられるべきだね。

119 ：デフォルトの名無しさん：2007/03/18(日) 15:36:57

とはいえ、人間はパターン認識の動物だから、
異なるパターンのコードを行ったり来たりするのは疲れることは確か。

だとしたらフリースタイルというcの思想がそもそも間違ってるのかもね。
まあ、自由というドグマに囚われた不自由なアメリカ人が作ったものだからな。

120 ：デフォルトの名無しさん：2007/03/18(日) 15:38:38

単文とか複文という概念が無いModula2最強ってことでｗ

121 ：デフォルトの名無しさん：2007/03/18(日) 15:59:53

GNUのスタイルがキモいと思ってる人間は少くないんだから
コミッターや開発者の間で民主的に多数決でもとって GNU v2 のスタイルでも
決めてくれればいいものを。

一部の変人がコーディングスタイルを決めて、それがデファクトスタンダードになって
しまってる現状に疑問を投げかけてもいいんじゃない？

>>118みたいに人格攻撃しかしないバカには理解できないだろうけど

122 ：デフォルトの名無しさん：2007/03/18(日) 16:32:19

GNUよりも>>118がキモイ

123 ：デフォルトの名無しさん：2007/03/18(日) 16:38:14

結論：>>118はキモイ

124 ：デフォルトの名無しさん：2007/03/18(日) 23:11:13

>>118の反響の大きさにﾜﾗﾀ

125 ：デフォルトの名無しさん：2007/03/18(日) 23:19:30

>>118のキモさに泣いた

126 ：デフォルトの名無しさん：2007/03/18(日) 23:54:09

>>118になにがしか反応せずにはいられないやつがこれだけいるとはw

127 ：デフォルトの名無しさん：2007/03/18(日) 23:58:36

>>118だと聞いて飛んできました。

128 ：デフォルトの名無しさん：2007/03/19(月) 00:03:09

幼児性って分断させるものなん？

129 ：デフォルトの名無しさん：2007/03/19(月) 11:06:30

この勢いだと>>118が切断されそうです＞＜

130 ：デフォルトの名無しさん：2007/03/19(月) 13:00:16

>>121
「デファクトスタンダード」の意味調べて来い。

131 ：デフォルトの名無しさん：2007/03/19(月) 15:56:43

>>130
>>121は、FLOSSなどと呼ばれるソフトウェアはLinuxカーネルを除いて
みなGNUスタイルで書かれてるとでも思っているのではないだろうか。

132 ：デフォルトの名無しさん：2007/03/19(月) 22:09:09

>128
俺は一瞬「幼児を分断」と読んで萎えた

133 ：デフォルトの名無しさん：2007/03/20(火) 01:27:02

そんなつまんないレスすると。負けずに

正しくは「幼児性の払拭」だね

なんつう、つまんないレスを(ry

134 ：デフォルトの名無しさん：2007/04/10(火) 13:58:05

C++使いです
関数名、変数名の大文字小文字でずっと悩んでいますが、
スタイルはJavaやMSDNでいいと思っています　
でも、STLやBoostを使うと、バランス悪くなりませんか？

135 ：デフォルトの名無しさん：2007/04/10(火) 14:49:21

それがC++標準のスタイル。気にしないのがベスト。
必要以上の一貫性は無意味だ。

136 ：デフォルトの名無しさん：2007/04/29(日) 03:20:35

>>101
それはいつも悩んでます。俺はVBでcmdOkとかcmdCancelみたいなのに
慣らされてきたから、C#になったときにbuttonOkとかbuttonCancelとか
やってみたんだけど、確かに探しやすいんだがなんか気持ち悪い。
次のプロジェクトではokButton、cancelButton式にしたんだけど、やっぱり
探しづらい。どうしても「UI要素の分類」をキーボードから打ったあとで
候補から↑↓で選ぶ方が探しやすいと思うのだ。
そうして小さなプロジェクトを作るごとにあーだこーだ悩んだ末、
今ではプロジェクトごとにばらばらだ。それが一番ダメなんだってｗ

137 ：デフォルトの名無しさん：2007/04/29(日) 07:21:40

プロジェクトごとにばらばらなのは許容範囲でしょ。
ダメなのはプロジェクト内で統一されてない時。

138 ：デフォルトの名無しさん：2007/05/01(火) 03:41:22

>136
_をofと考えて、button of ok → button_ok

139 ：デフォルトの名無しさん：2007/05/09(水) 03:02:45

/**
* ←このアスタリスクがめんどい
*/

140 ：デフォルトの名無しさん：2007/05/09(水) 03:13:07

C/C++/Java の複数行コメントのスタイルについて。
/*
* ←このアスタリスクがめんどい
*/
はじめに書くときにも面倒だし、後でコメント内のインデントを上げ下げ
するときにも激しくウザイ。そしてこの面倒さに対するメリットがよくわからない。

いっこだけ検索して見つけたのが、その行がコメントであることを行自身に
明示させる働きがあるとのこと。だけどそんなのエディタで開けば
色分けしてくれるし、そうじゃなくてもコメントとコードの区別は目で見れば
簡単に判別できる。機械的に判別させるためであれば、行頭アスタリスクで
始まるコードも書けてしまうので結局曖昧なままだし。

なんでこのスタイルがこんなに普及してるのか、知ってる人がいたら教えて欲しい。

141 ：デフォルトの名無しさん：2007/05/09(水) 03:15:14

見た目がどうこうとかもっともらしい理由が言われ続けているから、ではなかろうか。

142 ：デフォルトの名無しさん：2007/05/09(水) 03:16:50

モノクロの世界だと区別が分かりやすいってのはあるかもね。
いちいち打つのは面倒だからやりたくないね。
エディタが勝手に埋めてくれるから埋めとくかって感じだけど。

143 ：デフォルトの名無しさん：2007/05/09(水) 03:18:15

>>139
それがそんなにめんどいなら、そのアスタリスクを付加するフィルタを簡単に作れるようになるべきかと。
固定文字列対応のことを考えるとめんどいけど

144 ：デフォルトの名無しさん：2007/05/09(水) 03:20:35

>>142
そのエディタ、コメントの中のインデント調整してもアスタリスクの位置だけ
保持してくれたりする？

145 ：デフォルトの名無しさん：2007/05/09(水) 03:33:15

んなもん頭に*つけたり外したりするのなんざエディタの仕事だろうが。
プログラマなんだからそれくらいエディタにやらせろよ。

146 ：デフォルトの名無しさん：2007/05/09(水) 13:41:49

GNUは極度の後方互換とストールマソの趣味であんな規則になってるんでしょ
ところで単語の区切りはどうしてる？
do_somethingで単語を区切る方が好きだけどC++やJavaも使うから泣く泣くdoSomethingみたいに大文字で区切ってる

147 ：デフォルトの名無しさん：2007/05/09(水) 14:05:50

>>140
javadocのせいじゃないの？

148 ：デフォルトの名無しさん：2007/05/09(水) 18:05:54

MFC で C++ を覚えた俺から見ると DoSomething が一番自然に見えるｗ
C# と Java やり始めてようやく doSomething 式にしたけどまだ違和感があるな

149 ：デフォルトの名無しさん：2007/05/09(水) 19:42:35

俺てきとうだなぁそのへん。
とりあえず周りに合わせる感じ。
C++でソロだとdo_something系だな、今は。

150 ：デフォルトの名無しさん：2007/05/09(水) 21:31:46

>>148
C#はDoSomethingだろ
マイクロソフト様のガイドラインに書いてある。

151 ：デフォルトの名無しさん：2007/05/09(水) 21:34:24

do.somethingみたいな具合に
doやsomethingそのものも柔軟に定義できてそれらの直行性を使って
複合的な機能が実装できればいいのに

152 ：デフォルトの名無しさん：2007/05/09(水) 21:39:04

日本語おｋ

153 ：デフォルトの名無しさん：2007/05/09(水) 21:59:36

放っておけ奴は「直行性」と言いたいだけだ
直交性に読み替えてみてもさっぱり意味が(ry
・・・もしかしてニモニック？

154 ：デフォルトの名無しさん：2007/05/09(水) 22:07:17

>>150
マジすか
明日から堂々と DoSomething って書くわ、むろん Java でも

155 ：デフォルトの名無しさん：2007/05/09(水) 22:11:06

>>154
Javaでのメソッド名、変数名についてはdoSomethingでたのむにょろ。

156 ：デフォルトの名無しさん：2007/05/09(水) 22:34:40

変数名とメソッド名の見た目が同じなのが嫌という理由で
変数名は小文字アンダースコア区切り、メソッド名はCamelな俺。

157 ：デフォルトの名無しさん：2007/05/09(水) 22:36:15

名前の途中に大文字だけの単語が出てくると
命名しててなんか気持ち悪くなるんだよね。

158 ：デフォルトの名無しさん：2007/05/10(木) 00:26:29

>>146
変数名と関数名は全部小文字で単語間をアンダースコアで区切る。
クラス名はキャメルケースを使う。

という風に使い分けてる。

159 ：デフォルトの名無しさん：2007/05/10(木) 13:35:57

Javaをアンダーバーで切ると標準ライブラリで見づらくなるじゃない？

160 ：デフォルトの名無しさん：2007/05/10(木) 14:57:56

クラス名の先頭は大文字にしとけ

161 ：デフォルトの名無しさん：2007/05/11(金) 02:03:18

クラス・関数・変数・定数・etcの区別に拘っている方に聞きたい。
関数ポインタとかファンクタ、デリゲート、const変数等はどう名付けてます?

162 ：デフォルトの名無しさん：2007/05/11(金) 02:52:04

使用するライブラリに合わせるかなぁ。

>>161
デリゲートって悩むよねー
MS様のガイドラインではイベントハンドラ以外のは
～Callbackにしろって書いてあったと思うけど、
明らかに守られてないし。(MethodInvokerとか)

あんまし関係ないけどWin32APIの定数はできるだけ
constの変わりにenum使うようにしてる。

163 ：デフォルトの名無しさん：2007/05/14(月) 13:48:41

変数　＝＞　全部小文字／アンスコ
メソッド　＝＞　先頭小文字／キャメル
クラス　＝＞　先頭大文字／キャメル
定数　＝＞　全部大文字／アンスコ

かな。

164 ：デフォルトの名無しさん：2007/05/14(月) 21:40:44

>>154
publicな名前はDoSomethingで、
privateな名前はdoSomethingと覚えておけばいい

165 ：デフォルトの名無しさん：2007/05/14(月) 23:26:27

privateメソッドはどう名前をつけようが窯湾だろ。

166 ：デフォルトの名無しさん：2007/05/15(火) 02:20:54

c++だとバッティングするリスクがあるのでちょっとは気にした方がいい。

167 ：デフォルトの名無しさん：2007/05/15(火) 21:43:21

そのバッティングするリスクとやらをどうぞ

168 ：デフォルトの名無しさん：2007/05/16(水) 02:25:30

ttp://www.mozilla-japan.org/hacking/portable-cpp.html
> C++ 標準規格 17.4.3.1.2 節グローバル名 [lib.global.names] 第1パラグラフによると:
>
> 名前と関数シグネチャのある特定の組は、実装によって常に予約されています:
> 　二重のアンダースコア（__）が含まれる名前、または後ろに大文字 (2.11) が付くアンダースコアで始まる名前は、
> ある目的のために実装によって予約されています。
> 　アンダースコアで始まる名前は、グローバルな名前空間で使う名前として実装によって予約されています。

169 ：デフォルトの名無しさん：2007/05/16(水) 08:11:48

doxygen で @param に付く in, out って、つけたほうがいいんでしょうか？
ほとんど [in] だし、ポインタに const ついてなければ [out] または [in,out] なんで、
あんまり手動でつけて回るメリットが無いような気がしてます。

170 ：デフォルトの名無しさん：2007/05/16(水) 08:27:30

>>169
私のところでは、過去との互換性でconstついてないポインタの時にはつけてる。

171 ：デフォルトの名無しさん：2007/05/16(水) 09:11:58

クラスというか、抽象的に状態を保持してるオブジェクトを
渡すときは in も out も何かしっくりこないしねぇ。出したり入れたり
じゃなくて状態を変更するかどうかが重要って感じ？

172 ：デフォルトの名無しさん：2007/05/16(水) 12:50:24

通常それをピストンというのでは？

173 ：デフォルトの名無しさん：2007/05/16(水) 14:45:20

ほしゆ

174 ：デフォルトの名無しさん：2007/05/21(月) 04:21:30

ケースセンシティブをなくせばこんな宗教戦争は解決するんじゃない？

175 ：デフォルトの名無しさん：2007/05/21(月) 10:20:53

>>174
自動車をなくせば交通事故は無くなるんじゃない？

176 ：デフォルトの名無しさん：2007/05/21(月) 10:25:26

>>175
いいえ、自動車以外の交通事故は残ります。
→ケース問題を除く宗教戦争は残ります。

177 ：デフォルトの名無しさん：2007/05/21(月) 13:07:30

BASICって確か大文字小文字区別しないけど、
あの言語ってケース問題に関する宗教戦争ってないのか？

178 ：デフォルトの名無しさん：2007/05/21(月) 13:33:11

8bit時代のBASICならいざしらず、VisualBaiscとか今時のBASIC使ってるヤツで
「大文字小文字同一視だぜ」とか言ってるやつはみたことないな。
普通に大文字小文字区別して「どう書こう？」ってやってる。

179 ：デフォルトの名無しさん：2007/05/21(月) 13:51:21

Delphiが「大文字小文字同一視だぜ」なんだけど、
書籍やIT系サイトのチュートリアルっぽいコードで、たまに無茶苦茶なのを見かける。

一般向けに晒すコードなら、プロパティ名とかメソッド名はオンラインヘルプに記述されているとおりに書け。

# Delphiのヘルプは酷いから、そもそもオンラインヘルプで記述が統一されていないってのもあるが。

180 ：デフォルトの名無しさん：2007/05/21(月) 14:43:03

MSDN見習わせたらエラー処理はしないしファイル番号は固定だし……

ってのは兎も角。
>>178
VisualBasicは大文字小文字を区別できるんですか?
例えばdim aa as integer, AA as integer, Aa as integerみたいに?
私ゃ保存はされるけど区別はできないと思っていたのだが。

181 ：178：2007/05/21(月) 15:01:39

>>180
いや、区別しない。

>>178で言いたかったのは
「区別されないからAbcDefメソッドをABCDEFで呼ぶぜ」なんてやつはおらず、
VBでも「『AbcDef』がいいか『abcDef』がいいか(大文字小文字を意識して)どう書こう？」って
やってる、ってこと。

書き方悪かったかも。ごめん。

182 ：デフォルトの名無しさん：2007/05/22(火) 15:38:32

でも自動車を無くせば自動車事故は起きなくなるね
#こういう考え方はいかん
#エロサイトを封じれば性犯罪が減ると思ってやがる

183 ：デフォルトの名無しさん：2007/05/22(火) 19:08:06

>>182
コメントへの野暮なレスですまんが、
もとの「自動車を無くせば自動車事故は起きなくなる」に対応する
のは「エロサイトをなくせばエロサイトへの接続が無くなる」では。

# 縦読みを仕込みたかったが出来なかった。

184 ：デフォルトの名無しさん：2007/05/22(火) 20:21:39

エロサイトを封じたら、性犯罪は増えるんじゃないの？

185 ：デフォルトの名無しさん：2007/05/23(水) 00:14:54

>>183
エロサイトを封じればエロサイトの広告、迷惑メールなどが減る。
→でもその他の広告などは残る。

186 ：175：2007/05/23(水) 01:40:16

大文字小文字の区別をつけるか否かは、言語設計者が決めることだから、
その言語を使用する側が制御できることではないし、どうこう言うべきことでもない
と言いたかったのですが。

187 ：デフォルトの名無しさん：2007/05/23(水) 05:03:55

最近はCOMとか.NETとかスクリプティングとか言語設計者の都合だけでは
決められない要素も出てきた

188 ：デフォルトの名無しさん：2007/05/23(水) 06:51:31

COMは最近ではないと思うけど、まあそうだね。

189 ：デフォルトの名無しさん：2007/05/23(水) 13:52:32

機械語

190 ：デフォルトの名無しさん：2007/05/30(水) 08:01:29

そういえばスペースだけでコーディングする言語あったよね
あれなら宗教戦争はなくなる

191 ：デフォルトの名無しさん：2007/05/30(水) 08:23:20

ホワイトスペルマだっけ？

192 ：デフォルトの名無しさん：2007/06/02(土) 00:19:25

しばらく開発から離れた仕事をしていたうちにハンガリアンはあまり使われなくなったみたいですが、どういった理由でですか？
カーソルをあわせれば型が出るからですか？
自分はカーソルあわせるのが面倒なのでハンガリアンで書いてますが・・・

193 ：デフォルトの名無しさん：2007/06/02(土) 00:25:52

>>192
templateをゴリゴリつかったプログラミングなんかが流行ったこととかが関係してると思う。
ハンガリアンだと型を変えたときに名前まで変えなきゃならんしね。

↑これは型に対するハンガリアンのことであって、意味に対するハンガリアンは
いまでもそこそこ使われてると思うけど。

194 ：デフォルトの名無しさん：2007/06/02(土) 00:41:42

変数のスコープがやたらでかくなってないか、
関数でかすぎるせいでそうなってないか、
一回見直したほうが良い。

195 ：デフォルトの名無しさん：2007/06/03(日) 21:19:31

悪しきシステムハンガリアンが消えて
本来のアプリケーションハンガリアンを用いる人が増えただけ

196 ：デフォルトの名無しさん：2007/06/20(水) 05:09:57

ハンガリーってどこらへん?

197 ：デフォルトの名無しさん：2007/06/20(水) 11:45:17

X系はdoSomething、GNU系はdo_something
ディストリをメンテしているオレの戦いは今日もつづく

198 ：デフォルトの名無しさん：2007/06/20(水) 16:30:30

>>196
http://www.namamono.com/okotoba01.html (02年3月上旬)

199 ：デフォルトの名無しさん：2007/06/20(水) 16:37:28

無駄に探す労力を割かす上につまんねぇ…
なんという糞レス…

200 ：デフォルトの名無しさん：2007/06/21(木) 20:07:08

>>199
おーrrらー

201 ：デフォルトの名無しさん：2007/06/28(木) 01:08:52

今までこう書いてたけど

変数　＝＞　全部小文字／アンスコ
メソッド　＝＞　先頭大文字／キャメル
クラス　＝＞　先頭大文字／キャメル
定数　＝＞　全部大文字／アンスコ

>>163さんと同じにした方がみやすいんじゃん
っておもた
でも先頭が小文字のキャメルは不自然に感じてしまう

202 ：デフォルトの名無しさん：2007/06/28(木) 01:33:07

C#だけど結局

プライベートフィールド・ローカル変数　　：ローワーキャメル
名前空間・クラス・関数・プロパティ・定数：アッパーキャメル

に落ち着いた。
フィールドにアクセスするときは必ずthis付けるようにしてるから
ローカル変数と混同することはないはず。

今MSDNのガイドライン読んだらプライベートメンバの
名前付けに関してはなんでもいいみたいだな。

203 ：デフォルトの名無しさん：2007/06/28(木) 23:17:56

>>202
構造体・クラス・列挙体にはリーディングタグつけないやっぱり？
C#だとやってる人ほとんどいないなどういうわけか。

enumはともかく、クラスと構造体の違いは勘違いしてると致命的になる場合が
あるから、つけた方がぜったいコード読みやすいと俺は思うんだけど。

204 ：デフォルトの名無しさん：2007/06/29(金) 00:11:27

MS的にNGな気がする。

205 ：デフォルトの名無しさん：2007/06/29(金) 01:18:09

>>163氏の命名法で

変換テーブル的に使う変数(例えば数値→文字へに使うようなmap型の変数)や
関数オブジェクトのインスタンスなら関数と同じような命名法である
>先頭小文字／キャメル
を適用したいのです

こういう類の変数で初期化時に設定してあとは殆ど変更しなかったり、
初期化部分以外での扱い方が関数的(mapの例だとmap[x]でxに対応する値の取得に使われる)たりで
メソッドとみなしてメソッドに対する命名法を適用しても問題ない気がするんですがどうでしょう？

それでも変数である以上変数に対するルールを出来る限り使用するべきでしょうか？

206 ：デフォルトの名無しさん：2007/06/29(金) 10:02:57

>>203
C# は結局、VS のインテリセンスに頼ること前提だから、
クラスと構造体の勘違いは気にしなくてもいいのかも。

207 ：デフォルトの名無しさん：2007/06/29(金) 12:44:20

P/Invoke以外で構造体作ったこと無いなー。

208 ：デフォルトの名無しさん：2007/07/01(日) 18:08:36

>201
Javaだと先頭小文字のキャメルってよく使うよ。
何せ標準ライブラリがそうなってるからな。
M$は先頭大文字キャメルLoveみたいだが。

209 ：デフォルトの名無しさん：2007/07/01(日) 20:11:36

.NETは、
名前空間名、型名、パブリックメンバ名はPascalCase、
関数の引数名はcamelCase

210 ：デフォルトの名無しさん：2007/07/16(月) 02:29:48

正直Camelで区別するのって、ハンガリアンと同じモノを感じるのは漏れだけですか。

211 ：デフォルトの名無しさん：2007/07/16(月) 03:07:50

ハンガリアンはハンガリアンでもアプリケーションハンガリアンは全然おｋだよ
getXXXとかのgetのようなものも役目としてはこれに近いから同じように感じるのも無理はない

212 ：デフォルトの名無しさん：2007/08/16(木) 16:52:56

C#でLogというクラスを作ったわけですよ。で、ログの種別を
区別するための列挙型をLog.Typeと命名したんですね。
.NETのライブラリでもアッパーキャメル規約になってるっぽいですから。

で、メンバ変数としてType Log.typeを定義したのです。ここまでは
分かりますね。さらにLog.typeを外部から直にアクセスして欲しくないので
typeにアクセスするプロパティを定義すると。MS式の記法だと、やっぱり
Log.Typeが妥当かな？

　　型 'Log' は 'Type' の定義を既に含んでいます。

213 ：デフォルトの名無しさん：2007/08/17(金) 01:04:30

>>212
キャメル云々はそれでよいと思う。

名前が重複する件は、列挙型はTypeでよくて、プロパティの方は「○○のためのType」という
○○の部分をうまく補ってあげればいいんじゃないかな。

214 ：212：2007/08/17(金) 03:18:25

「○○のためのType」がこの場合、本当に「ログのためのType」としか
表現のしようがないのが辛いです。
列挙型はLog.Typeで、プロパティはLog.LogType…うーむ。

余談ですが、列挙型の識別子を“TYPE”と全部大文字表記
（長い場合はアンダースコア区切り）にすることも考えました。
しかしその方法でも内部クラスとかの命名になるとお手上げ…。

215 ：デフォルトの名無しさん：2007/08/18(土) 00:09:00

TypeIdとかTypeNoとか。

216 ：デフォルトの名無しさん：2007/08/24(金) 04:14:41

C++だけど、こんな感じで関数名と変数名がバッティングするときどうします？

class Ore {
public:
　　bool isNeet() const { return isNeet; }
　　// if (ore.isNeet()) { ... } とか呼びたい

private:
　　bool isNeet;
};

1. こういうの嫌だから関数を大文字で始めてるYO（isNeet()をIsNeet()に）
2. こういうの嫌だから変数にプリフィックスなどをつけてるYO（isNeetをm_isNeetやisNeet_に）
3. 変数名を変えちゃうYO（isNeetをneetとか……形容詞ならともかく名詞だと変な気が。
　なんかもっといいネーミングとかありますかね）

なんかJavaだと↓で普通に通っちゃうんだけど。理屈はわかりませんが。

class Ore {
　　public boolean isNeet() { return isNeet; }
　　private boolean isNeet;
}

関数名が小文字で始まるほうがコードが柔和な気がするのでC++でもそうしたいんですが、
（メイヤーズ先生も小文字で始めてるし）
どうもここがちょっと引っかかって。

217 ：デフォルトの名無しさん：2007/08/24(金) 04:29:23

>>216
isNeet = false とかがキモイのもあって、 neetFlag とかにしちゃうかな。
m_neet もアリだな。

218 ：デフォルトの名無しさん：2007/08/24(金) 10:53:28

>>216
メソッド名を大事にしたいならフィールド名にちょっと引込んでもらうしかないのでは。
自分ならサフィックスにアンダーバーつける。

>>217
「isNeetを内部で保持するのはneetFlag」みたいなのって、頭使うの面倒じゃない？
まれにはそういう置きかえがピッタリいくこともあるけど、ほとんどの場合は
機械的に「プレフィックスつけてるっすー」とかの方が、余計なことに気を回す必要がなくて楽だと思う。

219 ：デフォルトの名無しさん：2007/08/25(土) 00:44:34

_*
m_*
がいいよ。

メンバ変数を他の変数と区別できるようにするのは、
CodeCompleteでも薦められてるようなよくやるパターンです

220 ：デフォルトの名無しさん：2007/08/25(土) 01:21:18

メンバ変数はname_にしてる。

221 ：デフォルトの名無しさん：2007/08/25(土) 01:27:52

>219
_FollowedByUppercaseLetterはコンパイラ＆ライブラリ実装者用の予約語なので、
_nameも避けといた方が無難。
＃double__underscoreもね

222 ：デフォルトの名無しさん：2007/08/25(土) 01:32:37

前にアンダーバー置くのはイクナイね。

223 ：デフォルトの名無しさん：2007/08/25(土) 01:35:48

某所で、初心者にえらそうに教えてるやつが、Cなのに構造体のメンバにm_をつけてた。
意味をわかってつけてるのか。

224 ：デフォルトの名無しさん：2007/08/25(土) 03:11:13

>>219
_name をつけるほど自信家じゃない
grepしたときやたらと似たようなのが引っかかりそうだし
それにエディタの行位置表示を下線にしてあるから、見えなくなる

225 ：デフォルトの名無しさん：2007/08/25(土) 03:16:23

＞それにエディタの行位置表示を下線にしてあるから、見えなくなる
これが理由なら、阿呆だ。

226 ：デフォルトの名無しさん：2007/08/25(土) 06:17:51

>>223
member の m なら C の構造体でも間違いではないだろ。

227 ：デフォルトの名無しさん：2007/08/25(土) 09:51:01

>>221
たぶんそれ、グローバルな名前がそうなだけ

228 ：デフォルトの名無しさん：2007/08/25(土) 09:53:05

予約識別子だから、マクロ名を含めて、ソースコード中に出現してはならんよ。

229 ：227：2007/08/25(土) 11:29:28

すまん>>221は、_の後に大文字が来るのが最もマズいって言ってんのか

230 ：デフォルトの名無しさん：2007/08/25(土) 13:13:08

外からしか扱わないメンバに m_ とかつける必要は無いだろ。

struct Point { int m_x; int m_y };
Point p0 = { 0, 0 };
Point p1;
p1.m_x = p0.m_x + 1;

とか無意味。
scope の間違えようがない。

231 ：デフォルトの名無しさん：2007/08/25(土) 22:37:30

class Hoge {
private:
struct {
int x;
int y;
} m;
}

232 ：227：2007/08/26(日) 00:16:02

>>231
やめなさいｗ

233 ：デフォルトの名無しさん：2007/08/26(日) 01:06:27

>>231
とてもアリな気が今した!

234 ：デフォルトの名無しさん：2007/08/26(日) 20:47:53

>231
コレ継承先から継承元の変数見るのが面倒では…
あー、もしや変数は全部privateにしろって事?

235 ：デフォルトの名無しさん：2007/08/26(日) 21:13:48

>>234
＞あー、もしや変数は全部privateにしろって事?
当たり前じゃん。

236 ：デフォルトの名無しさん：2007/08/27(月) 00:31:17

>>234
structなしでint m_x;とか書いたのに比べて、なにか不便になることってあるの?

237 ：デフォルトの名無しさん：2007/08/27(月) 00:41:08

2～3行増える。
素直にint x_, y_;にしとけばタイプ量も減る。

238 ：デフォルトの名無しさん：2007/08/27(月) 01:24:03

231のmをポインタにした感じのコードなら書いたことある。
例外にも強いしコピー・交換も楽で速いしなんて思っていたら、
どうみても劣化pimplです、本当にありがとうございましたというオチ。

239 ：デフォルトの名無しさん：2007/08/31(金) 23:34:42

>>237
タイプ量だけ?
>>234 の継承とかなんとかは関係ないの?

240 ：デフォルトの名無しさん：2007/09/01(土) 22:41:02

>>237
メンバ数が多いと、逆にタイプ数は減らないか？ｗ

241 ：デフォルトの名無しさん：2007/09/04(火) 00:15:46

アフォな質問ですまん。
>231の例でx,yの初期化ってどうやって書けば良い?

242 ：デフォルトの名無しさん：2007/09/04(火) 00:38:14

>>241
普通にコンストラクタの初期化部で書けばよろしいかと。

243 ：241：2007/09/05(水) 00:12:31

>242
サンプルコードを書いて貰えませんか?
少なくとも漏れの知ってる書き方をみる限りでは、
>231の方法はやっぱダメだとしか思えませぬ。

244 ：デフォルトの名無しさん：2007/09/05(水) 00:47:14

structが無名だから初期化できないね。ま、コンストラクタで代入するってことで。
--
class Hoge {
struct {
int x;
int y;
} m;
public:
Hoge() {m.x = 0; m.y = 0;}
Hoge(int x, int y) {m.x = x; m.y = y;}
};

245 ：デフォルトの名無しさん：2007/09/06(木) 00:18:43

x,yがconstか参照で、かつコンストラクタの引数経由で
外部から初期値渡したい場合は?
それ考えると>231はやっぱ使い物にならん。

246 ：デフォルトの名無しさん：2007/09/06(木) 00:54:42

struct に名前を付けてコンストラクタ書けばいいだけの話じゃないの？

247 ：デフォルトの名無しさん：2007/09/06(木) 01:14:03

最早>231はどうでもいいがw
＞x,yがconstか参照で、かつコンストラクタの引数経由で
＞外部から初期値渡したい場合は?
条件後出ししていいなら、構造体に名前つけさせてくれ。

248 ：デフォルトの名無しさん：2007/09/06(木) 20:24:05

>246,247
structに名前付けるのはいいけど、
通常1回書けばすむはずの処理を、2回書かなきゃダメだよね?
そうじゃないスマートな書き方を知っているなら是非ご教授を。

249 ：デフォルトの名無しさん：2007/09/07(金) 13:03:53

>>248
2回って、何で？ Hoge は InnerHoge に丸投げするだけでしょ。

250 ：デフォルトの名無しさん：2007/09/08(土) 00:21:38

>>249
Hogeのコンストラクタとその内部構造体のコンストラクタで
2回初期化を書かなければいけない（そしてそれがスマートでない）
と248は言っているのだろう。

251 ：デフォルトの名無しさん：2007/09/18(火) 16:57:12

あーの、Windowsでアンダースコア区切りの命名規則を採用している方に質問なのですが、
皆さんはWinMainの引数とかAPIのコールバック関数にもアンダースコア区切りで命名しますか？
それともWinAPIに関連する変数は例外的にハンガリアン+CamelCaseで命名しますか？

当方、先週Windows畑に飛ばされたばかりのへっぽこPGなんですが、
どうにも気になって気になって。。。

252 ：デフォルトの名無しさん：2007/09/20(木) 02:06:24

Gtk+なんかだとAPIそのもの以外は徹底的にアンダースコア区切りで命名してるな

253 ：1/2：2007/10/05(金) 00:49:37

なんか、コーディング規約で this を返すのは駄目っていうのをどっかで読んだんだけど
こういうのはどうなの？
(サンプルソースの意図は、oldTest() の if 文を無くして test() のようにシンプルにすること)

public class Test {
    private static void oldTest(String[] params){
        for (int i = 0; i < params.length; i ++) {
            if (0 < i) {
                System.out.print("," + params[i]);
            }
            else {
                System.out.print(params[i]);
            }
        }
    }
    private static void test(String[] params){
        Printer printer = FirstPrinter.instance;
        for (String param : params) {
            printer.print(param);
            printer = printer.nextPrinter();
        }
    }
    public static void main(String[] argv){
        test(argv);
    }
}

254 ：2/2：2007/10/05(金) 00:50:41

abstract class Printer {
    abstract void print(String param);
    abstract Printer nextPrinter();
}
class FirstPrinter extends Printer {
    static final FirstPrinter instance = new FirstPrinter();
    void print(String param){
        System.out.print(param);
    }
    Printer nextPrinter(){
        return SecondPrinter.instance;
    }
}
class SecondPrinter extends Printer {
    static final SecondPrinter instance = new SecondPrinter();
    void print(String param){
        System.out.print("," + param);
    }
    Printer nextPrinter(){
        return this;
    }
}

255 ：デフォルトの名無しさん：2007/10/05(金) 00:58:07

>>253
コード読んでないけど、駄目って言う理由がないんならどうでもいいんじゃね？

256 ：デフォルトの名無しさん：2007/10/05(金) 01:31:13

メソッドチェーンするのに便利だしthisを返しておいた方がいいと思ったんだけど、
駄目って言う理由はなんなんだろう。

257 ：デフォルトの名無しさん：2007/10/05(金) 01:58:23

>>256
ちょっとよくわからないで言うけど
this を返してもらった奴がこれを使うときにthisの実体がなくなっちゃてたりするケースってない？

258 ：デフォルトの名無しさん：2007/10/05(金) 03:18:25

>>257
だって呼び出している側がインスタンス保持しているのに、
なくなっているってことが通常ある?

259 ：デフォルトの名無しさん：2007/10/05(金) 03:53:45

>>257
コード見る限り Java だから、それはありえない。

260 ：デフォルトの名無しさん：2007/10/05(金) 05:18:48

入出力関係のオブジェクトだと閉じてる可能性はあるね。

261 ：デフォルトの名無しさん：2007/10/05(金) 15:25:15

まじわからないで言う、ごめん

インスタンスを持っているならthisを返す意味はある？
汎化という目的で独立性を高めるために他の処理でこれを使うことを考慮したら
インスタンスが失われることを考えてthisを返してはいけないとか

262 ：デフォルトの名無しさん：2007/10/05(金) 15:26:27

if を使ってる処理のほうが、「何をしているか」がよくわかる

263 ：デフォルトの名無しさん：2007/10/05(金) 19:00:26

>>261
instance.foo().bar().baz()
とかやりたいってことない? これを指してメソッドチェーンといったんだけど。

264 ：デフォルトの名無しさん：2007/10/05(金) 20:10:40

operator overloading なんかだと this を返さないと成り立たないけどねw
まあ、java にはないから関係ないけど

265 ：デフォルトの名無しさん：2007/10/09(火) 15:59:59

副作用がある場合はthisを返さないってポリシーはあるな。

266 ：デフォルトの名無しさん：2007/10/09(火) 20:15:56

>>253
シンプルどころか複雑怪奇になってる。
さらにメモリ使用量も増えてるし、速度も遅くなっていそう。
そして、return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。

267 ：デフォルトの名無しさん：2007/10/09(火) 20:35:42

個人的に思ったのは、
「this を返すAPI を作るな」っていうコーディング規約は、
「メソッドチェーンを前提にした API を作るな」っていうのが本来の意図であって、
そうでなければオーケーなんじゃないかと。

>>266
今回はサンプルがはじめからシンプルだったために、結果的に複雑怪奇になってしまったわけで、
実際にはトレードオフで適用すればいいのだと思います。

＞最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。
親クラスで定義しているのは抽象メソッドだけで (つまり実質的にインタフェースといえる)、
クラス変数は存在しないはずなのですが・・・

＞return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
あー。確かに。言われてみれば。

ただ、今回は Printer をシングルトンで実装できたけど、
例えば任意のセパレータの文字を指定して CSV ファイルを構築できるように
Printer を改造したような場合は、各インスタンスが状態を持つようになるので
this を返すような実装になると思う。

まあ、この場合でも Printer をイミュータブルになるように設計して
Flyweight の getter メソッドを活用して this を返さないような仕組みにすることは出来るけど
そこまでやると冗長になる気がする。

268 ：デフォルトの名無しさん：2007/10/23(火) 19:22:00

保守代わりに転載。
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/172

269 ：デフォルトの名無しさん：2007/12/15(土) 02:35:34

　private:
　　bool isHoge_;

だけでなく、

　private:
　　void doHoge_();

とか、

　template<class Hoge_>

のように準ローカルな名前全てにアンダーバーを付けたくてウズウズしてしまうのですが、
そのようなコーディング規約が見付かりません。
常識的にあまり推奨されないのでしょうか？

270 ：デフォルトの名無しさん：2007/12/15(土) 02:39:55

>>269
どうして？

271 ：デフォルトの名無しさん：2007/12/15(土) 03:03:06

>>270
発端は、templateのタイプ名が外部の通常のクラス名と衝突してしまったため、
冗長にせざるを得ない場面があったからです。
ならばメンバ変数に習い、「末尾にアンダーバー」イコール「スコープ限定」にしてしまえば、
衝突も避けられるし、読む時にも迷子になり難いのではないかな・・・と。

272 ：デフォルトの名無しさん：2007/12/15(土) 03:44:57

>>271
そんな局所的な理由で規約になるわけないんじゃないの？

273 ：デフォルトの名無しさん：2007/12/15(土) 04:41:14

後ろにアンダーバーなんて始めて見たな。
前ならそうしてる人結構いるよ。

274 ：デフォルトの名無しさん：2007/12/15(土) 04:59:49

前につけるとすぐ予約名になるまたは予約名とまぎらわしいから、やめといたほうがいい。

275 ：デフォルトの名無しさん：2007/12/15(土) 07:12:05

>>271
つまりボキャブラリが貧弱なのを _ でごまかそうということですね
英語の辞書を買ったらどうでしょう

冗長といっても、いくら長くてもいいと思う
あとで別の人間が解析するときに、
grepをかけたら似た様なのがゾロゾロって
猛烈に格好悪い

276 ：227：2007/12/15(土) 07:45:38

>>274
これっていつから言われてるの？
昔は＿前だったのに・・・

>>271
それってローカル側優先で処理されるよね?
TXxxx
とかにするってのもどうかね

277 ：デフォルトの名無しさん：2007/12/15(土) 09:53:59

>>276
> これっていつから言われてるの？

「言われてる」ってのが何のことかわからないけど、予約名の規定自体は
知ってる範囲では ISO C++98, C99 とかで決められてる。たぶんそれより前の
C89 からそんなに変わってないと思うから、少なくとも 10 年以上前から使っちゃ
マズイってことにはなってたはず。

278 ：デフォルトの名無しさん：2007/12/15(土) 10:26:40

>>276
MS-DOS の初期のころから内部の実装で使われていた気がする

279 ：デフォルトの名無しさん：2007/12/15(土) 11:02:48

>>273
オレは何度も見たことあるよ。

280 ：デフォルトの名無しさん：2007/12/15(土) 12:33:25

>>279
確かに、C の関数の場合は後ろに _ をつけると()と離れて絵的に悪くないかも知れないけど

いまひとつ _ を前後に使う意味がわからないな
_ があることでなにかを示すようには見えないな
もっと、適切な方法があるならそれを選んだほうがいいように思う
見てわかるような名称にするように文になっていたっていいと思う

昔の関数名なんか変なのあるよな
creat() なんて何を考えてるんだかｗ
'e' 一文字を省く理由がわからない

281 ：227：2007/12/15(土) 12:39:05

>>277-278
ごめ。
_ は前に普通に付ける時代があったんだけど（本とかで載っていた）
最近後ろに付ける勢力が急拡大している感じ。
いつからだろうと。

282 ：デフォルトの名無しさん：2007/12/15(土) 12:49:04

>>281
前につけることの問題を知らずに本を書いちゃうようなアホが淘汰されたんだろう。
いつからってこともないと思うぜ。

283 ：デフォルトの名無しさん：2007/12/15(土) 12:57:38

>271
利点、欠点を考えて判断すりゃいいんじゃない？

利点：ローカルスコープの関数・変数が一目でわかる
欠点：メンバー変数とメンバー関数のバッティングが発生する可能性がある（C++の場合）
　　　-->別の命名規則で回避する必要あり
ぐらいかね？

ローカルスコープなんだし好きにすれば？という気もするけど。

284 ：デフォルトの名無しさん：2007/12/15(土) 13:28:58

>>282
_ 前に付けて問題になったことなど一度たりともないけどな。
メンバ変数なんてローカルだし。
__descspecとかのキーワードなんて __ だしな

285 ：デフォルトの名無しさん：2007/12/15(土) 13:56:19

>>280
creat()については名付け親がそうつけてしまったことを深く恥じているのだから、
もうそっとしておいてあげたらどうだw

286 ：デフォルトの名無しさん：2007/12/15(土) 15:40:04

釣りか本気か微妙な流れだw

287 ：デフォルトの名無しさん：2007/12/15(土) 23:55:12

>>284
__declspecはむしろ正しい使い方。
処理系予約の識別子なのだから。

288 ：デフォルトの名無しさん：2007/12/16(日) 00:04:35

>>287
？
いや、その通りだけど、>>284の趣旨は、「そういうのは"__"だから、"_"を前につけても問題が起こったことはない」でしょ。

289 ：デフォルトの名無しさん：2007/12/16(日) 01:34:46

ﾅｲｼﾌｫﾛｰ

290 ：デフォルトの名無しさん：2007/12/16(日) 01:42:20

>>280
歴史的なもの
識別子に5文字しか使えなかったシステムで付けられた名前を引きずってるだけ

291 ：デフォルトの名無しさん：2007/12/16(日) 02:50:52

>>284
一度もないのは分かるけど、
規格で「予約」と明記されているものをあえて使う理由が分からん。
ローカル名については「マナー」程度なのかな？
他の言語だと「予約」だったりするんだろうか。

292 ：デフォルトの名無しさん：2007/12/16(日) 07:00:04

2重の__ は予約かも知れないが、
グローバルの_ はstdio.hとかのライブラリと被るので
~~~~~~~~~~~~~~~
注意ってことじゃなかったかって気がするんだが。
手元に資料がないから確認は取ってないが

293 ：デフォルトの名無しさん：2007/12/16(日) 07:04:09

あ、一つ思い出した。
そういやBUFSIZ ってシンボル使えないよなｗ

294 ：デフォルトの名無しさん：2007/12/16(日) 11:04:04

>>292
どっちも「予約」だよ。識別子の利用範囲が違うだけ。区別するのがメンドイから
自分とこで作るルールに書くときは一括でダメってことにするのが簡単。

295 ：デフォルトの名無しさん：2007/12/16(日) 11:26:03

ttp://www.alles.or.jp/~torutk/oojava/codingStandard/writingrobustjavacode_pid86_c3.html#doc1_662
ちょっと見つけた

296 ：デフォルトの名無しさん：2007/12/16(日) 13:52:19

>>295
うーーー。意味わかんない；
ごめんオレ馬鹿すぎ。エロイ人教えて。

297 ：296：2007/12/16(日) 13:58:19

あ、泣くほど読んだらわかった；

298 ：デフォルトの名無しさん：2007/12/16(日) 13:59:11

>>296
>281-282 にある

> _ は前に普通に付ける時代があった
> 前につけることの問題を知らずに本を書いちゃうようなアホ

の例じゃね？

299 ：デフォルトの名無しさん：2007/12/16(日) 15:05:06

まぁ明日ARMでも読んでみるわ。
メンバ変数名は、
グローバルなネームスペースを汚してるわけじゃないしね

300 ：デフォルトの名無しさん：2007/12/17(月) 02:42:38

っ >168

301 ：デフォルトの名無しさん：2007/12/17(月) 02:50:17

なぜ予約語とぶつかる可能性のあることをしようとするのか
いまひとつわからない
たしかに、かっこいいかもしれないけど
_や__が予約語に多いのだから、他人が見たら、
これらは予約語としてみられる可能性があるということでしょ？

できるだけ、必然的であるべきだと思うのだけど
でないと後で見てわからない気がするんだけどな
名称を考えるのがめんどくさいだけに思えるのは、オレが世間知らずだから？

302 ：デフォルトの名無しさん：2007/12/17(月) 02:54:48

C/C++ の入門書や入門サイトがそういうインクルードガードを書いてたり。
そういうのを見て覚えた奴が自己弁護のために抵抗してるだけ。目的なんか無い。

303 ：デフォルトの名無しさん：2007/12/17(月) 08:01:37

_で始まる予約語に何があるか言ってみろよ

304 ：デフォルトの名無しさん：2007/12/17(月) 08:05:56

>>300
やっぱ答え出てるじゃないか。
メンバ変数はグローバルじゃねえ。

関数名とグローバル変数に問題があるだけだろうな

305 ：デフォルトの名無しさん：2007/12/17(月) 11:48:40

>>301,303 予約語じゃなくて、予約識別子ね。

306 ：デフォルトの名無しさん：2007/12/17(月) 15:58:27

>>303
_STDLIB_H_

307 ：デフォルトの名無しさん：2007/12/18(火) 00:11:07

>>305
それならわかるわ

検索してみたら、いいページ掛かったわ

308 ：デフォルトの名無しさん：2007/12/18(火) 06:32:30

結局 _ をつけたがるのは
自分の作ったのを予約語扱いしてもらいたい　「格好つけしー」　か
考えるのが面倒で、 _ でもつけとけの　「横着者」　のどっちか
でいいの？

309 ：デフォルトの名無しさん：2007/12/18(火) 08:17:39

>>308
_ のあとの小文字は問題ねーってよ

310 ：デフォルトの名無しさん：2007/12/18(火) 08:33:41

>>309
昔のDOS系、MSのLIBなんかは _ の関数だらけ
これを予約語といえるかわからんが
それと同列のものにしたいということだろ？

311 ：デフォルトの名無しさん：2007/12/18(火) 11:31:02

>>309
何が問題ねーの？予約識別子じゃないの？

312 ：デフォルトの名無しさん：2007/12/18(火) 11:46:38

_ のあと小文字は、グローバルスコープ（ファイルスコープ）のみで予約。以下 >294

313 ：デフォルトの名無しさん：2007/12/18(火) 12:17:43

>>168の短い文章を理解するのに一体何レス費やせば気が済むんだ？

314 ：デフォルトの名無しさん：2007/12/18(火) 12:21:59

「ある目的のために」とか、わかりにくい誤訳が入ってたからじゃね？

315 ：デフォルトの名無しさん：2007/12/18(火) 22:50:44

グローバルな名前空間でとわざわざ限定してくれてるからじゃん

316 ：デフォルトの名無しさん：2007/12/19(水) 05:46:36

「感染してますが、コンドームをつけてれば大丈夫です」と言われてもやる気はしないのと同じ

例えが、ちがうか；

317 ：デフォルトの名無しさん：2007/12/23(日) 23:54:01

　　　　　　　　　　　　　 ( ﾟдﾟ )
　　　　　　　　　　　　　 ¶ノ ¶ノ |
　　　　　　　　　　／￣￣￣￣￣＼
　　　　　　　　 ./　　（,）　　（,）　ヽ
　　　　　　　　　|　　　　　|￣|　　　　 |
　　　　　　　　　ヽ　　　　￣￣　　　 /
　　　　　　　　　　|　 |　　　|　 |　　　|
　　　　　　　　　.ノ　.ﾉヽノ　.ﾉ　　　.|
　　　　　　　　 (＿ノ　　(＿ノ　　　　.|
　　　　　　　　　　　／／￣／／
　　　　　　　　　　　<　<　　 .<　<
　　　　　　　　　　　　ヽヽ　　ヽヽ

318 ：デフォルトの名無しさん：2007/12/25(火) 07:53:47

あ、そうそうそうすると

#ifndef _FILENAME_H
#define _FILENAME_H

はどんなシンボル名にしてんの？

#define H_FILENAME_H

とか？( ﾟдﾟ)

319 ：デフォルトの名無しさん：2007/12/25(火) 10:30:28

FILENAME_HでもMACRO_OF_FILENAME_Hでもお好きなものをどうぞ。

320 ：デフォルトの名無しさん：2007/12/26(水) 04:02:28

MACRO_OF_*は却下

321 ：デフォルトの名無しさん：2007/12/26(水) 04:09:12

#pragma onceでいいよもう

322 ：デフォルトの名無しさん：2007/12/26(水) 04:10:30

せっかくポータブルな方法があるのに、
そうじゃない手段をわざわざ使うのは気が引けるよ

323 ：デフォルトの名無しさん：2007/12/29(土) 11:30:30

規律正しいおまいらなら
#ifndef
の使用はもうやめたんだろ？

324 ：デフォルトの名無しさん：2007/12/29(土) 13:41:22

両方使うのは意味があるのかな？

325 ：デフォルトの名無しさん：2007/12/30(日) 00:07:39

>>323
なんで　ifndef　はいけないと思うの？

326 ：デフォルトの名無しさん：2008/02/19(火) 01:14:20

皆さんのスタイルを、GNU indentの引数で表現するってのはどうでしょか。
俺は単純に
indent -kr hoge.c
です。

327 ：デフォルトの名無しさん：2008/02/19(火) 14:45:58

>>325
名前がぶつかるかも知れない恐怖が

328 ：デフォルトの名無しさん：2008/03/16(日) 18:09:35

ソースのフルパスをマクロ名に入れとけば無問題ｗ

329 ：デフォルトの名無しさん：2008/04/13(日) 15:16:47

そんなにぶつかるのが怖いなら、GUIDでいいんじゃないか？インクルードガードなんか入力することなんかないんだからさ。

330 ：デフォルトの名無しさん：2008/07/28(月) 01:19:20

http://lolo.jp/orecode/

331 ：デフォルトの名無しさん：2008/07/30(水) 22:41:39

はてなで話題になってたが
tp://d.hatena.ne.jp/akkt/20080424/1209051266
これを厳密に守るのはきついな……

332 ：デフォルトの名無しさん：2008/08/07(木) 15:47:21

これはJAVAを念頭に置いてるのか？

333 ：デフォルトの名無しさん：2008/08/09(土) 21:26:02

>>331
goto有害論並に偏りすぎてねぇか？

334 ：デフォルトの名無しさん：2008/08/09(土) 22:46:42

手続き型脳を矯正するには多少極端なくらいのショック療法が必要ってことだろ

335 ：デフォルトの名無しさん：2008/08/25(月) 00:22:16

OO厨だった学生時代はそういう病的に分割されたコードばっか書いてたな。
だけど、働き始めて周りの人間にソース追いにくいだのなんだの
不評だったせいでいつのまにか書かなくなったが。

336 ：デフォルトの名無しさん：2008/10/01(水) 21:55:22

C++でオペレータの宣言・定義するときにoperator=とかくのかoperator =とかくのかそういうのって決まってるの？

337 ：デフォルトの名無しさん：2008/10/01(水) 21:56:36

それは多分、インデントの量とか中括弧の位置なんかと同じテーマだと思うんだが。

338 ：デフォルトの名無しさん：2008/10/01(水) 23:43:18

>>336
検索しやすいように空けない。

339 ：デフォルトの名無しさん：2008/10/02(木) 00:07:24

operator\w= で検索すればおｋ

340 ：デフォルトの名無しさん：2008/10/02(木) 00:08:04

↑*追加しといて

341 ：デフォルトの名無しさん：2008/10/02(木) 20:45:35

\w じゃダメだろ。

342 ：デフォルトの名無しさん：2008/10/03(金) 01:01:52

じゃあ
operator\wktk=

343 ：デフォルトの名無しさん：2008/10/09(木) 08:01:21

elevaterⅡ
escalator⊿

344 ：デフォルトの名無しさん：2009/01/09(金) 01:29:10

あと、a,b,cで書いたなら、最後までa,b,cで通して欲しい。
a, b, cとか行に寄って記述が違うとイラッと来る。

345 ：デフォルトの名無しさん：2009/01/10(土) 21:16:17

>>344
コピペ製作だと思うよ。

346 ：デフォルトの名無しさん：2009/02/08(日) 11:22:25

C言語で複合代入演算子やインクリメント/デクリメント演算子の使用禁止って一般的なの？

for( iI = 0 ; iI < iMax ; iI = iI + 1){

とか泣けるんですが。iIって変数名も泣けるけど。

347 ：デフォルトの名無しさん：2009/02/08(日) 16:00:56

母国語が違うプログラマだろ

348 ：デフォルトの名無しさん：2009/02/08(日) 20:56:10

いや、コーディング規約なんだってば。ふつーそうなんだと言われた。

349 ：デフォルトの名無しさん：2009/02/08(日) 21:59:11

規約作った人の母国語が疑われる

350 ：デフォルトの名無しさん：2009/02/09(月) 00:02:37

VB使いしかいなかったんだろｗ

351 ：デフォルトの名無しさん：2009/02/09(月) 02:15:38

>>346
痛々しいな。
１を加算するのに++を使うのもみっともないが
１づつ増えていく値を表現するのに++を使わないのも、なんだかな

352 ：デフォルトの名無しさん：2009/02/09(月) 10:51:44

break continue 禁止　理由:分かりにくいから。
で、代替のサンプルがすごく分かりにくい。

353 ：デフォルトの名無しさん：2009/02/09(月) 15:12:23

重要なのは「読みやすく、書きやすい」なので、規則は場合に応じてでいいと思ってる。
ぱっと見で理解できやすいほうに改良していく感じで。
基本は固まりがわかりやすいインデント、改行＋固まりの概要コメントってとこかな。

class A {
public:
　　int i;

354 ：デフォルトの名無しさん：2009/02/09(月) 15:13:48

途中で書いてもうた(^^;

class A {
public:
　　int i;
}
よりも
class A {
　　public:
　　　　int i;
}
のが好き

355 ：デフォルトの名無しさん：2009/02/09(月) 20:43:15

インデントや変数名なんかは後でどうにでもなるんで、別に構わない。

356 ：デフォルトの名無しさん：2009/02/10(火) 12:27:33

class A
{
private:
　int i;
};
がすき

>>355
変数名はクラス間で衝突するのが当然だから後から置換するのは大変だぞ

357 ：デフォルトの名無しさん：2009/02/10(火) 19:13:10

コンパイラ相当の解析能力がある名称変更ツールってあったらいいなあと、たまに思う

358 ：デフォルトの名無しさん：2009/02/10(火) 20:36:18

>>357
JavaとかC#だと当たり前のように存在する。

359 ：デフォルトの名無しさん：2009/02/10(火) 20:39:51

>>357
何年前から来ましたか

360 ：デフォルトの名無しさん：2009/02/10(火) 21:25:10

Eclipseの入力補完とリファクタリングがなければ、もうコーディングできない体に・・・。
viでperlでCGIを書いていた時代には戻れない。

361 ：デフォルトの名無しさん：2009/02/10(火) 21:51:51

７０年代から来たものですが、技術の進歩はすばらしいなｗ
eclipseを使って変数名変更やもっと高度なコードの書き直しができるみたいね
ttp://www.confrage.com/eclipse/
（リファクタリングの項目）

こういう情報がまとまってるところってないものかな

362 ：デフォルトの名無しさん：2009/02/10(火) 22:25:03

VS2008でもリファクタリング出来ますよ

363 ：デフォルトの名無しさん：2009/02/10(火) 22:54:59

イマドキのモダンな開発環境なら大概できると思うが。
C++は構文解析の難易度高いんで発狂IDEも多いけどｗ

364 ：デフォルトの名無しさん：2009/02/10(火) 23:59:01

namespace の中はインデントする？
俺はしない。

365 ：デフォルトの名無しさん：2009/02/11(水) 03:25:36

基本はやらないほうだけど、
Java/C#では、IDEが勝手にやってくれるのでそのままやらせている。

366 ：デフォルトの名無しさん：2009/02/11(水) 15:14:16

いまだに、IDEのエディタよりテキストエディタを使ってる
名前変更は、grepで拾って一つ一つやる
そもそも名称変更をする時点で
設計がおかしいってことだし、そういう意味でコードの見直しにもなる

というオレは前時代の生き物だが、そうやって生き残ってきたから
この部分はそのまんまｗ

367 ：デフォルトの名無しさん：2009/02/11(水) 16:01:04

でも、若いのがIDE導入したいって言った時は、
前向きに検討してあげてね。

最近上司にO/Rマッパの話をしたら、
「そんなこと位、ケチらずにSQL書けよw
最近のはSQLも書けないのが多いってことなんかねー」
と言われた若いもんより

368 ：デフォルトの名無しさん：2009/02/11(水) 16:29:45

手間を減らすための手法は、使う側にメリットがあると感じさせなければただの余計な手間だからなｗ

369 ：デフォルトの名無しさん：2009/02/11(水) 16:36:56

Java+WebだとIDEなしは悲惨だぞ。
仕掛け上、膨大な数のファイルを取り扱うし整合性とるのだけでも大変だ。

370 ：デフォルトの名無しさん：2009/02/11(水) 19:04:31

SQL知らずにO/Rマッパー使いたがる馬鹿

371 ：367：2009/02/11(水) 20:56:18

>>370
どこからその発想が出てきたのか分かりませんが
そんな人がもしいたら馬鹿ですね。同意です。

372 ：366：2009/02/12(木) 00:35:22

>>367
いやいや、統合環境でもがつがつ組むときだけテキストエディタを使ってる
私は、フリーだし
誰かの面倒見るときでも、基本的には個人の自由と思ってる

373 ：デフォルトの名無しさん：2009/02/12(木) 07:55:52

>>371
お前のレスから出た発想に決まってるだろ低脳

374 ：デフォルトの名無しさん：2009/02/12(木) 08:14:58

おやおや

375 ：デフォルトの名無しさん：2009/02/12(木) 08:25:47

暇つぶしに煽ったら皮肉で返されて逆ギレっすかｗ

376 ：デフォルトの名無しさん：2009/02/20(金) 19:25:27

規約とはちょっと違うかもしれないけど、他に聞くとこないのでここでいいかい？
コードを管理するディレクトリ構成のことなんだけど、
ソースとヘッダーを同じディレクトリに入れてる人っているかな？
ライブラリのコードならヘッダーのディレクトリを分離しなきゃいけないだろうけど、
そうじゃなければ一緒にした方がやりやすいってやってるところもあるのかな？

377 ：デフォルトの名無しさん：2009/02/20(金) 19:54:54

好きなようにしたらいいと思うぞ。どっちにしても大した問題はないように思える。

378 ：デフォルトの名無しさん：2009/02/20(金) 20:12:40

いちいち分けないだろ

379 ：デフォルトの名無しさん：2009/02/20(金) 21:29:58

分けないのか？

380 ：デフォルトの名無しさん：2009/02/20(金) 21:33:59

IDEにおまかせ。

381 ：デフォルトの名無しさん：2009/02/20(金) 21:53:41

ライブラリでも配布時にヘッダ取り出せばいいし
必要とメリットに応じて。でいいんじゃない？　自分は分けてない

382 ：デフォルトの名無しさん：2009/02/21(土) 00:52:52

分けてない人多いのか

ところで今さらだけど、こんな記事あった
ttp://blog.scriptionary.com/2009/01/21/hungarian-notation-what-to-do/

383 ：デフォルトの名無しさん：2009/02/21(土) 01:02:05

いや、多いかは知らないぞｗ　書き込んだ２人は分けてないってだけだからなｗ

384 ：デフォルトの名無しさん：2009/02/21(土) 01:08:30

分ける意味がわからん

385 ：デフォルトの名無しさん：2009/02/21(土) 01:15:42

ハンガリアン表記法はコーディングの手間になるから使わない
ただ、ポインタとグローバル変数にはpとかg_をつけてる。取り扱い注意的な意味で。

386 ：デフォルトの名無しさん：2009/02/21(土) 01:16:25

複数のコンポーネントからなるプロジェクトの場合は、コンポーネントごとにディレクトリを作って
なおかつ、共通で使うヘッダファイルのディレクトリも作る。
コンポーネント内部でしか使わないヘッダファイルは、コンポーネントのディレクトリに入れる。

387 ：デフォルトの名無しさん：2009/02/21(土) 01:30:43

ハンガリアン表記法ね
Cの時は使ってる、C++とかオブジェクト指向系の言語だと考えちゃうね

388 ：デフォルトの名無しさん：2009/02/21(土) 01:33:46

>>385
コーディングの手間になるから使ってる
意識する分だけ誤りが少ないし、検索するときユニークになりやすい
同じ意味で型を変換したい時には楽

389 ：デフォルトの名無しさん：2009/02/21(土) 01:33:57

コメントの書き方で
flag = true; //フラグを立てる
とかいうのは意味ないと思う。コードを見ればすぐ分かることを書くのは無駄。

コメントはある程度のまとまったコードに対して、どういう意味があるかを書くと、いちいちコードを解析する手間が省けるから役に立つ。

疑問があるのは、コメントにコードの変更日と変更者を記入してるタイプ。役に立ったことがないんだが、役に立つんかね

390 ：デフォルトの名無しさん：2009/02/21(土) 01:45:12

10年20年使われるコードでは役に立つときもある

391 ：デフォルトの名無しさん：2009/02/21(土) 01:46:15

80 名前：デフォルトの名無しさん[sage] 投稿日：2007/11/08(木) 19:23:34
昔も似たようなスレあったな
俺はシステムハンガリアンも有効だとレスした
IDEによる入力サポートとか、カーソルあわせての型情報とか一切無い環境もあるからな
ってか俺のとこそうだし
と書いても理解してもらえなかった。
多分ここでも理解してもらえないなｗ

この意見をどう思う？

392 ：デフォルトの名無しさん：2009/02/21(土) 01:47:50

>>389
納品した後の修正とかなら書くよ

393 ：デフォルトの名無しさん：2009/02/21(土) 02:00:33

>>391
まずはWindows APIみたいにバンバンtypedefしろ。

394 ：デフォルトの名無しさん：2009/02/21(土) 02:06:37

>>391
役に立つならそれはそれでありだと思う。
よほどチープな機材しかない職場なんだろうな。

395 ：デフォルトの名無しさん：2009/02/21(土) 02:11:41

>>389 には完全に同意だ
とくに

>疑問があるのは、コメントにコードの変更日と変更者を記入してるタイプ。役に立ったことがないんだが、役に立つんかね

には泣くほど同意見だ。
読みにくいったらないよ。
SCMがあるのになぜコメントで書くのか

396 ：デフォルトの名無しさん：2009/02/21(土) 02:15:24

>>389
＞とかいうのは意味ないと思う。コードを見ればすぐ分かることを書くのは無駄。
まったく同意ｗ
//このフラグはここでのみ立つので、～ほにゃらら
とか書くならよいのだが、やってることを書くのはほんとアホ

＞コメントにコードの変更日と変更者を記入してるタイプ。
おれも役に立ったことがない、コードが読みにくいだけ
だれがどう変えたにせよ、今手を入れるのは自分なんだし
いまさら前任者を恨んでどうするって感じだわｗ
ファイルヘッダに履歴があれば充分って思う

397 ：デフォルトの名無しさん：2009/02/21(土) 02:15:29

バージョン管理なんて使わせてくれないところかもしれないだろ。
いや、SCMがあってもそういうのを書かされる話は聞くが。

398 ：デフォルトの名無しさん：2009/02/21(土) 02:41:39

>>395
> SCMがあるのになぜコメントで書くのか
どこにでもリポジトリがあるわけじゃありません。

399 ：デフォルトの名無しさん：2009/02/21(土) 02:43:12

あー、こいつが追加変更したところだから要注意だな、みたいなことはある。

400 ：デフォルトの名無しさん：2009/02/21(土) 02:54:24

いまどきソフトウェア開発プロジェクトでSCMを使わない以上の罪悪を探すのは難しいけどね

401 ：デフォルトの名無しさん：2009/02/21(土) 03:26:36

>>394
CodeWarriorというものがあってだな…

402 ：デフォルトの名無しさん：2009/02/21(土) 03:47:41

>>396
変更日・変更者コメントは、同時進行で進んでいるソース流用プロジェクトが、
流用元の最近の変更と自分たちの変更を区別するために欲しがっていたな。

403 ：デフォルトの名無しさん：2009/02/21(土) 03:53:56

>>401
組込のIDEには入力支援や型情報ポップアップがないって意味？
俺のとこではエディタとして別のIDE使ってたよ。組込の環境は使いにくいｗ

404 ：デフォルトの名無しさん：2009/02/21(土) 04:15:35

アセンブラだとメモリにどう入っているか分かるほうが楽

405 ：デフォルトの名無しさん：2009/02/21(土) 15:04:56

CodeWarrior のクソっぷりはなんとかならんか

406 ：デフォルトの名無しさん：2009/02/21(土) 17:25:27

>コードを見ればすぐ分かることを書くのは無駄。

アルゴリズムやデータ構造は知ってても、コードは読めんと言う相手と
連携しなきゃならん場合は必要だぞ。

具体的に例を挙げると、↓みたいなコードを、相手方にチェックしてもらうには
「読んで字のごとし」なコードもすごく重要。
・別言語で作ったアプリが吐いたデータを、整合性を崩さないように編集するコード
・ハードウェアを直接叩くコード

407 ：デフォルトの名無しさん：2009/02/21(土) 17:49:42

それは、「コードを見ればすぐ分かる」ことじゃない。

408 ：デフォルトの名無しさん：2009/02/21(土) 19:21:45

コードをみればすぐ分かるってのは、誰でも言語の知識だけでコードからすぐに読みとれること、と言い換えたら理解しやすいかもしれんな。
自分の知識ですぐ分かること、ではないぞｗ　言語以外の知識やその行付近以外の知識を必要とする時点ですでに「すぐ分かること」ではない。

例えばこういう感じ
*((volatile char*)0xF860) = 0;　　　//&HF860番地にゼロを書く　　←無駄なコメント

*((volatile char*)0xF860) = 0;　　　//VDPリセット　　←知識があれば分かることだが役にたつコメント

409 ：デフォルトの名無しさん：2009/02/21(土) 19:41:39

>>408
>*((volatile char*)0xF860) = 0;　　　//VDPリセット　　←知識があれば分かることだが役にたつコメント
これはコードをみればわかることじゃあないと思うな
0を入れるのか、リセットするのか、クリアするのかは、意味が少々違うからな

「文字」「文字値」「文字配列」「文字列」の違いみたいなものも結構気になる

410 ：デフォルトの名無しさん：2009/02/21(土) 20:10:39

>>409
コードを見れば分かる無駄なコメント　に対する　役立つものの例として、という意味ね
「そこにゼロ書けばVDPがリセットされる」って知識がある人には、例の２つは同じ「コードをみればすぐ分かるコメント」に見えるかもしれない
でも、>>389で言っている「コードをみればすぐ分かるコメント」ってのは前者（ゼロを書く）であって、後者（リセット）のコメントの付け方ではないよ。
という説明のつもりだったｗ

411 ：デフォルトの名無しさん：2009/02/21(土) 21:15:41

#define VDP_ADDRESS (volatile char*)0xF860
#define RESET 0

*(VDP_ADDRESS) = RESET;

412 ：409：2009/02/21(土) 21:32:26

>>410
同意

>>411
そうそう、オレならそうする。

413 ：デフォルトの名無しさん：2009/02/21(土) 22:23:07

#define VDP_ADDRESS ((volatile char*)0xF860)
#define RESET 0
#define RESET_VDP() *VDP_ADDRESS = RESET

RESET_VDP();

414 ：デフォルトの名無しさん：2009/02/22(日) 01:06:49

マクロ地獄だな

415 ：409：2009/02/22(日) 01:09:28

>>411は、レジスタのアクセスだけなのがわかるが、
>>413だと、いくつかのシーケンスが内蔵されているように見えるね

該当のレジスタに他の値を入れることがたびたびあって、この行でリセットをしたいなら、明示的な>>411
該当のレジスタには、他でアクセスすることがなく、ここでリセットするだけなら>>413だな

416 ：デフォルトの名無しさん：2009/02/22(日) 17:45:00

皆さんのお知恵をお借りしにきますた

どっかの本かWEBで、ブーリアンの引数名にはNoとかNotはつけるな
ってあったんだけど、みなさんどう思いますか？
例えばbool NoScrollとか

417 ：デフォルトの名無しさん：2009/02/22(日) 17:57:32

>>416
賛成の反対で、これでいいのだｗ

418 ：デフォルトの名無しさん：2009/02/22(日) 18:08:30

>>416
本とか読んでる訳じゃないから、俺の感覚だと…

別にbool型なんだから
NoScrollにtrue入れるか、Scrollにfalse入れるかでしょ
それなら、コード中でどう使うかで使い分ければいいんじゃない

絶対に、NoScrollを主体で判断した方がいい部分で使われるのが分っているなら
NoScrollとすれば良い

それ以外で、Scrollという状態をtrue or falseで見る使い方なら
わざわざフラグを反転させる意味にしない方か良いと思う

419 ：デフォルトの名無しさん：2009/02/22(日) 19:02:30

>>418
どうもありがとうございます
その本だかによれば、ブーリアンは意味的に「～する」の肯定で統一したほうが混乱が少ない、みたいなことを根拠にしてました
そうやって統一すると、何かを「する」場合はtrue、「しない」場合はfalseを指定すれば良くなる、と

マァ自分的にも個々の使い分けでいいと思いました

420 ：デフォルトの名無しさん：2009/02/22(日) 19:22:24

>>419
直感的に、True(真)なのにNo(否定)っていうのが誤りの元にならないかってことだよね。
"できるだけ"避けるべきだとは思うなぁ

ちょっとオレが変かもしれないけど
電気ポットの注ぎ口なんかよくハッとする
「赤」なのに「出る」のが気持ち悪い

421 ：デフォルトの名無しさん：2009/02/22(日) 19:37:12

混在させるより統一した方がいいとは思うけどどっちでもいいと思えるほどの些細なことに見える。

422 ：デフォルトの名無しさん：2009/02/22(日) 19:49:32

>>420
赤＝危険という風に見ればいい

423 ：デフォルトの名無しさん：2009/02/22(日) 20:23:15

>>416
否定後禁止ルールは、isとかcanとか三人単数ルールとかと併用しないと意味不明になりがちだと思う。
その場合ならCanScrollとかScrollsとか。

424 ：デフォルトの名無しさん：2009/02/22(日) 20:25:59

酷い日本語すみませぬ…。
×否定後 → ○否定語
×三人単数 → ○三人称単数

425 ：420：2009/02/22(日) 20:35:41

>>422
それはわかってるんだけどねｗ
出すことを前提に操作してるのに「赤」になるのがとてもアフォーざんす

426 ：デフォルトの名無しさん：2009/02/22(日) 22:22:51

なして？

427 ：デフォルトの名無しさん：2009/02/22(日) 22:55:00

信号機だと赤は停止の色だから？

428 ：デフォルトの名無しさん：2009/02/22(日) 23:15:36

・水は青、お湯は赤
・熱いから危険だから赤

429 ：デフォルトの名無しさん：2009/02/22(日) 23:22:32

>425
そこは「お湯を注ごうとしてる人」とは違うアクターを想像するんだ。
例えば「ポットを運ぼうとしてる人」とか。

430 ：デフォルトの名無しさん：2009/02/23(月) 00:52:59

>>429
わかっちゃいるんだけどね、例えば、車で
アクセルを踏むと赤いランプが点くとしたら、、、気持ち悪いよね
そんな感じ

431 ：デフォルトの名無しさん：2009/02/23(月) 01:06:41

そのつまんねー自分語り、いつまで続けるつもり？

432 ：デフォルトの名無しさん：2009/02/23(月) 01:19:19

>>431
レスがある限りｗ

433 ：デフォルトの名無しさん：2009/02/23(月) 02:49:40

>>431
2ちゃん歴浅いんか？
嫌ならお前が別の話題を振ればいい。

434 ：デフォルトの名無しさん：2009/02/23(月) 09:35:12

>>433
2ちゃん歴浅いんか？
気に入らないレスならスルーしろ。

435 ：デフォルトの名無しさん：2009/02/23(月) 13:06:16

おまえここは初めてか？力抜けよ。

436 ：デフォルトの名無しさん：2009/02/23(月) 13:28:14

420うぜーぞ

437 ：デフォルトの名無しさん：2009/02/23(月) 16:51:41

スルーしろといってる本人がスルーできてない

438 ：デフォルトの名無しさん：2009/02/23(月) 17:23:41

ｵﾏｴﾓﾅｰ

439 ：デフォルトの名無しさん：2009/02/23(月) 20:53:40

　　　　　　　,;:'';,　　　　　,;:' '; 　
　　　　　　,;'':.:.　';,,,.,.,.,.,.,;:' 　　'; 　　　
　　　　　､:´: .　　　　　　　　　　':,　　　
　　　　,':.:..:. .　　　　　　　　　　　':,　　　　ま、お茶でも飲んで休憩すれ。
　　　　';:.:.:.:.. ／　　　　　　＼　':, 　
　　　 ';::.:.:.:. .　●　　　　　　●　　;'　
　　　　';:::.::.:.　　　（__人__）　　　;'
　　　　　'':;,:.:.:.:.:. . 　　　　　　､:'　　　　　　　　　　　　（　(
　　　　　,;:'':.:.:. 　　　　　　　　 '::,,.,.,.,.,,.,,_　　　　　　　　ヽヽ
　　　　 ,;':::: ::　　　　　　　　　　　　　　　`()＼; _＿O＿_ 　)ノ
　　　 ,;'　;:.:.　　;,　　　　　　.:.''_,.,,.,.,.,.,.,.,_,:'" ＼/=￣￣ =ソ,ﾌi!
　　 ,;'　 ;;:.:.　　 ;,　　　　　;;''　　　　　　　　 {= = = = =イ .i!
　　 ;'　　 ';;:.:.　　;,　　　　;:'　　　　　　　　　　ﾞ､_= = =_ノ　 i!　
　　;,　　　 ';,　　 ,;　　　 ;'　　　　　　　　　　　￣￣　┌―‐┐～
　　;,　　　　ﾞﾞ''''''"　　　　;　　　　　　　　　　　　　　　　　　{　茶　}
　　:;　　　　;'''"ﾞﾞ'';:　　　:;　　　　　　　　　　　　　　　　　　ﾍニニﾉ
　　:;　　　　;　　 ;:　　　;　　　　　　　　　　　　　　　||￣￣￣￣￣￣￣||
　　':,　　　 ,;　　:;　　　 :;　　　　　　　　　　　　 ||　　　　　　　 ||
　　ﾞﾞ''''''''''"　　　ﾞﾞ''''''''''"

440 ：デフォルトの名無しさん：2009/02/24(火) 00:23:49

いや、俺はスルーしろなんて言ってないしなあ
命令しといて自分はやらない人につっこみ入れただけだしなあ。

441 ：デフォルトの名無しさん：2009/02/24(火) 00:26:10

レス乞食

442 ：デフォルトの名無しさん：2009/02/24(火) 00:30:51

呼んだ？

443 ：デフォルトの名無しさん：2009/03/02(月) 01:19:09

コメントに愚痴とかいいわけ書いてるやついるよなｗ
そういうヤツのコードは１関数１５００行とかスパゲッティな依存関係とかすごく汚いコードだったｗ
そんな事書くくらいならコードの可読性をあげるコメントを書けと

444 ：デフォルトの名無しさん：2009/03/03(火) 01:33:42

パスカル記法ってただ頭を大文字にするだけ？
ハンガリアンみたいに詳細に説明してるサイトがないからそれしかわからん

445 ：デフォルトの名無しさん：2009/03/03(火) 10:05:24

>>444
>パスカル記法ってただ頭を大文字にするだけ？

そんだけ。

446 ：デフォルトの名無しさん：2009/03/14(土) 12:19:31

おまいらtypedefどう思う？

いちいちtypedefしてんじゃねーよカスが。

447 ：デフォルトの名無しさん：2009/03/14(土) 12:50:46

なんでもかんでもtypedefするカス
typedefしなきゃ書けないコードを知らずに全否定するカス

448 ：デフォルトの名無しさん：2009/03/14(土) 15:23:25

批判 [編集]

一部の人々は、typedefを広範に使用することに反対している。
ほとんどの議論は、typedefは単に変数の実際のデータ型を隠すだけであるという考えに集中する。
例えば、Linuxカーネルハッカーであり、ドキュメント作成を行っているGreg Kroah-Hartmanは、
関数プロトタイプ宣言を除いて、typedefの使用をやめさせようとしている。
彼は、typedefを使用することが、必要以上にコードを混乱させるだけでなく、
プログラマが巨大な構造体を単純な型と誤認識して使用してしまうことがあると主張している[1]。

449 ：デフォルトの名無しさん：2009/03/14(土) 17:34:56

>>448
どこからの引用なのか書けや

450 ：デフォルトの名無しさん：2009/03/14(土) 18:04:54

ここだな。
ttp://ja.wikipedia.org/wiki/Typedef#.E6.89.B9.E5.88.A4

451 ：デフォルトの名無しさん：2009/03/14(土) 18:17:03

>>446
typedefはCとC++ではまったく事情が違う。
C++でテンプレートメタプログラミングするなら必須

452 ：デフォルトの名無しさん：2009/04/19(日) 16:03:42

そうかなあ

453 ：デフォルトの名無しさん：2009/04/19(日) 22:00:52

そうだよお

454 ：デフォルトの名無しさん：2009/05/29(金) 15:01:49

>>451
<>の中が書きにくいとか一行が長くなるとか？

455 ：デフォルトの名無しさん：2009/05/29(金) 15:58:01

trait

456 ：デフォルトの名無しさん：2009/05/29(金) 21:46:05

>>454
超大雑把に言うと、
データを渡すために変数が必要なように、型を渡すためにtypedefが必要だということ。
身近な例だとstd::vectorのvalue_typeとか。

457 ：デフォルトの名無しさん：2009/06/05(金) 03:28:55

自分がメンテするわけでもないコードにコメントなんか書かない。
マクロも定義もしない。
リリースまで立ち会えば、あとは、プリプロセッサを通した綺麗なソースだけを
残す。
後のヤツは苦しめ。俺のときは動いたんだから、それを動かせないのはおまぃらが
ドン臭いからだ。

これが派遣渡り鳥の現実です。

458 ：デフォルトの名無しさん：2009/06/05(金) 23:57:54

>>457
こいつ最低だな。
たいした能力も無いくせに・・・。
派遣雇うような環境なら周りはレベル低いやつばかりだろうから、自ずと自分の
能力が高いとか思いこむんだろう。
こう言うのが人生負け組、嫌われ者で、同じ所から二度と仕事の依頼がないんだろうな。

459 ：デフォルトの名無しさん：2009/06/06(土) 00:47:50

プリプロセッサがどうのっていう奴がそんなに変なコードを書くわけが無いだろ
まあネタでしょ

460 ：デフォルトの名無しさん：2009/06/06(土) 05:06:08

最低だの能力が低いだのとクサしていればいいさ。
メンテナンスの必要な間の雇用が保証されて給料の支払われる正社員の方はそういうメンテナンスしやすい
コードを引けば良いんだから、その分みっちり支払ってコメントかかせればいいよ。

その場限りで使い捨て搾取するんだから、その場限りのコードしか渡されないのは、やむなし。
同じところからの仕事の依頼なんてハナから期待していない。他の仕事していれば、断らざるを得ないし、
間を空けずに次の仕事を言ってくるのに派遣でつないでるようなろくでもない経営者と働くのはそもそも
イヤだしな。
ま、どうしても困ったときには呼んでくれ。土日スポット料金でおもくそ吹っかけてやんよ。

……くらいのものかな。

461 ：デフォルトの名無しさん：2009/06/07(日) 20:05:58

>>460
このひねくれ具合、もうだめだねこりゃ。

462 ：デフォルトの名無しさん：2009/06/07(日) 21:31:53

気持ちは分からなくもない
ドキュメントもなし、前時代のコーディング規約を押し付けて、ごてごて盛り付けていったような既存のコードの改造で、
テストまでこちらにやらせて、不具合だ未実装だと難癖付けて、ズルズル拘束しておきながら、なにげに機能追加まで盛り込んで
支払いもゴネたうえに、使い捨てるようなクライアントには、そんな対応でもしてやりたくなるわな

463 ：デフォルトの名無しさん：2009/06/08(月) 01:02:02

プリプロセッサを通したソースって、「綺麗なソース」って言うんかいな？
（Ｃのプリプロセッサの事だよな？）

何もかも展開されて、これを「はい、ソースです」って提出するのはありえんと思う
がそうでも無いのか？

464 ：デフォルトの名無しさん：2009/06/08(月) 03:20:39

バイナリ必須、ソースは形式的に納入するだけでおｋという場合もあるし。

465 ：デフォルトの名無しさん：2009/06/08(月) 11:57:24

メンテナンスが必要になるであろう部分を派遣でどうにかしようということ自体が
間違ってるんではないの？

466 ：デフォルトの名無しさん：2009/06/08(月) 16:11:06

>>465
メンテが必要ないプログラムってあるのか？

467 ：デフォルトの名無しさん：2009/06/08(月) 17:30:51

だっらプログラムを派遣に書かせることが誤りだ。

468 ：デフォルトの名無しさん：2009/06/08(月) 21:32:02

>>467
社員にそれだけの能力がある会社がどれだけあるんだかｗ

469 ：デフォルトの名無しさん：2009/06/08(月) 21:46:59

そろそろ言ってもいいよね？

マ板でやれ

470 ：デフォルトの名無しさん：2009/06/09(火) 02:43:33

一般的に、社員と派遣とどっちが技術高いの？

471 ：デフォルトの名無しさん：2009/06/09(火) 06:35:18

>>470
一言で言えば、いろいろ。
社員だけで足りないから、外に頼む。
外に頼むと、いらんやつがもれなくついてきたりする。
システムの規模によるが、数人～十数人規模のシステムなら
賢いところは、会社と付き合わずに、個人を特定して捕まえておく。
いいコードは、製品というより作品。
どんなにドキュメントをそろえても
作った会社にメンテを頼むより、作った個人にやらせるほうが数十倍早くて正確だから。

472 ：デフォルトの名無しさん：2009/07/01(水) 23:02:00

クラス内のメンバの記述順ってどうしてる？
フィールド変数・プライベートメソッド・
パブリックメソッド・パブリックプロパティ順にすると
宣言と使用箇所が離れて見にくいし
宣言と使用箇所を近くするにも限界がある
散らかした部屋の中みたい
使っている言語はC#

Delphiだと宣言がいやでもまとまるので見やすかった
実現部はIDE任せでアルファベット順だった

473 ：デフォルトの名無しさん：2009/07/02(木) 00:02:31

>>472
C# の場合は、Visual Studio のクラスビューの並びに合わせてる。

474 ：デフォルトの名無しさん：2009/07/02(木) 00:48:06

メソッド・プロパティ・フィールド・イベントのアルファベット順か
決めてしまえば迷うこともないかな、やってみる

475 ：デフォルトの名無しさん：2009/07/03(金) 13:15:12

あれこれ考えるより、多少理屈に合わなくても機械的に決めちゃったほうが楽だよな。

476 ：デフォルトの名無しさん：2009/07/03(金) 18:34:59

後でどうとでもなるものは、比較的どうでもいいというか、後で考える。
書くときは気の向くまま、というと変だが、気にしないで書いて、あとで整形するから気にしない。

477 ：ゴロゴロ：2009/09/11(金) 21:12:39

XML を定義するときって、要素の名前は
<ABC> と <abc> のどっちがいいと思いますか？
どっちが一般的でしょうか？

478 ：デフォルトの名無しさん：2009/09/11(金) 23:06:19

>>477
XML のタグは大文字・小文字を区別するから、どちらか
一方に統一するのではなく、Pasacl 記法で命名してる。

タグの大文字小文字の区別、使える文字を教えて
http://www.atmarkit.co.jp/fxml/askxmlexpert/011tagname/11tagname.html

もし一方に統一する必要があるなら、XHTML などに倣っ
て小文字にするだろう。

479 ：デフォルトの名無しさん：2009/09/12(土) 13:26:03

やっぱり俺式コーディング規約って言語ごとに別々に作るもんなの？
それとも一個汎用的なの作ったら、あらゆる言語でそれをつき通すもんなのかな

480 ：デフォルトの名無しさん：2009/09/12(土) 22:16:40

あらゆる言語で突き通す馬鹿とは、できれば一緒に仕事したくないな。

481 ：デフォルトの名無しさん：2009/09/13(日) 23:42:41

>>479
似た様な言語なら流用するじゃないの。
例えば、Javaのコーディング規約をC#に流用するとか。マイクロソフト標準とちとずれるかもしれないけど。

482 ：デフォルトの名無しさん：2009/10/19(月) 01:40:22

C++でfunction_name()のように小文字＋アンダースコアの関数名って異端ですか？

483 ：デフォルトの名無しさん：2009/10/19(月) 01:46:55

Stroustrupがバリバリ使ってる

484 ：デフォルトの名無しさん：2009/10/19(月) 16:17:04

>>482
オレはそればっかり
一方、変数は頭大文字

485 ：デフォルトの名無しさん：2009/11/25(水) 18:41:36

誘導されてきました

C++ でboolのメンバ変数を設定・参照したいんだけど
1)
void SetEnable(bool value);
bool GetEnable();

2)
void SetEnable(bool value);
bool IsEnabled();

3)
void Enable();
void Disable();
bool IsEnabled();

4)
bool Enable();
void Enable(bool value);

それぞれの長所と短所を教えてくらさい
一番長所が多いＯＲ一番短所が少ないやつにします

486 ：デフォルトの名無しさん：2009/11/25(水) 19:27:17

>>485
Enableって聞くと単にbool型変数の値を変更するだけじゃなく、有効にするための処理も含まれてると想像するけど。
それなら3)。
単にbool型変数の値を変更するだけなら1)かなぁ。

487 ：デフォルトの名無しさん：2009/11/25(水) 20:21:04

EnableXXXにすれ

488 ：デフォルトの名無しさん：2009/11/25(水) 20:40:51

本筋じゃないけど、属性としては enabled にしたいなあ。

489 ：デフォルトの名無しさん：2009/11/26(木) 01:05:56

>>485
> C++ でboolのメンバ変数を設定・参照したいんだけど

実装から名前を決めようなんて考えてる時点で根本的に間違ってる。

490 ：デフォルトの名無しさん：2009/11/29(日) 21:04:22

>>485
5)
bool set(int id, bool val);
bool get(int id);

１～４は変数増えたら API も増えるだろ。
生成時間もメモリ消費量も無駄に増える。

491 ：デフォルトの名無しさん：2009/11/29(日) 21:06:01

>>490
せめてidはenumにしろ。

492 ：デフォルトの名無しさん：2009/11/29(日) 21:15:44

まあ enum でも int でも char * でもいいね。

ただ、enum にするとコンパイラの最適化で short に
されちゃったりすることがある。組み込みの armcc とか。

複数のコンパイラが混在する場合は int か u32_t
みたいに CPU で決まる型にしておくのがいいよ。

493 ：デフォルトの名無しさん：2009/11/29(日) 23:09:00

コンパイラ規約に則ったコーディング規約か、意識したことないな

494 ：デフォルトの名無しさん：2009/11/30(月) 16:51:00

型チェックしたくない?

495 ：デフォルトの名無しさん：2009/11/30(月) 16:56:08

>>492
enumの肝は、妙なidをコンパイルエラーにしてくれるところジャマイカ?

496 ：デフォルトの名無しさん：2009/11/30(月) 17:02:08

>>495
C++だとチェック入るけど、Cだと実質整数だったような。

497 ：デフォルトの名無しさん：2009/11/30(月) 18:23:34

警告ぐらいは出たっけかなぁ・・・?

と思って gcc で試したけど、enum の型に無茶な数値入れても
警告最大だろうがなんだろうが何も言われなかった。

498 ：デフォルトの名無しさん：2009/11/30(月) 22:14:10

コンパイラが警告を出すか微妙な線だな。
lintなら警告するんだけど。

499 ：デフォルトの名無しさん：2009/12/02(水) 01:02:07

enum を signed で扱うか unsigned で扱うかも微妙で、
フラグに 0x80000000 立てるのが大好きな人にはウケが悪い。

みんな、ちゃんと -Wextra つけてるか？

if (err < 0) って書いて err が unsigned int
だったりすると恥ずかしいぞｗ

500 ：デフォルトの名無しさん：2009/12/02(水) 20:54:14

今どきエラーを数値で判定する男の人って…

501 ：デフォルトの名無しさん：2009/12/02(水) 22:23:24

処理系によっちゃ数値で判断するところもあるんじゃね？

502 ：デフォルトの名無しさん：2009/12/03(木) 01:22:31

中身が数値でも定数と判定しろよ、ってことじゃないの。
if (err != E_OK) とか。

503 ：デフォルトの名無しさん：2009/12/03(木) 02:14:26

Linux とかだと普通にあるな。

504 ：デフォルトの名無しさん：2010/03/05(金) 15:28:36

C++のグローバルスコープ解決演算子ってどうしてる？
（ネストしてるnamespaceで外側のスコープの解決とかも）

1. 出来るだけ解決演算子を付ける
2. 出来るだけ解決演算子を付けない
3. 名前が重複しがちな関数とか、特定のものだけ注意して付ける

俺はあんまりつけてないんだけど、何にでも付けてる人もいるし、
付けた方がいいよってガイドラインでもあるのかね。

自分の中での取り決めとか、例外とかもあれば教えてくれるとうれし

505 ：デフォルトの名無しさん：2010/03/06(土) 01:07:48

>>504
1 はウザすぎ、 2 はちょっとウザいことがあるかもしれない、 3 はスタイルとして成立してない。

グローバルスコープ解決演算子をどうする、とか考えるんじゃなくて、要らないものが
書いてあって見づらいなら消せばいいという当たり前の話で済まないのか？

506 ：デフォルトの名無しさん：2010/03/06(土) 17:15:16

2 だな。

つか、グローバルはご先祖様みたいなもんで身内と
同等の扱いだろ。

どうせ、頻繁に :: つけないといけないような実装は
他でも override とか static 忘れでバグ頻発するような
レベルのコードしか書けない奴。

507 ：デフォルトの名無しさん：2010/03/07(日) 01:01:21

付けるそのものにメリットがある訳じゃないが、
インテリセンス使ってる時は付けた方が便利ゆえ、
付けない事を強制するのもどうかと思う。

そもそも強制したってメリットの無いルールを強制するのは
労力の無駄遣いだと思う。
コンパイラ等でチェックできるならばしても良いとは思うけど。

508 ：デフォルトの名無しさん：2010/03/07(日) 21:27:31

わしは Windows のプログラム書かんから
つけないけど利便性があがるんなら
つけてもいいよ。

でも Cライブラリや Win32 API と同じ名前の関数を
自分のクラスに作るのは許さん。たとえ open/close であっても。

509 ：デフォルトの名無しさん：2010/03/08(月) 00:49:41

OpenやCloseならいいんですね？わかります。

510 ：デフォルトの名無しさん：2010/03/08(月) 04:07:55

>>508
お前とは一緒に仕事したくないわｗ

511 ：デフォルトの名無しさん：2010/03/08(月) 08:47:23

規約裁定時は宗教戦争が公式に認められる瞬間だからな。

512 ：デフォルトの名無しさん：2010/03/09(火) 22:22:49

無駄なたらい回しを否定する意味で言ってるなら508の意見には同意。
たまに m_pMember->Hoge(); を Hoge(); と短縮するのが目的みたいな
ラッパー関数が存在するが、正直止めて欲しい。

513 ：デフォルトの名無しさん：2010/03/09(火) 22:58:13

Hoge->m_pMember() を Member() だよね？言いたいことって。

514 ：デフォルトの名無しさん：2010/03/10(水) 01:55:58

>>509
CLibrary::open(char *file) {
return open(file, O_RDONLY);
}
みたいなのを書く奴がおるんよ。。。

515 ：デフォルトの名無しさん：2010/03/10(水) 03:06:15

>>514
そのコードの何が問題？

516 ：デフォルトの名無しさん：2010/03/10(水) 03:44:26

>>514
やはりお前とは仕事したくないでござる

517 ：デフォルトの名無しさん：2010/03/10(水) 07:29:32

C++ならそれぐらい普通だろ

518 ：デフォルトの名無しさん：2010/03/10(水) 07:49:22

>>514 の不人気さにわろた

519 ：デフォルトの名無しさん：2010/03/10(水) 07:53:57

「無駄なたらい回し」という発想がわからない。
リファクタリング読んだ？

520 ：デフォルトの名無しさん：2010/03/10(水) 10:30:12

Windowsの関数はマクロで別名付けたりしてるから、
SendMessageとかいう関数を作ったら、実はSendMessageWって名前になってました、とかあるよね。

521 ：デフォルトの名無しさん：2010/03/11(木) 01:03:03

>519
class Moge{
　public: void func();
};
class Hoge {
　Moge* m_pmoge;
　private: void func(){ m_pmoge->func(); } //←こーいうの
};

Hoge が func() の主語として適切なら良いが、そうじゃなければ
リファクタリング云々以前に、オブジェクト指向的に間違ってる。
Hogeを主語とすると不自然なものは、privateであってもメンバに加えるべきじゃない。
どうしてもラッピングしたいなら、Mogeのエイリアスとなるクラスを用意して、
そのクラスを使ってやるべき。

522 ：デフォルトの名無しさん：2010/03/11(木) 01:08:46

>>521 「たらい回し」は関係ないな。

523 ：デフォルトの名無しさん：2010/03/11(木) 01:18:58

>>521
おいおい、このご時勢にどんだけ時代遅れなんだよ

524 ：デフォルトの名無しさん：2010/03/11(木) 01:22:11

>Hogeを主語とすると不自然なものは、privateであってもメンバに加えるべきじゃない。
伝説級の迷言
デザパタの半数以上がオブジェクト指向的に間違ってるらしい。

525 ：デフォルトの名無しさん：2010/03/11(木) 01:25:24

>>515-517
ダメだな。基本がなってない。

526 ：デフォルトの名無しさん：2010/03/11(木) 02:37:28

>>521
そのスタンスで何か一つでもアプリを作れたら報告してください。
最終的にあらゆるオブジェクトがお互いの参照を持たないことになるわけですが。

527 ：デフォルトの名無しさん：2010/03/11(木) 09:02:05

>>521
委譲って言葉を知ってるか？

528 ：デフォルトの名無しさん：2010/03/11(木) 09:41:11

いまんとこ>>527のツッコミが一番的確でスマート。

529 ：デフォルトの名無しさん：2010/03/11(木) 22:32:31

>>521とは絶対に一緒に仕事したくない

530 ：521：2010/03/11(木) 22:45:42

>521
>Hogeを主語とすると不自然なものは、privateであってもメンバに加えるべきじゃない。
不正確で誤解を招く表現だったので訂正&補足。

Hogeを主語とすると不自然な「関数」は、privateであってもメンバに加えるべきじゃない。
より適切なクラスに持たせて、そのクラスのオブジェクトなり参照なりを持つようにすべき。

一応文脈的に「もの」=「関数」と読み取って欲しいところだけど、
暴論過ぎますな。すんません。

531 ：デフォルトの名無しさん：2010/03/11(木) 23:41:15

そこ突っ込まれてると思ったのかｗ

532 ：521：2010/03/12(金) 01:25:02

>531
ここじゃなかったら何だろうね。
もしかしたら>521のようなコードを、「全て」否定してると勘違いしてる?
否定してるのは「クラスが関数の主語として不適切な場合」だけだけど。
ProxyやFacadeのようなパターンは否定していない。
（これらは委譲先のクラスの別称あるいは総称であり、主語として適切）

533 ：521：2010/03/12(金) 01:30:03

追記。
もっともProxyやFacadeのようなパターンの場合、>521のようにラッパー関数が
privateになる事はほとんど無いと思うけどね。

534 ：デフォルトの名無しさん：2010/03/12(金) 04:55:35

すごいな
どんどんトンチンカンになっていく

535 ：デフォルトの名無しさん：2010/03/12(金) 11:19:06

>>521
同僚にお前って鳩山系だよなって言われない？

536 ：デフォルトの名無しさん：2010/03/12(金) 14:32:08

もうやめとけ。

537 ：デフォルトの名無しさん：2010/03/12(金) 15:28:04

>>521=>>514なのか？

だとしたら、なぜ>>514を良くないと考えるのか、HogeとかMogeとかfunc抽象的な話をせずに、
>>514のコードがどのような理由で良くないのか、ずばっと主張してくれ。

538 ：デフォルトの名無しさん：2010/03/12(金) 16:06:27

>>534も必要最小限で的確なツッコミだな。

539 ：デフォルトの名無しさん：2010/03/12(金) 16:36:10

何が言いたいのかさっぱり分からんから具体名で提示して貰いたいもんだ
ユーティリティクラスの全否定にしか見えんが

540 ：デフォルトの名無しさん：2010/03/12(金) 18:15:00

>>514はシステムコールのopen()を抽象化してるので良いと思うが。
open()がコードにあちこち登場して、なおかつ"/dev/物理デバイス"をopen()するような
ことだったら目も当てられない（テスト的に）。

541 ：521：2010/03/12(金) 20:38:38

>537
514≠521ですが何か。
514とは違う切り口で519の「無駄なたらい回し」の例を挙げてるだけなのだが。
いまいち理解を得られてないようなので、例を少し具体的にしてみた。

　class Data {
　　public: void SaveToFile() {
　　　open();
　　　write();
　　　close();
　　};
　　private:
　　　void open(){ m_pfile->open(); }　　//←こーいうのが
　　　void write(){ m_pfile->write(); }　　//←無駄だと
　　　void close(){ m_pfile->close(); }　　//←言いたい
　　　File* m_pconfigfile;
　};
open/write/closeは厳密にはFileに対する操作であるのだから、
Dataのメンバに加えるのは、そもそもオブジェクト指向的に間違ってる。

542 ：デフォルトの名無しさん：2010/03/12(金) 22:22:39

プライベートメソッドを省略のためだけみたいな使い方するなって言ってるんだろうけど
それどこの誰がオブジェクト指向違反だって言ってるの？

そのオブジェクト内でしか使わない、昔の C で言うところの static 関数みたいな使い方も
普通によくされてることだし、教科書でも別にあーだこーだ言ってるものは見たことないが。

543 ：デフォルトの名無しさん：2010/03/12(金) 22:23:55

文字通りその通りのコードだとしたらまさしく無駄だが、
オブジェクト指向的に間違っているのとは違うだろ。
public/protectedでopen/write/closeを公開するのなら
間違ってるかどうかの議論になるが。

544 ：543：2010/03/12(金) 22:24:51

ほぼ同時刻に、ほぼ同内容でかぶってしまった orz

545 ：デフォルトの名無しさん：2010/03/12(金) 22:30:44

>>514は、間違って変な引数入れないように、
決め打ちで引数入れて覆い隠してしまうことならあるな。

>>541も抽象化と言われれば、まあそうなのかと思えたりもするかも。
確かに基本無駄だろうな。
例えばconfig_openとかの名前にするのはどう思う？それもだめ？
あと、サブクラスでオーバーライドする用なんて可能性はどう？
（厳しい言語はprotectedじゃないとダメなのかな？）

546 ：543：2010/03/12(金) 22:35:50

ひょっとして>>512なのかな？
そもそもWrapperの認識が俺とは違う。
普通、Wrapper関数とかWrapperクラスというのは、AがBを直接呼ばないように（呼ばなくて良いように）
CにAが使うI/Fを定義して（あるいは、Bが提供する機能をCに定義して）、CのみがBにアクセスするよう
にするのを言うんじゃないか？

つまり、Wrapper関数/クラスCはAとBの間に構築するもので、AとBの外側にあるもの。

自クラス内のprivateメソッドにopenを分離するのをWrapすると言うのは聞いたことがない。
委譲の時にもWrapという単語を使うのは見たことないなぁ。

547 ：デフォルトの名無しさん：2010/03/12(金) 22:50:53

>>541
例えば、数行からなる、複数メソッドで使用するdatabseのopen/write/closeをprivateメソッドとして実装するのも
オブジェクト指向的に間違っているという主張？

それとも単に1行だからNGってこと？

548 ：デフォルトの名無しさん：2010/03/12(金) 22:52:40

private メソッドの主語まで自身のオブジェクトに紐付けしなきゃいけないとか
はじめて聞いたわw

やっぱ自称オブジェクト指向技術者はピンキリだね。

549 ：512=521=541：2010/03/13(土) 03:41:50

>546
>例えばconfig_openとかの名前にするのはどう思う？それもだめ？
open/write/close は否定しているが、SaveToFile は否定してない。が答え。

>あと、サブクラスでオーバーライドする用なんて可能性はどう？
541の例で言うと、Fileクラスを派生させてオーバーライドする形式が一番好ましいかと。

>つまり、Wrapper関数/クラスCはAとBの間に構築するもので、AとBの外側にあるもの。
だからこそopen/write/closeがData内にあるのは変という主張なんだけど。

>547
>例えば、数行からなる、複数メソッドで使用するdatabseのopen/write/closeを
>privateメソッドとして実装するのもオブジェクト指向的に間違っているという主張？
そのクラスとの関連が強い処理で、分離するには粒度が小さくなりすぎる場合「とか」は、
無理して分離する必要は無いと思う。（他にも例外はあるかと）

ただし>541みたいに、必要性が薄いのに分離されてるものを別のクラスに引き込むのは
当然駄目/無駄だと思う。

550 ：デフォルトの名無しさん：2010/03/13(土) 04:19:20

>>549
俺は>>541のprivate methodのようなものはWrapper関数とは俺なら言わないよってだけのことで、
Wrapper関数だからclass Dataの外側に持って行けとは言ってないよ。

Wrapper云々については、俺とは認識が違うなぁというだけの話なので、今回の本筋とは全く関係ないよ。

> そのクラスとの関連が強い処理で、分離するには粒度が小さくなりすぎる場合「とか」は、
> 無理して分離する必要は無いと思う。（他にも例外はあるかと）
えーと、分離すべきかどうかの話じゃなくて、オブジェクト指向的に間違ってるかどうかという質問
なんだけど。

databseへのアクセスを提供するクラスではなくて、それを使用するクラスでdatabaseアクセス
部分をprivateメソッドに抽出することもオブジェクト指向的に間違っているのかという質問。

> ただし>541みたいに、必要性が薄いのに分離されてるものを別のクラスに引き込むのは
> 当然駄目/無駄だと思う。
うーん、Fileの場合は間違っていて、databaseの場合は無理して分離すべき必要が無いというのが
良くわからん。

551 ：デフォルトの名無しさん：2010/03/13(土) 04:51:57

>>549
> 541の例で言うと、Fileクラスを派生させてオーバーライドする形式が一番好ましいかと。
わけがわからん。

class DerrivedFile {
public:
void Open() { open(); }
void Wite() { write(); }
void Close() { close(); }
}
を作れってこと？
これでも状況は全く同様で、
class Data {
　　public: void SaveToFile() {
　　　open();
　　　write();
　　　close();
　　};
　　private:
　　　void open(){ m_pfile->Open(); }
　　　void write(){ m_pfile->Write(); }
　　　void close(){ m_pfile->Close(); }
　　　DerrivedFile* m_pconfigfile;
　};
になるだけなんですが。で、今度は何を派生させますか？

552 ：デフォルトの名無しさん：2010/03/13(土) 05:54:34

クラス無駄にポコポコ作れば俺オブジェクト指向やってるカッケーって脳汁でまくる知的障害者なんだろ

>>549の論理で徹底するとクラスの数は無限大に発散する

553 ：デフォルトの名無しさん：2010/03/13(土) 06:08:04

>>541の例が>>541の言いたい事を表す為には全然具体性が欠けていると言う。
それが無駄なのは明白だが、単にその例に限定して無駄なだけでは？
オブジェクト指向的に間違っていると言う話はどこへ？
Dataがセーブ先のpathを自分で管理しなければならない場合はどう実装すれば良い？

結局例も挙げられないほど自分が何言ってんのか理解してないとしか思えない。

554 ：デフォルトの名無しさん：2010/03/13(土) 06:08:34

無駄なたらいまわしの話なのに、オブジェクト指向的に間違っているとか言い出すから話がおかしくなる

555 ：デフォルトの名無しさん：2010/03/13(土) 06:10:04

つか、土曜早朝にこんな底辺のスレに人居すぎだろｗ

556 ：デフォルトの名無しさん：2010/03/13(土) 06:17:40

まぁ>>541マンマのコードを書くような糞馬鹿野郎が実在するなら、そいつはゴミクズである事は誰もが同意するだろう
ただし、>>Hogeを主語とすると不自然な「関数」は、privateであってもメンバに加えるべきじゃない。　には誰一人として同意しないだろう

557 ：デフォルトの名無しさん：2010/03/13(土) 06:25:20

Dataクラスが実用レベルまで拡張されると、>>541の例のメンバが十分な正当性を持ち始めるんだがな。
512=521=541は数万ステップのコード書いた事あるか？

558 ：デフォルトの名無しさん：2010/03/13(土) 06:54:17

マチガッテル君
次はそんな無意味なコードじゃなくて
オブジェクト指向的に間違ってることを表すコードをお願いします
少なくともその無意味なコードはオブジェクト指向的に間違ってるとはいえません

559 ：デフォルトの名無しさん：2010/03/13(土) 06:57:02

「オブジェクト指向的に間違ってる」と示されたところで、だから何なの？っていう状態は
変わらない気がする。

普通に何が問題なのか（どんな困ったことが起こるのか）を示してくれればいいんだよ。

560 ：デフォルトの名無しさん：2010/03/13(土) 07:01:38

破綻例を示せって事だな

561 ：デフォルトの名無しさん：2010/03/13(土) 07:14:22

個人的な妄想じゃないと言うならクラスが主語にならないならprivateだろうとメソッドを作るべきでないと記述されている文献の提示でもいいよ。

562 ：デフォルトの名無しさん：2010/03/13(土) 09:11:34

ソフトウェア業界はたまーにこういうのが潜んでるから面倒だよね。
一見わかってるふうだからたちがわるい。

563 ：デフォルトの名無しさん：2010/03/13(土) 09:21:22

>>562
簡単な見分け方がある
「～は駄目だ」と言う奴は99%役立たずの勘違い馬鹿
コイツの戯言は何一つ聞き入れる必要が無い

「そこは～にすると良い」と言える奴は99%有益な意見を持つ人間

この見分け方は別にソフトウェア業界に限らない

564 ：デフォルトの名無しさん：2010/03/13(土) 19:34:45

>>563
お前は駄目だ

565 ：545：2010/03/13(土) 20:12:29

>>549
長文ですまん、横道ですまん、そしてprivateとかprotectedとか無視してすまんが、
例えば、下の２通りの派生の仕方なら下の方が好ましいということ？
で、根拠はFileはopenするものだが、Dataはopenするものではない、SaveToFileならToFileとあるのでより正確、ということ？
(ちなみにconfig_openはOKなんだよな？)
メソッド名が適切ならどっちでもあり？

class DataWithLog : Data {
　　void open(){ log("open"); super->open(); }
　　void write(){ log("write"); super->write(); }
　　void close(){ log("close"); super->close(); }
};
　
class FileWithLog : File {
　　void open(){ log("open"); super->open(); }
　　void write(){ log("write"); super->write(); }
　　void close(){ log("close"); super->close(); }
};

privateとはいえ、そこにこだわりたい気持ちは分かってきた気がする。命名について考え直すいい機会になった。
少し違うがその場での構造化のためにクラスにメソッドを作る違和感というのは時々感じてた。
クラスの中に、そのクラスしか使わないけどクラスメソッドでもインスタンスメソッドでもないただの関数が書ければそれがいいのかもな。
private:の他にfunction:みたいなのがあれば個人的にすっきりするかも。

なんにしろ、最初から完璧は難しいと思うから、名前は後からでも変えられると気楽に考えてみてはどうよ。
"達人自身にルールを作らせて、ルールに従わせると逆に作業効率が下がった"みたいな話もあるらしいぞ。
出典はたしかリファクタリングウェットウェア。ときには型を破ることも大切らしい。

566 ：デフォルトの名無しさん：2010/03/13(土) 20:27:40

嫌でも権限の纏わりつく今の世の中、DataはOpenするものだけどね

567 ：512=521=541=549：2010/03/13(土) 21:00:37

ちょっと整理しなおしておこう。
漏れが言いたいのは、まず↓は明らかに無駄だって事。
　class Data {
　　public: void SaveToFile() {
　　　open();
　　　write();
　　　close();
　　};
　　private:
　　　void open(){ m_pFile->open(); }　　//←こーいうのが
　　　void write(){ m_pFile->write(); }　　//←無駄だと
　　　void close(){ m_pFile->close(); }　　//←言いたい
　　　File* m_pFile;
　};

だけど、↓は辛うじて許容されると思う。（設計の良し悪しは別として）

　void opendata(){ m_pFile->open( m_datafile_path ); }

両者の違いは何か?と言う理由を考えたとき、一番単純明快な理由が
前者はオブジェクト指向的に間違ってるという事。
open/write/closeは明らかにFileに対する操作であって、
Dataに対する操作ではない。Dataだけが行う操作でもないし、
DataはFileの別称または総称でもない。

一方、後者はDataだけが行う操作。主体はデータファイルだから
原則を徹底するなら別クラスとして切り離すべきだけど、
その場合クラスの粒度が細かくなりすぎる。

一言でまとめるなら、「無駄なたらい回し」は何を持って無駄か?ってのは、
オブジェクト指向的にどこまでが妥当か?で判断すりゃ良いんじゃないかと
言いたかった。

568 ：デフォルトの名無しさん：2010/03/13(土) 21:06:34

>>567 >>559

569 ：デフォルトの名無しさん：2010/03/13(土) 21:24:38

>551
541の例は単純に↓がベストであると考えている。
open/write/closeをラップしたいなら、Fileをラップするクラスを作り、File*を置換する。
　class Data {
　　public: void SaveToFile() {
　　　//省略
　　};
　　private:
　　　File* m_pconfigfile;
　};

>552
>クラス無駄にポコポコ作れば俺オブジェクト指向やってるカッケーって脳汁でまくる知的障害者なんだろ
それは549で否定してるがな。
粒度の小さいクラスは、妥当なクラスに併合すれば良い。
でも>541みたいなのはそもそもopen/write/closeをラップする意味がないし、
併合先を間違えているとも言える。（Fileに併合して消滅させるべき）

>557
>Dataクラスが実用レベルまで拡張されると、>>541の例のメンバが十分な正当性を持ち始めるんだがな。
それはない。
open/write/closeにDataクラス固有の処理が追加されるならまだわかるけど。
でもその場合も必要になった時点で追加すれば良い。

>565
ルールを押し付けたいのではなく、原則はこうだよねというノリで書いております。
（如何なるルールにも例外はあると思う。）

>566
Dataに「Open」という関数を追加するのがNGなのではなく、
余所で定義済みの関数を、わざわざData内で定義しなおしてるのがNG。
「データファイルを開く」というDataクラス固有の処理ならばOK。

570 ：デフォルトの名無しさん：2010/03/13(土) 21:30:39

>>569
> open/write/closeにDataクラス固有の処理が追加されるならまだわかるけど。
> でもその場合も必要になった時点で追加すれば良い。

なら単に例のまんまの状態では関数化が要らないっていうだけのあたりまえの話じゃないか。
オブジェクト指向とか持ち出す意味がわからん。

571 ：デフォルトの名無しさん：2010/03/13(土) 21:49:27

うん
全く無駄な固有例を挙げて無駄だろ？って言ってるだけで
オブジェクト指向のオの字すらも関係ないな

固有例であってケースすら示してない

572 ：デフォルトの名無しさん：2010/03/13(土) 21:50:04

>570
>なら単に例のまんまの状態では関数化が要らないっていうだけのあたりまえの話じゃないか。
>オブジェクト指向とか持ち出す意味がわからん。

当たり前の話というのはその通り。ただ、世の中にはそれを当たり前と思わない人達も居て、
541のような実装がまかり通っている。
（実際、今あーいうコードと格闘中。）
なので別の基準としてオブジェクト指向を持ち出してみた。

open/write/closeはその内容を見る限り、Fileに対する操作であって、
Dataに対して行う操作とは違う。
だからオブジェクト指向的にも間違ってる（妥当な実装ではない）、って事で、
これもごく当たり前な事を言ってるつもりなんだが。

573 ：デフォルトの名無しさん：2010/03/13(土) 21:55:55

>>572
だから何でオブジェクト指向を持ち出すんだよ？
単に無駄だってことを説明すれば十分だろ？

そんなコードを書く奴はオブジェクト指向的に正しいかどうかなんてなおさら興味ないよ。

574 ：デフォルトの名無しさん：2010/03/13(土) 21:59:23

追記。無駄/無駄じゃないだと、よりもオブジェクト指向的に妥当じゃないという基準の方が、
>567の違いが説明しやすいと思うんだが。

実際、無駄/無駄じゃないだと>567の後者は良くて前者が駄目だという基準が曖昧で
中々理解を得にくいが、オブジェクト指向的に考えると両者に明確な差が出て来るんで
（ちょっとだけ）納得して貰い易くなる。

575 ：デフォルトの名無しさん：2010/03/13(土) 22:00:51

>>572
お前さ、バカが書いたコードで苦しんでるのは分かったから
そのイラツキをオブジェクト指向に対する意味不明な誤解を広める方向に向けないでくれ
主語がなんだとかprivateに持つべきでは無いだとか、何も関係ないだろ？

576 ：デフォルトの名無しさん：2010/03/13(土) 22:03:44

>>574
> （ちょっとだけ）納得して貰い易くなる。

と勝手に思っていたが、このスレで実はそうはいかないと学習できたわけだ。
まぁがんばれよ。

577 ：デフォルトの名無しさん：2010/03/13(土) 22:09:08

>>574
馬鹿の書いたコードの無駄さと、お前のムカツキを表すためだけに
何十年もかけて多くの人間が懸命に広めてきた共通概念を都合の良い様に捻じ曲げて使うな
どこからどう見ても全然関係ないだろ

578 ：デフォルトの名無しさん：2010/03/13(土) 22:12:22

お前ら、とりあえず AA でクラス図描いて来い。

579 ：デフォルトの名無しさん：2010/03/13(土) 22:12:28

>575
>主語がなんだとかprivateに持つべきでは無いだとか、何も関係ないだろ？

主語が云々は、凄く重要な判定基準だと思うんだが違うのか。
あと「privateに持つべきでは無い」とは言ってない。「privateであっても」だ。
また「持つべきでは無い」であって「持ってはならない」とは違う。
ニュアンスの違いも読み取って欲しい所。

580 ：デフォルトの名無しさん：2010/03/13(土) 22:15:43

>>579が俺定義言語を使っていて、会話不能と言う事もわかった

581 ：デフォルトの名無しさん：2010/03/13(土) 22:20:32

>>579
オレジェクト志向のお話はもうお腹いっぱいです

582 ：545：2010/03/13(土) 22:33:10

>>579
命名と意味のない拡張と、どっちを問題にしたかったんだ？
あるいは両方？

・命名が良くない
継承(is a)とコンポジション(has a)では、元のクラス(インスタンス)のメソッドを拡張するとき
命名の仕方はそれぞれで変えたほうがよい。それはprivateでも一貫させる。主語が大事。

・意味のない拡張がよくない
所有しているインスタンスのメソッドをそのまま呼び出すだけでは意味がない。
publicなら委譲だが、privateでは無意味。

583 ：デフォルトの名無しさん：2010/03/13(土) 22:35:28

>>582
多分この子が言いたいのは後者でしょ。
そして持論を補強したくて無理に前者を持ち出してみたら袋叩きにあったと。

584 ：デフォルトの名無しさん：2010/03/13(土) 22:47:10

>>569
>>557だが、お前さんは「とにかく否定したい病」の患者なのかい？

>Dataクラスが実用レベルまで拡張されると、>>541の例のメンバが十分な正当性を持ち始めるんだがな。
↓
>それはない。
↓
>open/write/closeにDataクラス固有の処理が追加されるならまだわかるけど。

「拡張」の意味を知らないのか？
「持ち始める」のニュアンス(笑)を捉える力が無いのか？
そもそもオブジェクト指向的な概念の話をしているという文脈が理解できていないのか？

>>557のケースをキッパリ否定した次の行で、>>557のケースの存在を認めるって何の意図があったの？

585 ：デフォルトの名無しさん：2010/03/13(土) 22:56:29

>>579
無駄って言いたいのはもう分かってるからさ
お前さんの主張が書かれてるソースをお願い
オブジェクト指向としてうんたらかんたらって言ってるんだから
俺様が今考えたスタイルですってわけじゃないんだろう？

586 ：デフォルトの名無しさん：2010/03/13(土) 23:06:27

なんか笑いが止まらんw

587 ：デフォルトの名無しさん：2010/03/13(土) 23:12:31

>582
後者。「命名が良くない」自体は否定しないけど、こちらの意図とは違う。

>583
「前者」を「オブジェクト指向」に置き換えれば概ね当たり。

単に無意味である以上に、純粋にFile操作するだけの関数が
Dataのメンバであるのは間違いだという主張。
「間違い」は言い過ぎだとしても、オブジェクト指向的に
違和感があると思うんだが。

多少のツッコミは予想していたが、正直>575-577,580-581は
熱くなりすぎじゃないかと思った。
何か気に触る事言った?

588 ：デフォルトの名無しさん：2010/03/13(土) 23:17:14

>>587は単純にprivateが何なのか分かってない

589 ：デフォルトの名無しさん：2010/03/13(土) 23:18:58

>>587
× オブジェクト指向的に違和感がある
○ オレ的に違和感がある

590 ：デフォルトの名無しさん：2010/03/13(土) 23:19:01

>>587
したり顔で大嘘吐いてるのが気に障る

591 ：デフォルトの名無しさん：2010/03/13(土) 23:20:26

>>587
> 「前者」を「オブジェクト指向」に置き換えれば概ね当たり。
だからどうしてそこを置き換えないといけないんだよｗ
わざとやってるのか？

592 ：デフォルトの名無しさん：2010/03/13(土) 23:25:48

>584
>「持ち始める」のニュアンス(笑)を捉える力が無いのか？

拡張が必要なら、拡張する時点で追加すれば良いけど、>541の時点では
追加する必要は全く無いというのがこちらのスタンス。
同じスタンスで言ってるなら>577は同意。
ただ違う事を言ってる可能性もあるんで、ああ書かせて貰った。

593 ：デフォルトの名無しさん：2010/03/13(土) 23:31:35

>591
>582の「前者」は意図してないと断ってるじゃん。
それに>583を↓と置き換えて、こうすれば概ね当たりだと言って何が問題?

　>>582
　多分この子が言いたいのは後者でしょ。
　そして持論を補強したくて無理にオブジェクト指向を持ち出してみたら袋叩きにあったと。

594 ：デフォルトの名無しさん：2010/03/13(土) 23:38:07

>>592
・・・
「拡張」されたら「持ち始める」といってるのに、お前さんが同じ事だと理解出来る為にはこれ以上何の補足が必要なんだ？

595 ：591：2010/03/13(土) 23:40:27

>>593
あぁそういうことか。ごめん。読み違えてた。

596 ：デフォルトの名無しさん：2010/03/13(土) 23:43:47

ニュアンスを汲んで欲しいとか文脈から読み取って欲しいと偉く上から目線で言ってっけど
>>593が一番国語力ありませんがなｗｗ
自分がコミュニケーション能力不足なのを人のせいにせんといてｗｗｗ

597 ：デフォルトの名無しさん：2010/03/13(土) 23:52:43

汲んでほしいとか読み取れるはずとか
人のせいにばかりしてるから
そんなに日本語が不自由なんだ

598 ：デフォルトの名無しさん：2010/03/13(土) 23:56:11

>594
いや、理解したからこれ以上の補足は不要。
こちらの読解力が足りていなかったと言う事で。

拡張すると意味を持ち始めるから、それに備えて実装しておく意味がある、
という主張かと思ってしまっていた。

599 ：デフォルトの名無しさん：2010/03/13(土) 23:59:18

>596-597
日本語不自由なのは認める。
あと上から目線っぽいのは、2chだからってのと、
口調を突然変えるのもどうかと思ったから。
不評のようだから変えます。

600 ：デフォルトの名無しさん：2010/03/14(日) 00:03:50

>>599
オブジェクト指向の下りは全面撤回ということでおｋ？

601 ：デフォルトの名無しさん：2010/03/14(日) 00:10:42

>600
いや、撤回はしません。
至らぬ所があると思うんだったら、ツッコミ入れてくれれば、
納得してくれるまで説明しますよ。
ただし煽りや的外れすぎ等で回答しずらいのはスルーさせて貰います。

602 ：デフォルトの名無しさん：2010/03/14(日) 00:15:47

>>601
貴方の説明は要らないんで、同内容が書かれていた文献を教えてください。

603 ：デフォルトの名無しさん：2010/03/14(日) 00:28:20

>>601の主張内容は理解したけど
オブジェクト指向的に間違っていると言うのには全く持って同意できない

俺ルールじゃないと言うのなら絶対に参照元があるはずだし、それを示せば一発でしょ

604 ：デフォルトの名無しさん：2010/03/14(日) 00:36:51

このスレにオブジェクト指向の開祖が居ると聞いて。

605 ：デフォルトの名無しさん：2010/03/14(日) 00:50:06

「無駄な間」はオブジェクト指向的に間違っていて
「無駄でなくなった」瞬間にオブジェクト指向的に正しくなる
このこじ付けには一切正統性が無く、意味不明です。

606 ：デフォルトの名無しさん：2010/03/14(日) 01:12:11

privateにおいて
そのインターフェースがクラスに相応しいかどうかは
実装に依存する、ということなのか？
オブジェクト指向的に考えて

607 ：デフォルトの名無しさん：2010/03/14(日) 01:16:27

だとしたら噴飯物だよね
オブジェクト指向的に考えて

608 ：デフォルトの名無しさん：2010/03/14(日) 01:28:06

そんな些細な実装に依存してしまったらどうやってクラス図書けばいいのん

609 ：デフォルトの名無しさん：2010/03/14(日) 02:24:13

>602,603
自分なりの解釈に基いて書いているので、コレという「ソース」はありません。
逆にこちらが間違っていると断言できるソースがあるなら示して下さい。

>606,607
「privateであっても」の部分が引っかかるというなら、
まずその部分は取っ払って考えて下さい。
（例えば>541のopen/write/closeは「Data」の操作と言えますか?）

オブジェクト指向的に相応しくないメンバであるなら、
privateであっても極力排除した方が良いと思いますが。
privateなら良しとするべき理由があるならともかく。

610 ：デフォルトの名無しさん：2010/03/14(日) 02:31:41

追記。
privateにすれば無問題というのは、オブジェクト指向プログラミングという
技法的には間違ってないと思うけど、思想的には間違っているはず、
と言った方が伝わるでしょうか。

>605
無駄かどうかとは別の角度、つまりオブジェクト指向的に妥当か否かでも
判断できるよねと言う話であって、両者をこじつけたい訳じゃありません。
こじつけて語ってしまった部分もあるかもしれませんが。

611 ：デフォルトの名無しさん：2010/03/14(日) 02:44:15

>>609
「オブジェクト指向的に間違っている」というのが
たとえば↓ここらへんにある内容のどれに反しているというのか、挙げてみせてくれないか？
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91

> オブジェクト指向的に相応しくないメンバであるなら、
> privateであっても極力排除した方が良いと思いますが。

そうしないと、どんな困ったことが起こるというの？

612 ：デフォルトの名無しさん：2010/03/14(日) 02:45:32

>>609
悪魔の証明を求めないで下さい。
こちらは、そんな寝ぼけた主張をしている文献があるはずが無いと言ってるんです。
なにを言われてるか理解できていますか？補足が必要ですか？

613 ：デフォルトの名無しさん：2010/03/14(日) 03:25:04

>611
>そうしないと、どんな困ったことが起こるというの？

privateならOKとか言い出すと、例えば全ての関数を
1個のクラスにprivateメンバとして詰め込んだ実装も
オブジェクト指向的に間違いじゃないと言えてしまいますが。

privateであっても「そこにあるべきと言えないもの」は極力分離すべき、
というのが原則で、クラスの粒度が過度に小さくなるのを防ぐ、
等の理由があるなら例外として認められる、というのが
オブジェクト指向的に正しい考えかただと思いますが違うんで?

614 ：デフォルトの名無しさん：2010/03/14(日) 03:44:49

粒度の判断も分割すべき次元も人それぞれの裁量に任されるべきで、オブジェクト指向はそこに踏み込みません
本質とは全然関係無い話なんで、勝手にすればいいとされています

>>613はオブジェクト指向を全然理解せず、実装に引きずられ過ぎです
書籍は1冊も読んだ事が無いと容易に伺えます
>>613にはオブジェクト指向を語る資格がありません

615 ：デフォルトの名無しさん：2010/03/14(日) 03:47:33

>>613
611じゃないけど、その例なら個人的にはありだな。
そのクラスでしか使わないものを、そのクラスに閉じ込めておくのは
他で使われる心配をしなくて済んでいいと思うぞ。
その関数を修正するとき、そのクラスだけ意識すればよくなる。
privateのいいところだな。

616 ：デフォルトの名無しさん：2010/03/14(日) 03:48:24

>>613
おまえ隠蔽の意味が全然分かってないだけ。

>privateならOKとか言い出すと、例えば全ての関数を
>1個のクラスにprivateメンバとして詰め込んだ実装も
>オブジェクト指向的に間違いじゃないと言えてしまいますが。

実装としてどうなんだ？と言う話で、オブジェクト指向的にはどこにも間違いが見当たらない。

617 ：デフォルトの名無しさん：2010/03/14(日) 04:03:09

>>613は、ただの実装の善し悪しとオブジェクト指向の正誤を取り違えちゃってる子

618 ：デフォルトの名無しさん：2010/03/14(日) 04:11:30

>>613
> オブジェクト指向的に間違いじゃないと言えてしまいますが。
あぁそうだ。そしてそう言えるとしても誰も困らない。

１個のクラスにすべて詰め込んだ実装はいろいろとマズイわけだが、
それはオブジェクト指向とは関係なく説明できる。

> オブジェクト指向的に正しい考えかただと思いますが違うんで?
何を聞いても最終的にオブジェクト指向（しかも脳内）しか出てこない
のもおかしい。その先にある具体的な利点や解決される問題点を示す
ことができないのなら、そんなオブジェクト指向には何の意味も無い。

619 ：デフォルトの名無しさん：2010/03/14(日) 04:17:46

>>618
だよなｗ
何を聞いても最終的には「俺の中のオブジェクト指向ではそれは正しくない」で話が終わってしまうｗ

620 ：615：2010/03/14(日) 04:31:48

すまん、どうやら読み間違えたようだ。
全てのってそのクラスしか無い状態か。
いままでprivateの外にいた奴らは、追い出せばいいんじゃないか？
・・・また読み間違えてる気がする。

621 ：デフォルトの名無しさん：2010/03/14(日) 05:12:42

ここまで長々やって一人も賛同者が居ないと言うのに、自分を疑うと言う事を知らないのか？

622 ：デフォルトの名無しさん：2010/03/14(日) 06:53:58

80年代ならまだしも、2010年にもなって>>613みたいな、勘違いを公衆に発信してる奴を見るとなんか虚しくなるな･･･
言ってしまえばオブジェクト指向の要点なんて情報のカプセル化しか無いだろうに、何でこんな酷い勘違いが出来るんだか･･･
なんというか、数の数え方も知らずに数学について語ってるみたいな奴･･･

623 ：デフォルトの名無しさん：2010/03/14(日) 08:43:20

まあオブジェクト指向がらみにはこういう変な理解しちゃった子結構いるからなぁ。
ちょっと前まではそういう人たちは XP に移ってたけど、今はどこで何してるんだろう？

624 ：デフォルトの名無しさん：2010/03/14(日) 08:50:54

これ思い出した。
モスバーガーのきれいな食い方教えれ
http://guideline.livedoor.biz/archives/50970830.html

625 ：デフォルトの名無しさん：2010/03/14(日) 09:19:15

>622
「カプセル化」のとはprotected/private化するだけじゃなくて、
クラスとして抽出して外部に追い出す事も含まれると思いますが。
（クラス化自体カプセル化の一種であるというのは、何かで読んだ気がするので探してみます）

でもって>541みたいに必要も無いのに他のクラスのメソッドを引き込むのは、
隠蔽レベルを下げる行為だと見なせますよね?

626 ：デフォルトの名無しさん：2010/03/14(日) 10:19:33

>>クラスとして抽出して外部に追い出す事も含まれると思いますが。
一切微塵も欠片も小指の先ほども含まれて居ない。
「クラスの抽出をする事をカプセル化と言う」などと解説している物があるなら提示を。

>>隠蔽レベルを下げる行為だと見なせますよね?
Dataを外から見た場合、open write closeは完全に隠蔽されている。
というか、privateなのに一体どこで何が下っているのか、想像も付かない。

そして、全く同じシグネチャでも、必要性があれば隠蔽レベルを下げているとは言わず
必要性が無い時だけ隠蔽レベルが下るという主張も意味不明。
全く同じコードでも、閲覧者の主観によって隠蔽レベルが変わるというなら、コンパイラは一体何をすればいいのか。

隠蔽について、まともな本を読み勉強しなおせ。

627 ：デフォルトの名無しさん：2010/03/14(日) 10:30:06

ttp://e-words.jp/w/E382ABE38397E382BBE383ABE58C96.html
カプセル化とは、オブジェクト指向プログラミングが持つ特徴の一つ。
データとそれを操作する手続きを一体化して「オブジェクト」として定義し、
オブジェクト内の細かい仕様や構造を外部から隠蔽すること。

c++で言うなら、データと手続きをクラスとして抽出し、
細かい仕様や構造をprivate等のアクセス修飾子を使って隠蔽する事が
カプセル化。
隠蔽というのは、あくまでカプセル化の一部。（カプセル化⊃隠蔽）

628 ：デフォルトの名無しさん：2010/03/14(日) 10:31:48

>627を踏まえて>625を訂正。

でもって>541みたいに必要も無いのに他のクラスのメソッドを引き込むのは、
カプセル化のレベルを下げる行為だと見なせますよね?

629 ：デフォルトの名無しさん：2010/03/14(日) 10:35:41

C++の薄汚れた擬似オブジェクト指向はあんま好きじゃないな
Smalltalkとは言わないからせめてJavaレベルで話して欲しい

630 ：デフォルトの名無しさん：2010/03/14(日) 10:38:02

>>628
使用者はDataのSaveToFileを呼び出すだけで良い事は変わらないのでカプセル化は保たれています。
Dataの中がどうなっていようが関係ありません。
関係ないからカプセル化です。

631 ：デフォルトの名無しさん：2010/03/14(日) 10:41:20

>>613=>>625=>>627=>>628？
613でも何でもいいから名前固定してくれ
つかれる

632 ：613=625=627=628：2010/03/14(日) 10:52:08

>630
Dataのヘッダに、Fileの実装やDataがどの関数を使用しているかという
振る舞いが一部見えてます。
（コンパイラは見て見ぬフリをしますが）
open/write/closeを追い出せば、カプセル化はより完璧になります。

633 ：デフォルトの名無しさん：2010/03/14(日) 10:55:14

「それ」に「オブジェクト」を認め、「カプセル化」するとした時に
「カプセル化」の手段として「クラス」があり「隠蔽」がある。

「カプセル化」され、「隠蔽」されているなら、どのような「実装」だろうと関係ない。
ましてや「実装」により「隠蔽」や「カプセル化」が脅かされる事は、絶対に無い。
絶対に、無い。

634 ：デフォルトの名無しさん：2010/03/14(日) 10:56:42

>>632
オブジェクト指向にヘッダなんて概念は存在しません。
そろそろ死んでください。

635 ：デフォルトの名無しさん：2010/03/14(日) 11:02:42

ここまでで唯一分かった事

613はC++の言語仕様の事をオブジェクト指向と呼んでいる

　　　　　　　　　　　　　　　- 完 -

636 ：632 ◆79cfdX7bxM ：2010/03/14(日) 11:10:55

Dataクラスの利用者から見て、Fileは以前隠蔽されたままだと言いたいのはわかります。
でも「抽出・分離」して隠蔽することを「カプセル化」と言うのだから、
Fileクラスとして抽出・分離されているものを、Dataクラスに必要以上に
結合するのはカプセル化を逆行してるでしょうに。

637 ：デフォルトの名無しさん：2010/03/14(日) 11:26:55

DataクラスとFileクラスはDataクラスにprivateメソッドを作ろうが作るまいがデータ結合です。
結合度は変わりません。オブジェクト指向として理想的です。

>Fileクラスとして抽出・分離されているものを、Dataクラスに必要以上に
>結合するのはカプセル化を逆行してるでしょうに。
意味不明のオレ概念です。使用を控えてください。

そしていい加減死になさい。

638 ：デフォルトの名無しさん：2010/03/14(日) 11:38:49

>>でも「抽出・分離」して隠蔽することを「カプセル化」と言うのだから、
だから違うと何度も言ってるだろう。
「カプセル化」とは「オブジェクト」を具現化する事であり、抽出も分離も隠蔽もその手段でしかない。
そこまで致命的にトップダウンな思考が出来ないのなら、一生オブジェクト指向を理解することは無い。

639 ：デフォルトの名無しさん：2010/03/14(日) 12:04:13

>>627
お前はe-wordsをチョロっと読んだだけで、浸透まで何十年もかかったパラダイムを理解した気になっている･･･のか･･･？
失笑と言うか････脱力感が･･･ヤバイ･･･

640 ：デフォルトの名無しさん：2010/03/14(日) 12:39:26

何を聞いても最終的にカプセル化（しかも脳内）しか出てこない
のもおかしい。その先にある具体的な利点や解決される問題点を示す
ことができないのなら、そんなカプセル化には何の意味も無い。

641 ：デフォルトの名無しさん：2010/03/14(日) 12:39:36

e-wordsで200文字読むだけで今日から君も立派なOOPerだ！やったね！

642 ：デフォルトの名無しさん：2010/03/14(日) 12:45:45

>>640=632?
やっと後釣り宣言出たって感じ？

643 ： ◆79cfdX7bxM ：2010/03/14(日) 18:06:48

>640
Data内で使用しているFileのメンバのシグネチャを変えても
Dataに一切影響がないようにするには、>541のような隠蔽だけでは
不十分です。
例えばopen に引数が追加されたら、Data::openも変更が必要です。
一方、Fileの派生クラスまたはラッパークラスを用意し、そちらに定義しておけば
シグネチャ変更の余波は、Dataに到達する前に止められます。

　例：
　class DataFile : public File { /*省略*/ };
　class Data {
　　public: void SaveToFile(){
　　　m_pFile->open();
　　　m_pFile->write();
　　　m_pFile->close();
　　}
　　private: DataFile* m_pFile;
　};

このように、「別クラスに抽出」して「隠蔽」する事をカプセル化と言うのであり、
単に隠蔽するだけをカプセル化と言うのじゃありません。
多くの解説書でアクセス制御=カプセル化として説明してますから
誤解するのも無理は無いと思いますがね。

644 ：デフォルトの名無しさん：2010/03/14(日) 19:05:26

>>643
> 例えばopen に引数が追加されたら、Data::openも変更が必要です。
> 一方、Fileの派生クラスまたはラッパークラスを用意し、そちらに定義しておけば
> シグネチャ変更の余波は、Dataに到達する前に止められます。

わざわざ作った「Fileの派生クラスまたはラッパークラス」には変更が及ぶんだろ。
そこに変更が及ばないようにまた何かラッパークラスでも作るの？
それで誰が喜ぶんだよｗ

645 ：デフォルトの名無しさん：2010/03/14(日) 19:27:22

>>643
Fileのパブリックメンバのシグネチャ変えたら使用側全てに変更が及ぶなんて当たり前すぎて何が言いたいのかわからない。
それにData::openの実装の修正は必要だがシグネチャの変更は不要。
お前はなぜ何故実装とシグネチャの区別が付かない。

そうやって無限ラップ地獄の明らかに破綻した論理を大事に墓まで抱えていけば。

646 ：デフォルトの名無しさん：2010/03/14(日) 19:30:50

パブリックなシグニチャの変更を極力抑えるのが隠蔽でもあるんだけど愚かだねー

647 ：デフォルトの名無しさん：2010/03/14(日) 19:39:48

>>643　こいつは主語が分かってない
DataクラスがDataクラスに対して隠蔽してどうすんだ
馬鹿すぎる

648 ：デフォルトの名無しさん：2010/03/14(日) 19:58:09

ここまでの論理破綻は中々お目にかかれないでござるの巻

649 ：デフォルトの名無しさん：2010/03/14(日) 20:36:42

>>643
Fileのpublicメンバを変更したらそれはFileのカプセル化が漏れたことになります。
その公開されたメンバを使用している箇所でも修正が必要です。

DataはFileを使用しているため実装に変更が必要になります。
それはFileのカプセル化が漏れたためであり、悪いのはFileです。
publicメンバを変更したFileが悪いのです。Dataは被害者です。

DataFileクラスを新しく作る必要があるのはFileのカプセル化の漏れを
新しいカプセルで覆う必要があるからです。
DataFileのカプセル化に成功した場合は、Dataの実装を変更する必要は無くなります。
541のコードのままでも変更は必要なくなります。
なぜならそれがDataFileのカプセル化の効果だからです。
DataFileがFileからの被害を受け止めることで、Dataが救われました。
DataFileは救われませんが。

650 ：デフォルトの名無しさん：2010/03/14(日) 21:01:47

>>643の主張はDataをDataFileに置き換えても再帰的に成り立つ
なぜなら、DataFileも本来関係ないはずのFileの変更に影響されるべき物ではないからだ。

651 ：デフォルトの名無しさん：2010/03/14(日) 21:06:35

あ、一応言っとくけど>>650は>>643が明らかに破綻してる事の証明だからね。

652 ：デフォルトの名無しさん：2010/03/14(日) 21:16:03

コイツがここまで不勉強な奴だったとは･･･
>>541みたいなコードを書いたという元コーダの正当性も再評価する必要があるな。
全うにコーディングしてたら馬鹿に絡まれ馬鹿に馬鹿と晒し上げられた、ただの被害者の可能性がある。

653 ： ◆79cfdX7bxM ：2010/03/14(日) 22:37:18

ここまで馬鹿ばかりだとは…
そもそも Data::open を作る意義が何なのか分かってますか? >全員

654 ：デフォルトの名無しさん：2010/03/14(日) 22:41:47

さぁやーっとオチがつくぞー

655 ：デフォルトの名無しさん：2010/03/14(日) 22:42:51

Data の取得方法ってファイルだけなのか？

656 ：デフォルトの名無しさん：2010/03/14(日) 23:00:57

>>653
わからないし、そこを明らかにしないと作成の是非なんか話にならないはずなのに、
「オブジェクト指向的に間違ってる」だの「カプセル化が不完全」だの抽象的な
概念（しかも脳内）を具体的な問題点と繋げないまま繰り返し言うだけで、それで
納得しなかったら馬鹿よばわりとか、どんだけ

657 ：デフォルトの名無しさん：2010/03/14(日) 23:03:52

平和だなぁ

658 ：デフォルトの名無しさん：2010/03/14(日) 23:06:37

>>653
>>541のケース「限定」で「Data::openは無駄だ」という当初の主張から翻り、今度は作る意義ですか。

さっぱり分かりませんが、作る意義って何の事を言ってるんですか？

個人的に作る意義は沢山存在しますが。貴方の言ってる事は本当に意味不明です。

659 ：デフォルトの名無しさん：2010/03/14(日) 23:34:51

関数つくる意義なんてたいてい抽象化じゃないのか？
オブジェクト指向でも構造化プログラミングでも。

660 ：デフォルトの名無しさん：2010/03/14(日) 23:47:17

ほんと笑いがとまらんwwww

661 ： ◆79cfdX7bxM ：2010/03/15(月) 01:14:06

>659
その通り。抽象化です。(カプセル化、あるいは隠蔽化でも良いと思いますが)
では次。
①抽象化のメリットは何ですか?
②Data::open は何に対して、何を抽象化してますか?

662 ：デフォルトの名無しさん：2010/03/15(月) 01:19:47

　　　　　　　　 ,. -‐'''''""¨¨¨ヽ
　　　　　　 (.＿＿_,,,... -ｧァﾌ|　　　　　　　　　　あ…ありのまま今　起こった事を話すぜ！
　　　　　 |i i|　　 }!　}} /／|
　　　　　　 |l､{　　j}　/,,ｨ//｜　　　　　　　『おれは奴に具体的な問題点を聞いていた
　　　　　　　 i|:!ヾ､_ﾉ／ u {:}//ﾍ　　　　　　　　思ったらいつのまにか聞かれていた』
　　　　　　　 |ﾘ u' }　 ,ﾉ　_,!V,ﾊ |
　　　　／´fト､_{ﾙ{,ィ'ｅﾗ　, ﾀ人　　　　　　　　な…　何を言ってるのか　わからねーと思うが
　　　　 /' 　ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ　　　　　　　　おれも何をされたのかわからなかった…
　　　　,ﾞ　／ )ヽ iLﾚ　u' |　| ヾｌﾄﾊ〉
　　　 |／_／　ﾊ !ニ⊇　'／:} 　V:::::ヽ　　　　　　　　頭がどうにかなりそうだった…
　　　 /／二二二7'T'' ／u'　__ /:::::::/｀ヽ
　　　/'´r　-―一ｧ‐ﾞＴ´　'"´ ／::::／-‐ 　＼　　　　催眠術だとか超スピードだとか
　　 / // 　广¨´ 　/'　　／:::::／´￣｀ヽ ⌒ヽ　　　　そんなチャチなもんじゃあ　断じてねえ
　　ﾉ ' /　ノ:::::`ー-､___／:::::／/ 　　　ヽ　　}
_／｀丶　/::::::::::::::::::::::::::￣`ー-{:::...　　　　　　ｲ　もっと恐ろしいものの片鱗を味わったぜ…

663 ：デフォルトの名無しさん：2010/03/15(月) 01:26:18

>>661の言ってる事がさっぱりわからない
オブジェクト指向とか本読むのめんどくせえから1から俺に教えてくれって事？

664 ：デフォルトの名無しさん：2010/03/15(月) 01:27:48

とりあえず◆79cfdX7bxMにはキチガイ認定を

665 ： ◆79cfdX7bxM ：2010/03/15(月) 01:33:32

こっちの方が考え方としては分かり易いか。

ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060607/240196/
>役割とは，「オブジェクトが果たすべき機能」のことで，オブジェクト指向では
>「責務（Responsibility）」と呼ぶ。通常はクラスにメソッドを実装することで，責務を実現する。
>
>オブジェクトに最適な役割を割り当てることは，
>「適切なクラスに適切な責務を配置する」ことに他ならない。

ファイルのopen/write/closeという責務は Fileが負ってくれているのだから、
Dataまで担う必要ありません。

666 ： ◆79cfdX7bxM ：2010/03/15(月) 01:43:16

これもどうぞ。

Single Responsibility Principle (SRP) - 単一責任原則
ttp://syboos.jp/sysdesign/doc/20080608013448257.html

クラスの責務（役割）は一つでなければならない。

667 ：デフォルトの名無しさん：2010/03/15(月) 01:59:02

↓以下、Dataが担っているのはDataのopen/write/closeだといい始めるループ

668 ：デフォルトの名無しさん：2010/03/15(月) 02:05:39

>>665
オレジェクト指向の宣教活動は自重してください
スレ違いですし、単純に迷惑です

669 ： ◆79cfdX7bxM ：2010/03/15(月) 02:05:46

>667
その先は付きあい切れません。
ではおやすみ。

670 ： ◆79cfdX7bxM ：2010/03/15(月) 02:07:32

>668
ここまで物分りが悪い奴ばかりと思ってませんでした。
（もしかして釣られたのか。）
では今度こそおやすみ。

671 ：デフォルトの名無しさん：2010/03/15(月) 02:09:21

privateで言うのもおかしいが、DataはそのままFileに委譲してるのにFileの責務を負ってるらしい
自己都合によって捻じ曲げるとこんな醜態を晒すという例

672 ：デフォルトの名無しさん：2010/03/15(月) 02:10:14

>>669
寝る前にどこ立て読みかネタばらし頼む
俺もスッキリ寝たい。

673 ：デフォルトの名無しさん：2010/03/15(月) 02:12:34

>>670
馬鹿は絶対に自らの間違いを認めない特性を持つが故に、馬鹿は死んでも直らないと言われる。
俺がこれをどちらに向けて言ってるかは、お前が決めれば良い。

674 ：デフォルトの名無しさん：2010/03/15(月) 02:56:15

典型的な救いようの無いタイプの馬鹿でワロタ

675 ：デフォルトの名無しさん：2010/03/15(月) 03:10:03

なんとなく言いたい事が分かってきたかもしれん。
DataとFileが密結合になるのが嫌なのだと思う。

まずDataの中にFileをコンポジションで所有するのが、気に入らない。
DataにFileの特性が入り込んでしまう。継承よりは疎結合だし、必要なので我慢する。
だがDataからFileのメンバを使うのは、それだけ結合が増えるので嫌だ。なるべく避けよう。
でもSaveToFile関数でopen/write/closeの３個を使うのは、避けられないから我慢する。
だがopen/write/closeを分けて委譲するのは、同じ３個でも３カ所に分かれるのは結合が強まる。
それに委譲を作るのも、まるでオーバーライドのようで結合が強まっているようだし、そもそもDataの特性に合わない。
SaveToFile関数のローカル内だけで済んでいた結合がDataクラス全体に拡散してしまうなんて悪夢だ。

という考え方なんだと推測したがどうだろう？

676 ：デフォルトの名無しさん：2010/03/15(月) 04:46:39

>>675
多分そうなんだろうねー
でもそれらのどこでも結合は強まってないんだけどねー
Data内部でopen/write/closeに分けた方が抽象化の度合いが高まって、より疎になってるんだけどねー

677 ：デフォルトの名無しさん：2010/03/15(月) 06:24:49

Dataはopenする物ではないという決め付けにまず驚愕

678 ：デフォルトの名無しさん：2010/03/15(月) 07:18:17

そしてこんだけ延々とスレチを続けるあたりがもうね。

679 ： ◆79cfdX7bxM ：2010/03/15(月) 08:52:46

あーあー、見苦しいなw

>671
>665
>通常はクラスにメソッドを実装することで，責務を実現する。
つまりopen/write/closeを追加する事自体、責務を増やしている。
m_pFile を持てば十分なのだから増やす必要は無い。

>673,674
お前らにそっくりそのまま返すw

>676
open/write/closeを抽象化したところで、m_pFileを通してFileが丸見えだから
抽象化の度合いは全く高まっていないし、「より疎」にもなっていない。
むしろ675の言う通り無駄な経路を増やしてる。

そもそもopen/write/closeを拡張する場合、Fileを派生するかラッパー作って拡張し
m_pFile の型を変えれば良いのだから、open/write/closeを作らなくても
十分抽象化されてて疎の状態。

>677
「Dataをopen」を意味する関数であれば、privateにはしないでしょうに。

>678
超ド素人でも感覚で理解してるような原則を延々説明しなきゃならんとか、
こっちも想定外だってw

680 ：デフォルトの名無しさん：2010/03/15(月) 09:38:42

>>679
> 通常はクラスにメソッドを実装することで，責務を実現する。
↓
> つまりopen/write/closeを追加する事自体、責務を増やしている。

private に open/write/close を追加したことで増えた Data クラスの責務って何よ？

681 ：デフォルトの名無しさん：2010/03/15(月) 10:29:35

>>679
その Data クラスにありそうな拡張って例えば、
・最後に保存してから変更があったかどうかのフラグの処理
・ロギング
のようなものが考えられると思うが、両方とも欲しい場合には
FileWithLoggingAndModificationFlag みたいな派生クラス
を作れって言ってるの？

682 ：551：2010/03/15(月) 10:45:15

出遅れ感ありありだが……

>>569
> 541の例は単純に↓がベストであると考えている。
> open/write/closeをラップしたいなら、Fileをラップするクラスを作り、File*を置換する。
> 　class Data {
> 　　public: void SaveToFile() {
> 　　　//省略
> 　　};
> 　　private:
> 　　　File* m_pconfigfile;
> 　};
完全な例を書いてくれないかな。それ>>551と何が違うの？
あ、ちなみに>>551は一部書き損なってたとこがあった。
> class DerrivedFile {
↓
> class DerrivedFile : public File {

>>579
> あと「privateに持つべきでは無い」とは言ってない。「privateであっても」だ。

他の奴はどうか知らないが、俺がこだわってるのはこれ。
public/protectedならともかく、privateに>>541のようなメソッドがあることが
なぜオブジェクト指向的に間違っているかだ。

> ニュアンスの違いも読み取って欲しい所。
いやいや、お前がニュアンスを文章として的確に表現しろよ。

683 ：デフォルトの名無しさん：2010/03/15(月) 11:16:48

>>679
> m_pFile を持てば十分なのだから増やす必要は無い。

オブジェクト指向的というなら、そもそもclass Dataにm_pFileを持たせること自体がどうかと思う。
Dataには、自分自身を表現するメソッド、例えばtoString()とかイテレータを実装しておき、
永続化を担当するクラスの方に、Dataを渡す方がいいんじゃないか？

684 ：デフォルトの名無しさん：2010/03/15(月) 13:14:00

その先は付きあい切れません。
↓
あーあー、見苦しいなw

わろた

685 ：デフォルトの名無しさん：2010/03/15(月) 14:13:48

>>683
シーッ！
ペラい経験と先入観で気持ち良さそうに語っちゃってる痛い子にそんな事言っても理解不能です

686 ：デフォルトの名無しさん：2010/03/15(月) 14:34:39

>>682
>public/protectedならともかく、privateに>>541のようなメソッドがあることが
>なぜオブジェクト指向的に間違っているかだ。
ヘッダを読むと見えちゃうかららしいｗ
そこで爆笑したｗ

687 ：デフォルトの名無しさん：2010/03/15(月) 15:45:43

ヘッダを読むとは何の話ですか。
オブジェクト指向で言うと、どの行為に当たりますか。

688 ：デフォルトの名無しさん：2010/03/15(月) 15:50:26

>>682
俺も思ったけど一番肝心な所が//省略されてて意味不明だった
何が話されてるのかさっぱり分かってないただの馬鹿と判断してスルーしたけど

689 ：デフォルトの名無しさん：2010/03/15(月) 15:55:44

>>679
>m_pFileを通してFileが丸見えだから
イミフミエ

690 ：デフォルトの名無しさん：2010/03/15(月) 18:07:58

そもそも>>541にm_pFileというメンバは存在しないところから謎は始まった。

691 ： ◆79cfdX7bxM ：2010/03/15(月) 20:01:16

>680
例えばopen等のメンテの度に、Data全体をコンパイルし直さなければならないというコストです。

>681
うんにゃ。拡張したopen関数が、Dataに負わせるに相応しい債務であれば
Dataに入れても良いと思います。
ちなみに何の拡張もされていないopenを追加する目的は、「openの拡張に備えて」だろうけど
「必要に成った時点で追加」と言う方針で困るケースなど無いから、杞憂というものです。

>682,668
>551と>569の違いは、Dataがopen等を実装しているか否かです。
>569のSaveToFileの中身は↓です。
SaveToFile() {
　m_pFile->open();
　m_pFile->write();
　m_pFile->close();
}

>683
そうですね。
まぁダメな例をちょっと改善したに過ぎないので、ツッコミ処はいくらでもあるかと思います。

>684
その先って>667の無限ループの事ですよ?

>687,689,690
細かい事は気にせず書いてるから、多少おかしな部分はあるかもしれません。
ツッコミたければ好きなだけどうぞ。全部甘んじて受けておきますよ。
以降は、些細なミスについては一々弁解・謝罪するつもりは無いのでよろしくお願いしますね。

692 ：デフォルトの名無しさん：2010/03/15(月) 20:48:21

>>691
> 例えばopen等のメンテの度に、Data全体をコンパイルし直さなければならないというコストです。

そのメンテの度にコンパイルし直さなければならないという発生するコストは、
SaveToFile() の中で全部やってなかったら発生しなかったというのかね？

693 ：692：2010/03/15(月) 20:50:52

ごめん書き直す。

>>691
> 例えばopen等のメンテの度に、Data全体をコンパイルし直さなければならないというコストです。

聞いたのはクラス Data の「責務」なんだけど、なんでコストの話になったの？

コストの話にしてもおかしいよね。
そのメンテの度にコンパイルし直さなければならないというコストは、
SaveToFile() の中で全部やっていれば発生しなかったというのかね？

694 ：デフォルトの名無しさん：2010/03/15(月) 21:06:10

いいかげんスレタイ読み直せ

695 ： ◆79cfdX7bxM ：2010/03/15(月) 21:28:22

>692,693
「コスト」という表現が分かりにくいなら、open等のメンテの度にDataも影響を
受けざるを得ない、要はopenと一連托生になる、ではどうでしょうか。
（話が逸れますが、openとDataはm_pFileを共有する、共有結合だって事も分かりますか?）

>SaveToFile() の中で全部やってなかったら発生しなかったというのかね？
File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
まぁ open等を作った場合も同じ方法で発生を抑えられますが。
けどそれやったら、丁度>551のような状態になります。
Data内のopen等が無用の長物と化しますね。

オブジェクト指向で考えても、結局行きつく結論は「無駄」でしたね。
皆様お疲れ様でしたw

696 ：デフォルトの名無しさん：2010/03/15(月) 22:11:15

おまえらIDの出ない板でよく集中力もつなｗ

697 ：デフォルトの名無しさん：2010/03/15(月) 22:42:20

最後に書いた人の勝ちルールでやってるからっしょ。

698 ：デフォルトの名無しさん：2010/03/16(火) 00:17:07

>>（話が逸れますが、openとDataはm_pFileを共有する、共有結合だって事も分かりますか?）
天変地異級の大勘違いです。

一体今までの話のどこにグローバル領域が存在したというのか。

そもそも、クラスと、そのクラス自身のメソッド間で結合度？
どこまで馬鹿なんですか？
結合度とは、オブジェクト(クラス)間の関連を語るものです。

699 ：デフォルトの名無しさん：2010/03/16(火) 00:27:48

>File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
File* を外部から渡しても無意味だと思うのですが、実際にDataをコンパイルしなおす必要がない設計をしてもらえますか。
何を想定してるのかさっぱり想像がつかないので
とりあえずFileのopenが廃止され、open_streamのみになったケースに対応してください。

700 ：551：2010/03/16(火) 00:48:38

>>691
> >569のSaveToFileの中身は↓です。
> SaveToFile() {
> 　m_pFile->open();
> 　m_pFile->write();
> 　m_pFile->close();
> }
え？これが理想型なの？
これだとclass Dataとclass Fileの結合度は全く変わってないよね？

それから「責務」とか「openを実装する」とかの話になっているけど、もともとprivateメソッドの話だよ？
m_pFile->open()をprivateメソッドに括りだしたら、責務が増えたという認識？
俺的には、「Dataにopenを実装する」と言えば、それは大抵publicの話であって、百歩譲っても
protectedの話。

やっぱり「一行しかない処理をprivateメソッドに括り出すのって無駄なたらい回しだよね」以上の
オブジェクト指向的な何かが関係してるとは読めないよ。

701 ：551：2010/03/16(火) 00:51:12

>>695
> File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
の完全な実コードをお願い。

> まぁ open等を作った場合も同じ方法で発生を抑えられますが。
の完全な実コードをお願い。

> けどそれやったら、丁度>551のような状態になります。
> Data内のopen等が無用の長物と化しますね。
この二行の意味がわからないので。

702 ：デフォルトの名無しさん：2010/03/16(火) 00:53:17

ふつうは
File->Save(Data); じゃないの？

703 ：デフォルトの名無しさん：2010/03/16(火) 01:03:24

>>691
念のため言っておきますが、あなたが突っ込まれてる箇所はオブジェクト指向の基本中の基本で、
非常に致命的でお話にならない勘違いをしている所ばかりです

度合い的に言うと、÷記号って両辺の数字を足せばいいんだよね？レベルです
（しかもあなたは、÷記号は両辺を足すという意味なのを理解してないの？お前ら馬鹿じゃないの？と言うスタンスで語っています）

細かい所なんて誰も突っ込んでません
突っ込みきれる量じゃないからです

704 ：デフォルトの名無しさん：2010/03/16(火) 02:05:22

すげーな

◆79cfdX7bxMが書いてる事でオブジェクト指向的に正しいことが本当に一つも無い

細かい事気にしてないとか　そんなチャチなもんじゃあ　断じてねえ

705 ：デフォルトの名無しさん：2010/03/16(火) 03:15:28

>>695のプログラマ歴って業務で何年なの？
俺5年なんだけど(お陰で周りは正しいOOPに満ちていた)>>695の言ってる事がちっともわからん。
「無駄」から話が始まったはずなのに「結局行きつく結論は「無駄」でしたね。」とか再発見されても、困惑する。
一体どこを目指していたの？

706 ：デフォルトの名無しさん：2010/03/16(火) 03:31:38

一番最初に分からない部分。

> 「コスト」という表現が分かりにくいなら、open等のメンテの度にDataも影響を
> 受けざるを得ない、要はopenと一連托生になる、ではどうでしょうか。
> （話が逸れますが、openとDataはm_pFileを共有する、共有結合だって事も分かりますか?）

openはDataのopen?Fileのopen?

1. Dataのopenの場合。
Data::openのメンテをする場合Dataが影響を受けるのは当たり前。
よってDataが主語に来ることは在り得ない。

2. Fileのopenの場合。
File::openのシグニチャに変更が無い場合はDataが影響を受けないのは当たり前。
File::openのシグニチャに変更があった場合は、どんな形であろうと、呼び出しているDataが影響を受けるのは当たり前。
そして併せて↓が成立しない。
> (File::)openとDataはm_pFileを共有する
よってFileが主語に来ることは在り得ない。

∴どちらを主語にしても成立しない。

707 ：デフォルトの名無しさん：2010/03/16(火) 03:40:19

次に分からない部分。

> File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
> まぁ open等を作った場合も同じ方法で発生を抑えられますが。
↓
> けどそれやったら、丁度>551のような状態になります。
↓
>Data内のopen等が無用の長物と化しますね。

話が繋がってない。
重要な言葉を略しすぎで、人に伝える能力が無い。

708 ：デフォルトの名無しさん：2010/03/16(火) 04:24:23

>m_pFileを通してFileが丸見えだから
指摘したのに細かいとか一蹴されててワロス
Fileの公開メソッドへアクセス可能なことを丸見えといってるのか、
DataのprivateメンバにFileのインスタンスが存在する事をもって丸見えと言ってるのか
どちらにしろ超絶馬鹿
イミフミエ

709 ：デフォルトの名無しさん：2010/03/16(火) 10:09:00

さらしage

710 ：デフォルトの名無しさん：2010/03/16(火) 10:12:41

ちゃんと「ごめんなさい」が言える子に育ててもらえなかったんだね。かわいそうに。

711 ：デフォルトの名無しさん：2010/03/16(火) 12:56:00

>>627
> データとそれを操作する手続きを一体化して「オブジェクト」として定義し、
> オブジェクト内の細かい仕様や構造を外部から隠蔽すること。
その通り。

>>628
> でもって>541みたいに必要も無いのに他のクラスのメソッドを引き込むのは、
> カプセル化のレベルを下げる行為だと見なせますよね?
見なせない。外部からは何も変わっていない。

>>636
> でも「抽出・分離」して隠蔽することを「カプセル化」と言うのだから、
微妙に言い回しを変えてるが、>>627にあるとおり「外部から隠蔽する」というのが
カプセル化の定義。

> Fileクラスとして抽出・分離されているものを、Dataクラスに必要以上に
> 結合するのはカプセル化を逆行してるでしょうに。
何が「必要以上」なのかさっぱり分からんが、privateメソッドを作ろうが作るまいが、
DataとFileの結合度には何の影響も与えない。

そもそもあるクラスがあるクラスを使う（use関係）というのは、カプセル化とは
何の関連もない。
さらには、あるクラスがあるクラスを使うと決定した時点で、結合するのは逃れられない。
ちなみに、その結合を逃れる手段は>>683。

712 ：デフォルトの名無しさん：2010/03/16(火) 13:00:15

さて、class Dataがclass Fileを直接使用するとFileの変更がDataに波及するのだから、
class FileWrapperを作るのが正しいという主張だが、これは誰かに使用されうるクラス
全てについて言えることだ。

class Dataがclass A, B, Cを使用するなら、AWrapper, BWrapper, CWrapperを作れと
言っているに等しい。

さらに言えば、class Data自身も誰かに使用されることが目的のクラスなのだから、
class DataWrapperが必要になるということだ。

つまり、100個のクラスを作るなら、100個のWrapperクラスを作るべきと主張している。

Wrapperクラスが有用な場合はもちろんあるが、これが壮大なたらい回しクラスの
固まりだと誰かに言われたらなんと反論するのだろうか。

713 ：デフォルトの名無しさん：2010/03/16(火) 13:15:46

>>712
クラスの「ニュアンス」を読み取って、コーダの主観だけを根拠に、ラッパーの必要の無いところは外してほしい(ｷﾘｯ

714 ：デフォルトの名無しさん：2010/03/16(火) 13:22:18

>>530の最後の一文からコイツクッセエエエと思ってたが、やはりキチガイさんでしたな

自分の話が相手に伝わらない原因を相手に求めだす奴にまともな奴は一人も居ない

715 ：デフォルトの名無しさん：2010/03/16(火) 13:24:31

リファクタリングを知らないのかな。
リファクタリングだと、一行だけprivateメソッドに抽出するなんて普通すぎて、誰も疑問に思わないんだけど。

716 ：デフォルトの名無しさん：2010/03/16(火) 13:26:39

おっとインドリさんの悪口はそこまでだ。

717 ：デフォルトの名無しさん：2010/03/16(火) 13:28:47

ここで爆笑した。

>>670
> ここまで物分りが悪い奴ばかりと思ってませんでした。
> （もしかして釣られたのか。）

確かに爆釣成功だけどな。

718 ：デフォルトの名無しさん：2010/03/16(火) 13:35:11

ごめんなさい出来ない子とは遊ぶなってばっちゃが言ってた
ばっちゃありがとう

719 ：デフォルトの名無しさん：2010/03/16(火) 13:41:56

インドリでググったらやたらタイムリーな記事書いてるな
で、こいつがなんなの？

720 ：デフォルトの名無しさん：2010/03/16(火) 13:58:45

そもそもprivateが何なのか知らなかったんじゃないのかねぇ

721 ：デフォルトの名無しさん：2010/03/16(火) 14:57:01

privateメソッドって、Cで言うところのファイルスコープのstatic関数のようなものだと
思ってたが、何か違うの？

722 ：デフォルトの名無しさん：2010/03/16(火) 19:30:02

どっかで見た書き込みだなぁと思ったら>>542だった。

723 ：デフォルトの名無しさん：2010/03/16(火) 22:34:29

>>721
運用による。
private メンバ/メソッドにアクセスしないなら、依然ファイルスコープ static でも構わない。
C の頃から OO 的モジュール分割してたのなら、その解釈でいいと思う。

724 ： ◆79cfdX7bxM ：2010/03/16(火) 23:41:56

言葉を額面通りでしか受け取れない人達ばかりですねぇ。
メンドイのでチョイスして回答させてもらいます。

>706
1の「Dataのopenの場合」です。

当たり前の事を書いてるだけのつもりでしたが、改めて説明しますか。
まずData::openを変更するのはどんな時?と言うと、↓です。
　(1)Data独自の機能を追加する場合
　(2)File::openのシグネチャが変化した場合
ここでまず「File::openの変更時にDataが影響を受けるのを避ける」のに
Data::openは役立たない事が分かりますね?
そもそもprivateなのだから、Data内に対する役割しか持ち得ませんが。

ではDataに対するData::openの役割は何でしょう?
それも「File::open に処理を丸投げするだけのData::open」の役割は?
m_pFileの隠蔽は当然あり得ません。
また、m_pFileが隠蔽されていないのですから、File::openの代わりに
Data::openを使用する事を強制できません。
使用を強制できないのですから、丸投げするだけのData::openは
将来の拡張に備えるという目的には相応しくありません。

Data::openの役割は、「任意で使用できる」Dataクラス固有の機能を
提供するだけのはずです。
丸投げするだけのData::openに固有の機能などありませんから、
無用の長物としか言えません。

725 ：デフォルトの名無しさん：2010/03/16(火) 23:44:00

メンドウならもう書かなくて良いのに

726 ： ◆79cfdX7bxM ：2010/03/17(水) 00:06:33

>715
漏れが無駄と言ってるのは、「他のクラスの関数に処理を丸投げするだけの関数」です。

ちなみに Proxy や Facade のようなパターンでは例外的にそういった関数が登場すると思いますが、
その場合はアリだとも断ったはずです。(>532)
またその場合、問題の関数がprivateなワケがありません。

727 ：デフォルトの名無しさん：2010/03/17(水) 00:07:19

>>724
もう、あなたが書くべき言葉は「ごめんなさい」の一つしか残されていません。

728 ：デフォルトの名無しさん：2010/03/17(水) 00:10:21

>>726
あの、↓の実装お願いできませんか？
出来たら本当に凄いことだと思うので。

>File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
>まぁ open等を作った場合も同じ方法で発生を抑えられますが。

729 ：デフォルトの名無しさん：2010/03/17(水) 01:33:42

>>724
「では」以降何を言っているのかさっぱりわからないが、それprivate関数であっても、
クラス名が主語になるようなメソッドしか作成してはならない、の説明なのか？

額面通りに受け取って話が通じるような文章にしてくれよ。

あまりにお前が一生懸命に何か言おうとしてるから、何を言いたいのか知りたいんだけど、
大抵何言ってるのかさっぱりわからんのだよ。

それと、もうクラス名の主語たりえろ云々はもうどうでもいいから、>>728だけは回答してくれ。

730 ：デフォルトの名無しさん：2010/03/17(水) 01:48:36

結局、俺様の崇高な文章がわからないお前ら馬鹿という所で思考停止してしまって、
推敲するとか文章読本読むとかするつもりゼロなんだろうなぁ。

ニュアンス読み取れってことは、自分の伝えたいことが伝わってないということで、
それは自分の文章に原因があるってことに気づかないのかね。

プログラマなんだからコードで語れよ。

>File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。

「等の条件」はお前にしか解らないんだから。
コードで示せば一発で相手を理解させることができるのに。

731 ：デフォルトの名無しさん：2010/03/17(水) 02:15:10

次に◆79cfdX7bxMは　「こまけえこたぁいいんだよ」　と言う

732 ：デフォルトの名無しさん：2010/03/17(水) 02:21:47

あれ、責務とか結合度とかカプセル化の話はどこいったんだ？

733 ：デフォルトの名無しさん：2010/03/17(水) 02:25:48

◆79cfdX7bxMにとっては「Dataのメソッドを書き換えるときに、Dataをコンパイルし直さなければいけない事」が一番重要な問題だったんだよ！！
もういいだろみんな！！！

734 ：デフォルトの名無しさん：2010/03/17(水) 02:32:53

>File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
当たり前の様に言ったコレ
間違いを認めて全面撤回と謝罪をするか、サクっと実コードを示すか
最後にコレだけ頼む

735 ：デフォルトの名無しさん：2010/03/17(水) 02:45:25

1対他全員の構図になってるのに、めげずに書き込むのは何がそうさせるんだろう？
そろそろ自分が間違ってるカモと思い始めてもいい頃なのに。

736 ：デフォルトの名無しさん：2010/03/17(水) 02:54:04

>>726
だーかーらー、一行をたらい回すprivateメソッドなんて無駄だよねってのはみんなが同意するところで、
オブジェクト指向的に間違ってるのはどこがどう間違ってるのかという話なんだけど。

737 ：デフォルトの名無しさん：2010/03/17(水) 02:54:24

無知や矛盾や破綻を指摘される度に一応ググってるらしく
段々使ってる語呂が増え、語呂もオブジェクト指向の物になって来てるんだけど
一つも漏らさず全部の単語の用法が致命的に間違ってると言う素晴らしさ

一生改善しない、まさに死ぬまで馬鹿が約束された、馬鹿の中の馬鹿

738 ：デフォルトの名無しさん：2010/03/17(水) 09:07:57

皆今日も華麗に舞って俺を楽しませてくれ

739 ：デフォルトの名無しさん：2010/03/17(水) 11:27:40

飽きた

740 ：デフォルトの名無しさん：2010/03/17(水) 11:30:26

もしかして：語彙

ﾌﾟｷﾞｬ-ｗｗｗ

741 ： ◆79cfdX7bxM ：2010/03/17(水) 19:54:07

>735
そろそろ気付いて下さい。

※但し釣りじゃありません。

742 ：デフォルトの名無しさん：2010/03/17(水) 20:18:19

レッツパリィー！

743 ：デフォルトの名無しさん：2010/03/17(水) 21:57:34

コードも書けない、負け逃げも嫌

屑

744 ：デフォルトの名無しさん：2010/03/18(木) 00:08:50

>>741
そろそろ自分で出来るって言ったコード書けよゴミクズ

745 ：デフォルトの名無しさん：2010/03/18(木) 00:56:51

Cライブラリの関数ポインタ集みたいなクラス作って
何が抽象化だよｗ

746 ：デフォルトの名無しさん：2010/03/18(木) 01:28:27

>>741の名前はクニオ
間違いない

こんなに自分の発言に責任を持たないキチガイは二人と居ない

747 ： ◆79cfdX7bxM ：2010/03/18(木) 01:43:07

反例出せば即決なのに。

748 ：デフォルトの名無しさん：2010/03/18(木) 01:46:15

>>747
お前は出来ると言った

俺は出来ないと考える

悪魔の証明を求めるとか本当に馬鹿だな

どうせ悪魔の証明って言葉自体知らんのだろうけど

749 ：デフォルトの名無しさん：2010/03/18(木) 01:48:20

>>747
この期に及んで、明らかに不可能な発言すら撤回しないの？本当にごめんなさい出来ないクズだな

750 ：デフォルトの名無しさん：2010/03/18(木) 02:08:51

出してもいない例に対する反例を出せとかｗｗｗｗｗｗｗｗｗｗばかすｗｗｗｗｗｗｗｗｗ

751 ：デフォルトの名無しさん：2010/03/18(木) 02:35:07

>>747
おれの理論を使えば誰でも簡単に時間旅行が出来る。
そんなことありえないだって？ならお前が反例だせ。

これ位の馬鹿さを晒しています。
気付いてください。

752 ：デフォルトの名無しさん：2010/03/18(木) 04:58:01

>>747が仕事でコード触ってるとか嘘乙すぎるｗ

753 ：デフォルトの名無しさん：2010/03/18(木) 06:30:27

>>747
どの発言の何の反例を求めてるんだ？
お前の発言はどれもめちゃくちゃでわからんぞ。

754 ：デフォルトの名無しさん：2010/03/18(木) 09:05:32

>>747
何の反例を求めてるんだか、唐突で全く意味不明。
反論の間違いだとしたら、死ぬほど反論されてお前が無視してるだけだから、スレを読み直して回答しろ。

755 ：デフォルトの名無しさん：2010/03/18(木) 09:07:02

もう、自分が正し*げ*だという立場表明のほのめかし発言しか出来なくなったようだな。
それでもこのスレを読むのもやめられず、悔しくて発言するのもやめられない。

756 ：デフォルトの名無しさん：2010/03/18(木) 09:11:51

>>724
> 言葉を額面通りでしか受け取れない人達ばかりですねぇ。

普通の人間なら、額面通りに受け取ってもらえる文章を書こうとするんだが。

757 ：デフォルトの名無しさん：2010/03/18(木) 14:01:04

>>747 に質問なんだが
Data::open() が固定パスのファイルを開くメソッドで有ったり、インデックスを特定のルールでパスに変換して開くメソッドである場合も
File の派生クラスを用意して役割分担させるべきと考える？
同様に Data::write() がテキストをHEXで書き込むメソッドである場合もその責務を File の派生クラスに負わせるべき？
この考えだと File の派生クラスは Data の完全な下請けクラスになっちゃうけどこれってオブジェクト指向的に正しいの？

758 ：デフォルトの名無しさん：2010/03/18(木) 14:22:59

>>747
短文にどこまでツッコミ所を込められるかのテストか？ｗｗｗ

759 ：デフォルトの名無しさん：2010/03/18(木) 15:56:27

結論

>>747は病気

760 ： ◆79cfdX7bxM ：2010/03/18(木) 19:38:45

今日も空気を読まずにカキコ。
Data は DataHolderと書いといた方が分かり易かったかと今更後悔。

ところで念の為に聞いておくけど、↓のような実装もオブジェクト指向的には
全く問題無い、と思っておられる方は居るんでしょうか。

　class DataHolder : private File
　{
　　public: void SaveToFile(){
　　　open();
　　　write();
　　　close();
　　}
　};

761 ：デフォルトの名無しさん：2010/03/18(木) 19:44:31

くだらん話題なんか振らなくていいから、まずお前のすべきことをしろ。

762 ：デフォルトの名無しさん：2010/03/18(木) 19:52:09

念の為だって、奥様ｗ

763 ：デフォルトの名無しさん：2010/03/18(木) 20:18:16

> と書いといた方が分かり易かったかと今更後悔

まだこいつ自分が正しいと思ってるのか

764 ：デフォルトの名無しさん：2010/03/18(木) 20:24:24

マ板のおじゃばってコテを思い出した。

765 ：デフォルトの名無しさん：2010/03/18(木) 20:26:13

こいつのトリップぐぐったらMoonWolfと一致するな。偶然かもしれないが。

766 ：デフォルトの名無しさん：2010/03/18(木) 20:27:46

DataHolderみたいなピンとこねぇ名前で、
そういう単位でクラスをつくる奴の気は知れねぇが。

class DataHolder {
　　public: void SaveTo(File f){
　　　f->open();
　　　f->write();
　　　f->close();
　　}
};

みたいになぜしないのか不思議。
流れ読んでなくてすまんが。

767 ： ◆79cfdX7bxM ：2010/03/18(木) 22:12:32

>766
まぁ普通はそうします罠。
では質問をちょっと変えて、↓のB～Eのうち、これは無いだろってのを挙げて下さい。
あと一部は良くて他は駄目と言う場合、できれば何が違うかも挙げて下さい。
※クラスB～Eは、Aとは全く役割が異なるクラスとします。
※Func2～5は、func1を呼び出す以外の処理も行うとします。
※クラスA以外のfunc1は、クラスAのfunc1を呼び出すだけとします。
※コンストラクタやm_pAの初期化処理は割愛。

　class A {
　　public: void Func1( );
　};
　class Awrapper {
　　public: void Func1( ) { m_pA->Func1( ); }
　　private: A* m_pA;
　};
　class B {
　　public: void Func2( ) { m_pA->Func1( ); }
　　private: A* m_pA;
　};
　class C {
　　public: void Func3( ) { Func1( ); }
　　private: void Func1( ) { m_pA->Func1( ); }
　　private: A* m_pA;
　};
　class D : private Awrapper {
　　public: void Func4( ){ Func1( ); }
　};
　class E : private A {
　　public: void Func5( ) { Func1( ); }
　};

768 ： ◆79cfdX7bxM ：2010/03/18(木) 22:17:24

>757
一応Data::openは固有の引数を与えるとかすら無い、
「完全に丸投げ」な関数だから問題としてます。
あとFileの派生クラスがDataの下請けクラスになるのは正しいと思いますが。
Dataがそのクラスに処理を一部委譲してるって事ですよね。

>765
多分トリップの無い様が簡単過ぎるからかと。

769 ：デフォルトの名無しさん：2010/03/18(木) 23:54:48

>>768
下請けクラスを作成する事がオブジェクト指向的に正しいのか答えてないね

あるクラスの機能を実装するときにこの機能はこのクラスの派生が持つべきだからって理由で下請けクラスを
複数作るのは原理主義過ぎて現場にはそぐわないと思うんだが

770 ：デフォルトの名無しさん：2010/03/19(金) 00:06:53

>>768
うるせークズ
お前はまずやるべき事をやれ

771 ：デフォルトの名無しさん：2010/03/19(金) 00:10:47

>>767

　　全　　部　　論　　外

772 ：デフォルトの名無しさん：2010/03/19(金) 02:02:04

うわ、こいつこれまでの数々の恥ずかしい勘違いを無かったことにしようとしてるぞ

773 ：デフォルトの名無しさん：2010/03/19(金) 02:15:22

>>768
> 「完全に丸投げ」な関数だから問題としてます。

問題だから問題です以上の何かは、もう言えないということだな。

private継承を持ち出して、また何か持論を展開しようとしてるみたいだが、まずお前の結論・主張を書け。
つか、まず>>541の問題に決着をつけろ。

774 ：デフォルトの名無しさん：2010/03/19(金) 02:32:56

散々嘘吐いて話逸らして誤魔化し続けた不誠実の極み見たいな馬鹿が
まーた論点ずれた問いかけをして誰かに答えてもらえるとでも思ったの？

775 ：デフォルトの名無しさん：2010/03/19(金) 02:34:43

>>760
仮にそれが問題ありだとして、>>541とどう関連づけるつもりなんだろう？

776 ：デフォルトの名無しさん：2010/03/19(金) 02:36:57

private継承などという言語specificな話題を持ち出した時点で、オブジェクト指向的な是非とは
離れてしまったということに気づかないのかな。

777 ：デフォルトの名無しさん：2010/03/19(金) 02:48:40

>>776
だからコイツにとっては
オブジェクト指向=C++の言語仕様
なんだって
本人にとっては何もぶれちゃいないツモリ

ヘッダでprivateメソッドの痕跡が見れるのが
オブジェクト指向的に見て大問題とかいっちゃうブットビ具合

778 ：デフォルトの名無しさん：2010/03/19(金) 02:59:01

これだからC++は塵言語なんだ
マルチパラダイム言語とか「１０人の天才の足を引っ張る一人のキチガイ」を大量生産するだけだろ

779 ：デフォルトの名無しさん：2010/03/19(金) 03:42:56

普通の人間には、ここまで支離滅裂な行動をとる事は、実は難しい。

780 ：デフォルトの名無しさん：2010/03/19(金) 03:56:38

このスレで、なんとか名誉挽回しないと心の平穏が保てないんだろうなぁ。

781 ：デフォルトの名無しさん：2010/03/19(金) 06:41:21

あーあー、見苦しいなｗ

782 ：デフォルトの名無しさん：2010/03/19(金) 07:56:52

多分今晩にはこの馬鹿の勝利宣言が聞けるな

相手にされなくなってからの勝利宣言ほど惨めな物は無いが
いい加減しつこ過ぎるしさっさと勝利宣言して気持ちよく消えてくれ

783 ：デフォルトの名無しさん：2010/03/19(金) 09:08:44

C++におけるコーディング規約：
・private継承はしない

え？やりたい？うるせー馬鹿。うぜー。

784 ：デフォルトの名無しさん：2010/03/19(金) 10:10:14

>>767
基底クラスと派生クラスの役割と、派生クラスは継承して何をやりたいかを明確にしないと
private継承のことは語れません。
private継承は、それを行うと便利なときのみに使います。
どのような時に便利なのかは、（More?) Effective C++やModern C++ Designに載ってます。

785 ：デフォルトの名無しさん：2010/03/19(金) 10:16:59

基本的にはprivate継承は、派生クラスのクライアントコードから基底クラスの公開メソッドを隠すために使う。
A-Eが何なのか解らないと答えようがないのは>>784と同じ。

786 ：デフォルトの名無しさん：2010/03/19(金) 18:45:48

そろそろ来るぞー
「誰にも答えられなかったようですね」と言う虚しい勝利宣言がー

787 ：デフォルトの名無しさん：2010/03/19(金) 19:16:43

OOPの話題をしているかと思ったら、
private継承を混ぜてきたとか（；´Д｀）

だいたい、privateメソッドに着目してウンタコータラ言い続けるのも不思議。
そんなもんの変更は、クラス内で完結しちゃってるだろうに。

788 ： ◆79cfdX7bxM ：2010/03/19(金) 23:51:35

>776,783,784
そこを突っ込むつもりなら、D、Eはこれでも良いです。

　class D : public Awrapper {
　　protected: void Func4( ){ Func1( ); }
　};
　class E : public A {
　　protected: void Func5( ) { Func1( ); }
　};

>785
A～Eが何なのかは、まず身近なコードでAとBの関係になってるものを探して、
B=C=D=Eとして考えて下さい。
で、B～Eはありなのかと。
流石にBが論外とか言うのは>771だけだと思いますが。

789 ： ◆79cfdX7bxM ：2010/03/19(金) 23:54:59

誰もまともに答えるつもりがなさそうなので質問を変えてみますが、
BのようなコードをC～Eのように書く（書き直す）のはありでしょうか?
無闇に書き直すのは間違いとかいうのは無しですよ。

790 ：デフォルトの名無しさん：2010/03/20(土) 00:10:58

もはや誰一人としてどういう観点からありなしを語ってるのかすら分からないだろう
こいつは根っこから馬鹿なんだな
余りにも話を伝える能力が無い

791 ：デフォルトの名無しさん：2010/03/20(土) 00:11:19

答えて欲しいなら問題を書き直してくれ
>>767 では問題として題意が不明瞭な為に回答ができないとの意見が多い
修正点を上げるだけでは読むほうにとって面倒なので問題を作り直して提示するのが筋だ

792 ：デフォルトの名無しさん：2010/03/20(土) 00:57:38

この馬鹿まだやってるのかよｗ

793 ：デフォルトの名無しさん：2010/03/20(土) 01:57:26

幼稚園児の方がまだ話が通じるわ

794 ：デフォルトの名無しさん：2010/03/20(土) 02:37:10

意味不明で答えようも無い質問を出してるのにコイツは何時になったら気付くの？

まともに答えるつもりが無い？質問を変えてみます？

何でコイツはコンナニモ馬鹿なのにコンナニモ上から目線なの？

795 ：デフォルトの名無しさん：2010/03/20(土) 02:48:37

>>789
まず、お前が積み残した質問に答えろ

796 ：デフォルトの名無しさん：2010/03/20(土) 02:55:09

自分以外の馬鹿が釣れるまで質問し続けて、
決定的な間違いをした奴を叩いて溜飲を下げてから
このスレから立ち去る戦法。

797 ：デフォルトの名無しさん：2010/03/20(土) 02:55:35

>>789
お前が大半のレスを無視した結果がこれだよｗ

798 ：デフォルトの名無しさん：2010/03/20(土) 02:59:31

>>789
BをCに書き換えたらそれは>>541で、Cはオブジェクト指向的に間違いだという主張じゃなかったのか？
今までさんざん指摘があったのは全部無視か？

>A～Eが何なのかは、まず身近なコードでAとBの関係になってるものを探して、

いやいや、質問したいなら、お前の身近なコードで具体例を示せよ。

799 ：デフォルトの名無しさん：2010/03/20(土) 03:13:50

今頑張って馬鹿が釣れそうな問題考えてるから明日の夜まで待ってくれ
じゃないの？

800 ：デフォルトの名無しさん：2010/03/20(土) 03:26:46

◆79cfdX7bxMの汚点まとめ
１．馬鹿
２．不遜
３．尊大
４．横柄
５．論点無視
６．論理飛躍
７．他者批判
８．責任転嫁
９．認知障害
１０．有言不実行
１１．自意識過剰
１２．自制心不足
１３．認知的不協和

801 ：デフォルトの名無しさん：2010/03/20(土) 05:45:24

>>788にとってはpublic/privateの違いなんて、「ならこれでも良いです」って位の
どーーーーーーーでもいい些事なんだな

オブジェクト指向のオの字すら語る資格が無い

802 ：デフォルトの名無しさん：2010/03/20(土) 05:52:44

正直ここまでpublic/privateの区別が出来てない奴も珍しい
プロジェクトに組み込まれたら災害レベルの無能を発揮するだろう

803 ：デフォルトの名無しさん：2010/03/20(土) 08:40:49

さあ連休だ。
存分に踊れ。

804 ：デフォルトの名無しさん：2010/03/20(土) 10:31:14

明らかに間違った事を主張する　2010/03/11(木)
↓
矛盾点を指摘、質問される
↓
論点がずれた意味不明な回答をする
↓
全然解決されなかった矛盾点を再度指摘、質問される
↓
めんどくさいんでスルーしますと言い出す
↓
全てを無かった事にして意味不明な質問をしだす
↓
意味不明すぎて誰からも相手にされない
↓
質問の要点が不明瞭なまま角度だけを変えた意味不明な質問を繰り返す
↓
意味不明すぎて誰からも相手にされない　←いまここ
↓

805 ：デフォルトの名無しさん：2010/03/20(土) 10:42:54

この一文にすべてが凝縮されてる。

>>679
> 超ド素人でも感覚で理解してるような原則を延々説明しなきゃならんとか、

ド素人の自分が超ド素人時代に、感覚で理解したと勘違いしたことを延々と垂れ流しているだけ。
何の根拠も理論武装も無い。無いが故に、何故正しい自分がわかってもらえないのかという所
から抜け出せない。
あまつさえ、全員が自分を釣っているのではという疑念を抱く始末。

806 ：デフォルトの名無しさん：2010/03/20(土) 10:56:15

こんなにはっきり「お前のそれは間違ってる」と言われているのに
「こいつら一から説明しなきゃ分からないのか」と超絶変換される脳みそ持ってる事は、本当にお気の毒だと思う
まぁ79cfdX7bxMの脳みそと性格は絶対直らないから早く死ぬといいよ

807 ：デフォルトの名無しさん：2010/03/20(土) 21:36:10

Money, Employee, Order, Printer, Customer, Movie, Rental, Account, Chargeとかさ、
OOの設計とかリファクタリングとかTDDとか、その手の書籍見たらこんな感じの簡単な
具体例が良く出てくる。
Animal, Dog, Catはもう古いけどさ。
こういう具象クラスを例に挙げないと、会話が進まないよ。
本気で会話したいのかどうか知らないけど。

808 ：デフォルトの名無しさん：2010/03/20(土) 21:45:55

もう居なくなった 79cfdX7bxM の話は終わりにしないか？

809 ：デフォルトの名無しさん：2010/03/20(土) 22:19:51

>>504が発言するまで三ヶ月も放置されてたし、やりたいならとことんやれば？ｗ

810 ： ◆79cfdX7bxM ：2010/03/20(土) 23:26:22

　class A {
　　public: void Func1( );
　};
　class B {
　　public: void Func2( ) { m_pA->Func1( ); }
　　private: A* m_pA;
　};
元々↑のようになっていたコードを、
　class Awrapper {
　　public: void Func1( ) { m_pA->Func1( ); }
　　private: A* m_pA;
　};
　class B : public Awrapper {
　　public: void Func2( ){ Func1( ); }
　};
あるいは
　class B : private Awrapper {
　　public: void Func2( ){ Func1( ); }
　};
と書き直すのはありなんですか?

811 ：デフォルトの名無しさん：2010/03/20(土) 23:29:17

なし。

812 ：デフォルトの名無しさん：2010/03/21(日) 00:10:30

>>810
Awrapper を Bsuper に変更すれば問題無いんじゃないの

813 ：デフォルトの名無しさん：2010/03/21(日) 00:31:13

何か自由度が増えるとか関数ポインタの参照をする依存度が
減るとかメリットあるのか？

814 ：デフォルトの名無しさん：2010/03/21(日) 01:13:54

>>813
class B と同列に class B' を作るなら class Bsuper から派生させるのは良くある事だと思うけど
俺に聞いてるんじゃなかったかな？

815 ：812：2010/03/21(日) 01:34:28

少し補足
>>810 の class A を犬、class B を桃太郎として考えてみよう
class Awrapper は犬の機能を抽出したペットというクラスになり、class Bsuper は人って事になるかな
class Pet {
public: void peropero() { m_self->peropero(): }
private: Dog* m_self;
};
ラッパーは継承しないほうが隠蔽度が上がるからこの実装に問題は無いと思う
class Human {
public: void peropero() { m_dog->peropero(); }
private: Dog* m_dog;
};
人のクラスに舐めるメソッドが存在するのは少し変だけど、実装上の都合でこうなるのは有りえる事
原理主義者は怒るだろうけど絶対ダメって話じゃないと思う（無論、異論は認める）

かくしてペット( Awrapper )と人( Bsuper )の実装が舐める(peropero）に関しては同じになってしまったが、
この２クラスの性質は明らかに異なる
>>810 の後半はペットから桃太郎を派生しているからオブジェクト指向的にはダメで、
Awrapper を Bsuper にして、人から桃太郎を派生させる様にすれば問題は無いんじゃなかろうか

816 ：デフォルトの名無しさん：2010/03/21(日) 01:41:43

>>810
意味ない質問してるの解ってるのかな。
責務とか言ってたの誰だっけ？

817 ：デフォルトの名無しさん：2010/03/21(日) 01:43:23

>>815
お前それ本気で言ってんの？

818 ：815：2010/03/21(日) 02:15:19

>>817
うーん微妙、>>810 の反応が見たいから書いてみたけど少し無理が有るしなぁ...

819 ：デフォルトの名無しさん：2010/03/21(日) 02:20:08

>>816
いやいや、その前にたとえprivateであっても主語がうんたらかんたらが先だろ

820 ：デフォルトの名無しさん：2010/03/21(日) 04:35:35

>>810の馬鹿ついに全部パブリックにしだした

821 ：デフォルトの名無しさん：2010/03/21(日) 05:52:19

こんなイン○リみたいな奴がイ○ドリ以外に居る事に驚愕を禁じえない
それとも、俺が知らないだけでC++界隈にはこの手の馬鹿が多かったりするのか？

822 ：デフォルトの名無しさん：2010/03/21(日) 07:44:12

イソドリ本人だったりしてな
こんなのそうそう出ない上に、その破壊力が強烈だから目立つだけじゃね？
℃ｏｄｅＺｉｎｅみたいに、ライターとして記事を採用するようなバカやらなきゃ、実被害は出んよ

823 ：デフォルトの名無しさん：2010/03/21(日) 08:21:29

いや、でもこういう手合いってPGSEには一定割合で存在してるような気もするよ。

824 ：デフォルトの名無しさん：2010/03/21(日) 08:40:01

だからインドリって何だよ
ここで話に挙げたいなら纏めろ

825 ：デフォルトの名無しさん：2010/03/21(日) 10:18:06

ググればすぐわかるのに

826 ： ◆79cfdX7bxM ：2010/03/21(日) 10:42:09

　class B : public Awrapper {
　　public: void Func2( ){ Func1( ); }
　};
あるいは
　class B : private Awrapper {
　　public: void Func2( ){ Func1( ); }
　};
と書くのがダメだとしたら、
　class B {
　　public: void Func2( ){ Func1( ); }
　　private: void Func1( ) { m_pA->Func1( ); }
　　private: A* m_pA;
　};
もダメだと思いますがいかがでしょうか。
Awrapper が明示的に抽出されていないだけで、
その役割をBに与えてるのは同じですよね。

まぁこれは原理主義的過ぎる考え方だとは思いますがね。

827 ：デフォルトの名無しさん：2010/03/21(日) 10:44:21

相手が何か特殊な単語を使うと鸚鵡返しのように次のレスに組み込んでくるな
まぁ相変わらずイミフ

828 ：デフォルトの名無しさん：2010/03/21(日) 10:52:08

賢そうな単語に見えたんで早速真似してみましたって行動パターンが哀れ過ぎる。
そして悉く使い所が間違ってると来ると、もはや涙無しには語れない。

829 ： ◆79cfdX7bxM ：2010/03/21(日) 11:08:09

>827-828
特殊な単語ってどれ?

830 ：デフォルトの名無しさん：2010/03/21(日) 11:34:49

>>826
話がずいぶん変わってきた感じがあるが、直近のレスにコメントすると、
Code1:
class B : public Awrapper {
　　public: void Func2( ){ Func1( ); }
};
と
Code2:
class B {
　　public: void Func2( ){ Func1( ); }
　　private: void Func1( ) { m_pA->Func1( ); }
　　private: A* m_pA;
};
は同一じゃないだろ。Code1の是非はともかくCode1が駄目だとしてもCode2が駄目だとは言えない。
Code1は、お前が考えてるのとは別の意味で駄目な場合がある（継承の是非的視点）。

Code3:
class B : private Awrapper {
　　public: void Func2( ){ Func1( ); }
};
これも同様で、Code3の是非とCode2の是非はイコールではない。
なぜイコールだと思うのか、その根拠を書け。

831 ：デフォルトの名無しさん：2010/03/21(日) 11:41:19

継承という話を持ち出した時点で、is-a関係やs-implemented-in-terms-of関係か
どうかという事抜きに話をするのは意味がない。

それら抜きに書き換え可能かどうかと言えば、答えは書き換えられるとしかいいようがなく、
それが無駄なたらい回しかどうかは、その場合もあればそうでない場合もあるとしか言えない。

832 ：デフォルトの名無しさん：2010/03/21(日) 11:48:16

コンテキスト抜きにClass ABCとかFunc1とか言っても駄目。
なんでコンテキストがしっかりしている>>541から逃げるのか。

833 ：デフォルトの名無しさん：2010/03/21(日) 11:50:15

>>832
もはや反論しようが無いからABCで誤魔化して逃げてる

834 ：デフォルトの名無しさん：2010/03/21(日) 11:53:09

>>826
> Awrapper が明示的に抽出されていないだけで、
> その役割をBに与えてるのは同じですよね。

まだわかってねーな。
privateメソッドに抽出してもclass Dataの役割は何も変わってないし、カプセル化の度合いも変化なし。
そのこととその抽出したprivateメソッドをクラスに引き上げるのとは全然別。

835 ： ◆79cfdX7bxM ：2010/03/21(日) 12:19:37

>830
>なぜイコールだと思うのか、その根拠を書け。

826に書いてある通りです。
Awrapper が明示的に抽出されていないだけで、
Awrapperとしての役割をBに与えてるのは同じですよね。
（役割と言う表現が妥当かは、若干自信がありませんが。）

あとCode2は A-B が has-a な関係なのは明らかですから
is-a 関係とは言えないと思います。
※Javaのように多重継承を許さない言語系では、
　is-aな関係でも委譲の形で実装する事はあるでしょうが、
　その場合 func1 を private にする事はないはず。

836 ：デフォルトの名無しさん：2010/03/21(日) 12:27:59

何言ってるのかさっぱりわからない。
Code2はhas-a関係でCode1はis-a関係でしょう。

837 ： ◆79cfdX7bxM ：2010/03/21(日) 12:29:05

>834
DataとFileから見た両者の関係は?
少なくともData自身から見れば、Fileとの関係について
privateかどうかは関係無いと思いますが。

838 ： ◆79cfdX7bxM ：2010/03/21(日) 12:30:51

>836
何でCode1とCode2を比べているのですか。
>830が言ってるのはCode2とCode3では。

839 ：デフォルトの名無しさん：2010/03/21(日) 12:35:18

>>837
DataとFileはデータ結合だっつってんだろカスが

840 ：デフォルトの名無しさん：2010/03/21(日) 12:37:53

>>838
何でそんなに文盲なの。

841 ：>>830=836：2010/03/21(日) 12:38:06

>>838
開いた口がふさがらないとはこのことだな。
>>826を書き直せば、
「Code1あるいはCode3が駄目だとしたらCode2も駄目である」
と言ってる。

Code1とCode2は同一ではない。Code1はis-a関係でCode2はhas-a関係だ。
別の構造なんだから、Code1の是非とCode2の是非は同一ではない。

Code3はクラスを抽出したということと、private継承下という点でCode2と異なる。
故にCode3の是非とCode2の是非は同一ではない。

Code1、Code2そのものにも問題がある場合があって、それは具象例でなければ語れない。

わかった？

842 ：>>830=836：2010/03/21(日) 12:43:21

付け加えて言うなら、Code2とCode3はいつでも違うのかというと同じ場合もあって、
それはやはり具象例でなければ語れない。

>>541のような具象例だと話が早いし、是非も語れる。
そして、>>541のコードだったら無駄なたらい回しだよねという結論だが、
オブジェクト指向的に間違いかどうかには決着が付いてない。

843 ：デフォルトの名無しさん：2010/03/21(日) 12:43:28

完全に実装の是非の話をしているのに、ABCABC繰り返すだけでお話にならん

844 ： ◆79cfdX7bxM ：2010/03/21(日) 12:46:09

>841
>Code3はクラスを抽出したということと、private継承下という点でCode2と異なる。
>故にCode3の是非とCode2の是非は同一ではない。

ここを詳しく。
Code3はダメでCode2はOKという例を出してくれればOKです。

845 ：デフォルトの名無しさん：2010/03/21(日) 12:48:15

１．馬鹿
２．不遜
３．尊大
４．横柄
５．論点無視
６．論理飛躍
８．責任転嫁
９．認知障害
１２．自制心不足
１３．認知的不協和

今日だけでこれだけ再発

846 ：デフォルトの名無しさん：2010/03/21(日) 12:52:37

>>844
お前は絶対実例出さないのに人にだけはそんな偉そうな態度で例示させるんだなｗｗｗ

847 ：>>830=836：2010/03/21(日) 12:55:09

お前が主張したいのは、Code3は駄目である、なぜならCode2が駄目であるからということだろうが、
そもそもその命題の建て方が間違ってるという指摘なんだが。

何度も言うが、具象例を出せ。

848 ：デフォルトの名無しさん：2010/03/21(日) 12:56:24

そもそもprivate継承はオブジェクト指向に無い概念だから論外だろ
お前は一体何の話がしたいの？

849 ： ◆79cfdX7bxM ：2010/03/21(日) 13:01:49

>847
逆。
Code3がダメだからCode2もダメだと言いたい。
あるいはBにAのラッパーとしての性格を持たせるのがナンセンスと言いたい。

850 ：>>830=836：2010/03/21(日) 13:03:54

>>844
ちゃんと説明しないとわからないか。

Code3が良いなら、それはis-implemented-in-terms-of関係なの（他のprivate継承の
例もある）だから、Code2も良い。

しかし、Code2が良いならいつでもCode3が良いとは言えない。
良い場合もあれば悪い場合もある。（だからCode2が良くてCode3が悪い例を考えても
意味がない）

そして、Code3が悪ければCode2も悪いことにはならない。

851 ： ◆79cfdX7bxM ：2010/03/21(日) 13:05:32

>あるいはBにAのラッパーとしての性格を持たせるのがナンセンスと言いたい。
無論 B が A のラッパーであるなら妥当であるけど、その場合↓のように
B::func1 は public にするはずですよね。（protectedもあり得るけど）

Code4:
class B {
　　public: void Func2( ){ Func1( ); }
　　public: void Func1( ) { m_pA->Func1( ); }
　　private: A* m_pA;
};

852 ：>>830=836：2010/03/21(日) 13:07:05

クライアントがclass Dataを使用するという関係と、class Dataとclass Fileの関係を
ごっちゃにするなよ。
class Dataが何を保有しようと、privateメソッドに何を持とうと、クライアントには
Fileラッパーの性格は見えない。

853 ：>>830=836：2010/03/21(日) 13:10:30

>>851
ごめん、理解不能。

854 ：デフォルトの名無しさん：2010/03/21(日) 13:15:10

>>852
それと全く同じ指摘は200～300レス前からされてる。
その時の返答はヘッダファイルから見えるだった。

855 ：>>830=836：2010/03/21(日) 13:15:59

あ、これ言っとかなきゃ駄目か。
Code3は良い場合がある。それは、is-implemented-in-terms-of関係の場合だ。

今日はこれにて撤退。

856 ：>>830=836：2010/03/21(日) 13:17:45

あ、それから具象例というのは具体的なコード＋具象クラスのことだからよろしく。

857 ：デフォルトの名無しさん：2010/03/21(日) 13:24:03

お疲れ様でした

858 ：デフォルトの名無しさん：2010/03/21(日) 13:26:03

privateで隠せば何やってもOKと言うなら、
大半の問題ケースが許されてしまうと思うんだが。

859 ：デフォルトの名無しさん：2010/03/21(日) 13:28:47

>>858
クラス設計的な誤りと、それを隠蔽するかどうかと、>>541がオブジェクト指向的に
誤りかどうかは別の話。

860 ：デフォルトの名無しさん：2010/03/21(日) 13:46:02

private継承で実装手段以外の例としては、non-copyable-mixinだな。

861 ：デフォルトの名無しさん：2010/03/21(日) 13:46:08

　class Awrapper {
　　public: void Func1( ) { m_pA->Func1( ); }
　　private: A* m_pA;
　};

Aという型が実装に使われてるのを隠すんなら、
そんなクラス名は不都合だし、メソッド名も同じになるのも苦痛。
型を継承した関係じゃないのに、
実装にある型の存在を予感させたりするのはブサイク。
上の例は class B {public void foo() {_a->Func1();}}; の形にしないとウマミが無い。

class DecratedA : public A {};

にして継承関係にすれば、
クラス名もメソッド名も自然になる。

コンストラクタでA *を受け取るようにして、
内部でそれに委譲しながら独自処理を行うと、
GoFで言うところのDecoratorパターンになる。

特性を動的に追加したりすることなく、
再帰的に合成することもなくて、
あるインスタンスへの間接的なアクセスを提供するなら、
Proxyパターンとなる。

862 ：デフォルトの名無しさん：2010/03/21(日) 13:55:22

もうさ、
static A_Func1();
でいいんじゃね？ｗ

863 ： ◆79cfdX7bxM ：2010/03/21(日) 14:03:15

>861
>実装にある型の存在を予感させたりするのはブサイク。
A::Func1 へ丸投げするだけの B::Func1 を実装するのも
ブサイクと思うんですが。（例えB::Func1がprivateだとしても）

それをオブジェクト指向的に云々と表現するのが間違いって言うなら、
単純に漏れが言葉の選択をミスっているという事で納得できますが。

864 ：デフォルトの名無しさん：2010/03/21(日) 14:09:48

>>861と>>863に同じ臭いを感じるんだがどうすればいい？

865 ：デフォルトの名無しさん：2010/03/21(日) 14:27:43

>>861
まぁ、なんだ
>>504から読み直せ

866 ： ◆79cfdX7bxM ：2010/03/21(日) 14:49:29

…
とりあえず別人証明したいなら協力します、と言っておく。>861
（なんならfusianasanもする。）

867 ：砂漠の帝王 ◆.CzKQna1OU ：2010/03/21(日) 16:18:33

俺もなんか ◆79cfdX7bxM が正しいんじゃないかって気がしてきたよ。

868 ：デフォルトの名無しさん：2010/03/21(日) 16:26:18

あーあ・・・

869 ：デフォルトの名無しさん：2010/03/21(日) 17:27:23

>>863
> A::Func1 へ丸投げするだけの B::Func1 を実装するのも

実装はさておき、インタフェースとして適切かどうかが最大の関心ごと。
Aのインタフェースとして適切で、BがAを継承しているのなら正しい。
継承していなくてもFunc1がBとして適切なら正しい。
あくまで、実装の話をする前にこの決着をつけておく必要がある。
インタフェースが腐っていたらもう、実装の話なんかしてる場合じゃなくなる。

次に、実装について。一見不要でも、単純に判断できない。
インスタンスへのアクセスを集約しておくことは、後で思いがけず役に立ったりもする。
void B::Func1() {_a->Func1();}は、メソッド内を if (_a && _a->isVisible()) _a->Func1(); とさせたり、
if (hasFocus()) _a->Func1(); else _stderr->puts(_a->inspect()); とさせたりしうる。
丸投げに見えるだけであっても、ある種のささいな拡張性を備えていると言えなくもない。

最後に、そのたらい回しprivateメソッドの名前がFunc1のままでいいかどうか。
俺は良くないと思う。ただ同時に、ピーピー言うほどのものでもないと思う。
privateメソッドはただ単に、クラスの内部で完結しており、表に出はしない。
クラス内で判別が付く名前を適当に使えば十分だと思う。
private void B::Func1() であっても、良くはないが許せる。

870 ：デフォルトの名無しさん：2010/03/21(日) 18:36:14

>>866
同じ臭いと言われただけでなんですぐ自演に結びつくのかね

871 ：デフォルトの名無しさん：2010/03/21(日) 19:34:53

>>826
class B {
　　public: void Func2( ){ Func1( ); }
　　private: void Func1( ) { m_pA->Func1( ); }
　　private: A* m_pA;
};
に問題は無い、B::Func1() が何の為に存在するのか理解してないだろ
class B {
　　public: void Func2( ){ Func1( ); }
　　private: void Func1( ) { m_pA->Func1( ); }
　　private: Awrapper* m_pA;
};
なら B::Func1() は冗長だから問題が有るがオブジェクト指向的な理由では無い

872 ： ◆79cfdX7bxM ：2010/03/21(日) 22:10:20

>869
>インスタンスへのアクセスを集約しておくことは、後で思いがけず役に立ったりもする。
void B::Func1() {_a->Func1();} と実装したところで、Bの他のメンバが
a->Func1(); とFunc1を直接呼び出すのを禁止できないから、
集約するという役割は果たしていないと思うのですが。

>871
>B::Func1() が何の為に存在するのか理解してないだろ
何の為に存在すると言うのですか。

873 ：デフォルトの名無しさん：2010/03/21(日) 22:16:24

A とか B とか抽象的な名前にした時点で
議論するの意味なくね？

File と Data はどこ行った？

874 ：デフォルトの名無しさん：2010/03/21(日) 22:26:46

> void B::Func1() {_a->Func1();} と実装したところで、Bの他のメンバが
> a->Func1(); とFunc1を直接呼び出すのを禁止できないから、
> 集約するという役割は果たしていないと思うのですが。

もう何なのこの馬鹿
メンバが使う事を制限できないとか言い出したら全てが破綻するだろ

>>872
Awrapperを作ったとしてもAwrapperのメンバがA*に直接アクセスするのを制限できない問題について語れ

875 ：871：2010/03/21(日) 23:09:24

>>872
>>869 = 874 が書いてるんだけどなぁ
B:Func1() の存在意義は A のラッピング

君がラッパーの存在意義を理解してない事は >>872 で露呈されたよ

876 ： ◆79cfdX7bxM ：2010/03/21(日) 23:32:12

>874
Awrapperは、A*を隠蔽して、Awrapper::Func1の使用を
Bのメンバに強制できます。

>875
ですからラッピングしてる対象に直接アクセスできるのですから、
役割を果たしてないじゃないですか。

877 ：デフォルトの名無しさん：2010/03/21(日) 23:38:56

>>872
「一つのクラス内のメンバすら管理できないクソ共が途轍もなくクセェ」ってだけで、他に何か問題でもあるのか？

878 ：デフォルトの名無しさん：2010/03/21(日) 23:39:38

>>876
馬鹿乙

879 ：デフォルトの名無しさん：2010/03/21(日) 23:41:51

>>876
お前正気か？ふざけてんのか？

Awrapperを作ったとしてもAwrapperのメンバがA*に直接アクセスするのを制限できない問題について語れ

千回音読した後死ね

880 ： ◆79cfdX7bxM ：2010/03/21(日) 23:54:03

>Awrapperを作ったとしてもAwrapperのメンバがA*に直接アクセスするのを制限できない問題
そんなモノ無い。でおしまい。
そもそも public である Awrapper::Func1 は、自身からA*を隠すのが目的ではありませんよね。
private である B::Func1 との違いを良く考えて下さい。

881 ：デフォルトの名無しさん：2010/03/22(月) 00:06:14

同次元の話だが

882 ： ◆79cfdX7bxM ：2010/03/22(月) 00:10:31

>877
>他に何か問題でもあるのか？
ぶっちゃけ言うとそれを見つけるのが漏れの目的。
馬鹿の思索に付き合わせてすまんかった。
とりあえず「単に無駄」の領域を出ませんねこりゃ。

敢えて言うなら、コレに意味があると思う人達が居るのが問題?

883 ：デフォルトの名無しさん：2010/03/22(月) 00:25:54

十日以上の時を費やして何も得る物が無かったでFAなｗｗ
無能すぎｗｗｗ

884 ：デフォルトの名無しさん：2010/03/22(月) 00:26:45

>>876
言いたい事は分かるけどね

プロマネが『B::Func1() は A::Func1() のラップ関数ですので将来の事を考えて B のメソッド実装において B::Func1() を使って下さい』
と言ったときに君は『その実装だと A::Func1() の使用を禁じる事ができませんので Awapper を用意すべきです』って返す訳だ
俺がプロマネだったら『帰れ』って言うね

885 ：884：2010/03/22(月) 01:03:10

>>882
先に負け惜しみ書いて逃げてたのね、気付かずにレスして損した気分

コレって B::Func1() の事か？
完全なラッパー（生メソッドの使用を禁じる事ができる）でなくともラップの目的を果たせるのであれば意味は有るだろ
やはり何故ラップするのかって理由が判ってないんじゃないか？

B:Func1() と Awrapper で実装の手間も変わらないとか言うなよ、それこそ素人の証明になる

886 ：デフォルトの名無しさん：2010/03/22(月) 01:07:29

>>885
おいもうそっとしておけ
やっと「オブジェクト指向的に問題ある」と言う妄言を撤回したんだから

887 ：デフォルトの名無しさん：2010/03/22(月) 01:11:59

負け惜しみと言うより全面降伏だな
非常に見苦しかったが、決着はついた。

888 ： ◆79cfdX7bxM ：2010/03/22(月) 01:26:39

とりあえずけじめは付けるつもりでトリ付けてるので、貶すなりなんなりどうぞ。

>885
>やはり何故ラップするのかって理由が判ってないんじゃないか？
将来性考えて云々は分かりますが、B::Func1を拡張する時点で
何処で使われているか確認しないと、危険だって事は分かってますか?

889 ：デフォルトの名無しさん：2010/03/22(月) 01:32:34

>>888
俺たちがお前を貶めているんじゃなくて、お前が勝手に堕ちてってんだろ
悪いこと言わんからもう黙っとき

890 ：デフォルトの名無しさん：2010/03/22(月) 01:34:12

>>888
拡張って何？
メソッドの機能を後で変更する話ならラップ関数に限定した話では無いよね
話をすり替えてないか？

891 ： ◆79cfdX7bxM ：2010/03/22(月) 01:38:07

流石に>885はツッコミ入れておかないとマズイのでは…
下手すると漏れより…

892 ： ◆79cfdX7bxM ：2010/03/22(月) 01:40:01

>890

884 名前：デフォルトの名無しさん[sage] 投稿日：2010/03/22(月) 00:26:45
>>876
言いたい事は分かるけどね

プロマネが『B::Func1() は A::Func1() のラップ関数ですので
将来の事を考えて B のメソッド実装において B::Func1() を使って下さい』
~~~~~~~~~~~~~~~~

893 ：デフォルトの名無しさん：2010/03/22(月) 01:58:50

>>892
やはりラップの意味が判ってないね
『将来の事』というのは『環境の変化』を意味するのはラップの意図を理解していれば明白な事

A社が提供するライブラリ class A を使って何かの機能を実装していました
しかし、何かの理由でX社が提供するライブラリ class X を使用しないとならなくなりました
class A と class X ではインターフェイスも異なります
さて、ラッパーを噛ませないでBのメソッドがAのメソッドを直接コールしていたら修正作業はどうなりますか？
ラッパーを噛ませておいた場合はラッパー部分の修正だけで済みますけどね

後の環境変化に対して修正量を極力少なくするのがラッパーを噛ませる一番の理由だよ

そもそも Awrapper って書き方自体が変なんだよ
ラップは A を隠蔽するモノでは有るけど隠蔽対象が X になったり Y になったりした時に対応する為のもの
だから A が持つ機能で名前を付けるべきなんだよ
例えば WinSockWrapper なら winsock の機能をラップしたクラスとして妥当だけど CScokWrapper って名前にしちゃうと
意味が無いって事だね
まぁ CSock 自体が winsock をラップした様なもんだからこの例えは変だけど良いのが浮かばなかったから勘弁

894 ： ◆79cfdX7bxM ：2010/03/22(月) 02:10:56

>893
そのケースも、例えば
　class B {
　　public: Func2(){ m_pA->Func1(); }
　　private: A*m_pA;
　};
と組んでいた場合、Awrapperを用意して↑のA*を書き換えれば、
Bの修正は1箇所で済むと思いますが。
（より適切な名前を付けるなら、Aadapterとすべきでしょうか。）

しかもこの方法なら、他にAを使っているクラスがあった場合に
Awrapperを使い回せます。

895 ：デフォルトの名無しさん：2010/03/22(月) 02:20:33

>>894
勿論、B 以外のクラスでも A の機能を利用したい場合ならラッパークラスを作成するのは当然
B::Func1() はもっと手軽にラップを実現しようとした例で、もし B 以外のクラスも A を利用するならタコ実装だ

完全なラップ手法をとらなくとも用が足りてれば何の問題も無い
B::Func1() に意味が有ると言うのはそういう意味だ、いい加減に理解してくれ

896 ：デフォルトの名無しさん：2010/03/22(月) 07:14:48

今までの流れから、話の前提として在るのは「BがAを使う上でB独自の拡張を強制するためにAwrapperを作るか否か」なのに
Awrapperを他のクラスで使いまわすとか言い出すのはタコ過ぎるだろｗ

897 ：デフォルトの名無しさん：2010/03/22(月) 09:20:40

>>895-896
の書いたことは、いつもどおり通じないと思う…。
もう>>894には何も通じないとおもわれ。

Bのprivateメンバ変数を、Bがどう使うか、
BがBの都合によりどう呼び出すかは、
Bが決めることだから、
Bが用意した自分のためのprivateメソッドを、
Bが自分のために使うことは正常。

privateメソッドすら用意しなかった場合のことを考えると、
そのメリットが分かる。クラス実装上の保守性を高めている。

>>893
> そもそも Awrapper って書き方自体が変なんだよ

おれもそっちが気になる。
オブジェクト指向的に、っていうんなら、
クラス内部の実装のためのprivateメソッドがどうかというよりも、
Awrapperなんていうクラスを作ってしまうことが不気味。

898 ：砂漠の帝王 ◆.CzKQna1OU ：2010/03/22(月) 09:22:44

おまえらクズだな

899 ：デフォルトの名無しさん：2010/03/22(月) 09:52:45

>>897
ラッパーって言葉は知ってたけど、その目的や存在意義を知らなかっただけでしょ
慌てて >>894 で見当違いなレスしてきたけど、今まで書いてきた事と整合性が取れてないよ
Awrapper から B を派生するのと B がラップメソッドを持つのを比較してたりしてたんだから
そして沈黙だし...

現場を知らない学生さんと見てるけど皆さんはどう思う？

900 ：デフォルトの名無しさん：2010/03/22(月) 09:54:18

なんという衝撃的な結末。
まさか折れるとは思わなかった。

901 ：デフォルトの名無しさん：2010/03/22(月) 09:58:19

>>880
> void B::Func1() {_a->Func1();} と実装したところで、Bの他のメンバが
> a->Func1(); とFunc1を直接呼び出すのを禁止できないから、
> 集約するという役割は果たしていないと思うのですが。

イコール

折角Awrapperを実装したのに、タコ男君はBのメンバを実装中にAwrapperを無視してAへ直接アクセスしてしまいました。
これではアクセスをAwrapperに集約するという役割が果せていません。
このタコ男君にAwrapperの使用を強制するにはどうすれば良いのでしょうか？？

結論
タコ男君、明日から来なくていいよ。

902 ：デフォルトの名無しさん：2010/03/22(月) 10:04:01

>>901
ちょｗ的確な指摘だなｗ

903 ：デフォルトの名無しさん：2010/03/22(月) 10:17:06

別にもう来るなとは言わないけどね
>>541 で『こーいうのが無駄だと言いたい』ではなく『何故こーいうのが必要なんですか』ってスタンスだったら
皆優しく接してたはずだろう
なんで >>541 みたいな書き方しかできないんだろうって思うよ
誰かが書いてたけど御免なさいって言えないのも悲しいし

904 ：デフォルトの名無しさん：2010/03/22(月) 10:23:26

またこのスレ閑散としちゃうのん・・・
なんだかんだで楽しかったのに

905 ：デフォルトの名無しさん：2010/03/22(月) 10:37:50

あの発言は間違ってましたごめんなさい
じゃ無く

発言は撤回しないけどキミらが貶したいなら勝手にすれば？(訳注：俺から見るとキミらの発言は「貶し」でしかないの意)
いやまてそんなことより実は○○の方が俺より酷くないか？(訳注：やっぱり俺だけ叩かれるのはイヤだの意)
だもんなｗ

これが釣りでも一字一句意識した煽りでもないんだとしたら、本当に屑野郎としか言いようが無い

906 ：デフォルトの名無しさん：2010/03/22(月) 10:44:15

もうあとは↑みたいな何の実もない書き込みだけが続きます。

907 ：デフォルトの名無しさん：2010/03/22(月) 10:49:57

祭りは終わったんだよ…

908 ：デフォルトの名無しさん：2010/03/22(月) 10:52:49

実は沢山なってたのに
一つも口にする事が無かった◆79cfdX7bxM
合掌

909 ：デフォルトの名無しさん：2010/03/22(月) 10:56:10

ここからは底辺PG名物の「人格否定」による戦犯嬲りが初まるよ！

910 ：デフォルトの名無しさん：2010/03/22(月) 11:03:39

>>909
つ[鏡]

911 ：デフォルトの名無しさん：2010/03/22(月) 11:12:03

最後に ◆79cfdX7bxM がインドリさんなのかだけ教えてもらえないでしょうか。

912 ：デフォルトの名無しさん：2010/03/22(月) 11:42:30

> ◆79cfdX7bxM がインドリさんなのか
流石に違うと思われ
インドリは、異論・指摘のある者全てをアラシ認定して暴れるから
奴のブログや、CodeZineでの並列処理関係の連載のコメント欄見れば分かる
いや、だからといって見る事はオススメしないけど

913 ：デフォルトの名無しさん：2010/03/22(月) 11:55:19

インドリさんは他のブログまで乗りこんでくるからな。

914 ：デフォルトの名無しさん：2010/03/22(月) 17:49:19

○ンドリブログでの直近のやり取り
ttp://indori.blog32.fc2.com/blog-entry-1003.html#cm

疲れた体に一服の清涼剤・・・

915 ：デフォルトの名無しさん：2010/03/22(月) 19:05:45

限界以上に簡素にしようとして、元から同じ認識を持つ人間にしか理解出来ない無意味な糞文になってるが
別に言ってる事は、まともじゃね？

↑のURLしか見てないが
◆79cfdX7bxM＝インドリと言ってる奴は相当の節穴
技術レベルが園児と高校生位は差があるっつの
インドリ憎しで汚物を撒き散らすな

916 ：デフォルトの名無しさん：2010/03/22(月) 19:07:18

知識レベルでは差があるかもしれないが技術レベルでは似たようなもんだと思いました。

917 ：デフォルトの名無しさん：2010/03/22(月) 19:15:59

>>915
どっちが園児でどっちが高校生?
いや、素で・・・

918 ：デフォルトの名無しさん：2010/03/22(月) 19:20:49

パイソンの人はインデント議論なんてしないのかな？
聞いた話によるとパイソンのインデントはアレなようで。

919 ：デフォルトの名無しさん：2010/03/22(月) 19:30:48

>>914
ざっと読んだけど（目がちかちかする）、コメント欄でかみついてる方が何言ってるのかわからない。

並列処理で起こりうる問題点を話してるのに、グローバル変数をローカル変数に持って行ったら、
グローバルで参照しているところがみれなくなるとか、なにそれな指摘。

インドリという奴がどのコミュニティでどれだけ有名なのか、あるいは全く無名なのか知らないけど、
気に入らないならそこで叩けよ。

920 ： ◆79cfdX7bxM ：2010/03/22(月) 19:34:05

>895,897
コードの不完全さを、運用でカバーするというスタンスはどうかと思いますよ。
他に方法が無いならともかく。

>896
>Awrapperを他のクラスで使いまわすとか言い出すのはタコ過ぎるだろｗ
使い回せるってのは>893が挙げた、AがXに変わった場合のケースですよ。
個々のクラスにラップ関数用意するのは、むしろ仕事増やしてるだけでしょうに。
クラス数×関数の数だけ修正が必要って事分かってますか?

>899
>そして沈黙だし...
メーカー系勤務なので今日も出勤です。

>901
>タコ男君、明日から来なくていいよ。
むしろこちらから願い下げです。

921 ：デフォルトの名無しさん：2010/03/22(月) 19:39:49

相変わらずのブッチギリ馬鹿で安心した

922 ：デフォルトの名無しさん：2010/03/22(月) 19:40:22

DLLでは明示的に公開クラスに指定しないと使えないけど、誰もそういう話してない？
ラッパーの話になってから、両者ともすげー読みづらいので読む気大幅ダウン。
Unix/Linuxのsoだとどうなのかな？

923 ：デフォルトの名無しさん：2010/03/22(月) 19:43:11

誰もそんな話はしてないな

924 ：デフォルトの名無しさん：2010/03/22(月) 19:46:21

>>920
いい加減自分に都合の良い前提を暗黙的に出したり引っ込めたりするのを止めろ
何時Awrapperは複数のクラスから参照される事になった

925 ：デフォルトの名無しさん：2010/03/22(月) 19:48:55

ぶっちゃけ、>>869以降、◆79cfdX7bxMの方が正しげな気がする。
◆79cfdX7bxMの相手をしてる方が何を主張したいのか良く解らない。

926 ：デフォルトの名無しさん：2010/03/22(月) 19:51:59

>>925
主張すべきものは何も持ってないのであまり触らないであげて下さい。

927 ：デフォルトの名無しさん：2010/03/22(月) 19:54:37

>>861ががんばってんのかな。
>>861が何を言いたいのか良くわからん。
derrivedという単語も知らんのかいな的な疑念もあるしｗ

928 ：デフォルトの名無しさん：2010/03/22(月) 19:56:44

derived?

929 ：デフォルトの名無しさん：2010/03/22(月) 19:56:47

>>918
マゾっぽいんですね。わかります。

930 ：デフォルトの名無しさん：2010/03/22(月) 20:03:00

>>521 >>541あたりの
privateであっても主語なんたらかんたらオブジェクト指向的に間違ってるなんたらかんたらを撤回させたいだけなんだがな。
>>920
>>882で撤回したと受け取っていいの？
凄い勢いの言い訳で撤回してるか微妙。

>敢えて言うなら、コレに意味があると思う人達が居るのが問題?
一応突っ込んでおくが、そんな奴居ないから。
お前のオブジェクト指向絡みの糞解釈を否定してるだけで誰一人その糞例を肯定していない。

931 ：デフォルトの名無しさん：2010/03/22(月) 20:04:14

AWrapperを作るって、例えば生Winsock APIをラップするclass Socketを作りましたって事のメタファーじゃないの？

932 ：デフォルトの名無しさん：2010/03/22(月) 20:05:09

この流れは>>598-601で既に見た

933 ：デフォルトの名無しさん：2010/03/22(月) 20:07:48

>>931
話の発端は>>521だから、そんな解釈はありえない。常識的に考えて。

934 ：デフォルトの名無しさん：2010/03/22(月) 20:08:04

privateメンバ変数へのアクセスを、必ずsetter/getter経由で行う流儀の人たちがいるんだけど
どうなんだろ的な話題を振ってみたりして。

935 ： ◆79cfdX7bxM ：2010/03/22(月) 20:08:48

読み辛いと言う事なので書き直してみますか。
　class B {
　　public: void Func2(){ Func1(); }
　　private: void Func1(){ m_pA->Func1(); }
　　private: A*m_pA;
　};
このようなコードにおいて、Func1() の存在意義として
A* が X* に変わった場合に、Func1()で吸収できると
>893は申し上げました。要はこうできると言いたいのでしょう。
　class B {
　　public: void Func2(){ Func1(); }
　　private: void Func1(){ m_pX->Func3(); }
　　private: X* m_pX;
　};
ですが、B::Func1など用意しておかなくても、
↓のよにすれば良いはずです。
　class B {
　　public: void Func2(){ Func1(); }
　　private: void Func1(){ m_pA->Func1(); }
　　private: XA* m_pA;
　};
　class XA {
　　public: void Func1(){ m_pX->Func3(); }
　　private: X* m_pX;
　};
この方法であればB以外のクラスでもA*を使っていた場合に
XAを使い回せる（他のクラスもA*をXA*に書き換えるだけで済む）はずです。
更にBが外部からAを受け取る形で実装されている場合、
XAをAから派生させて作ればもっと手間が減らせます。

936 ：デフォルトの名無しさん：2010/03/22(月) 20:09:25

>>933
AWrapperという名前がおかしいという指摘に対する感想ね。

937 ：デフォルトの名無しさん：2010/03/22(月) 20:09:30

>>934
マルチスレッドのデバッグでログ入れたりするから普通にアリ。完。

938 ： ◆79cfdX7bxM ：2010/03/22(月) 20:11:33

>933
↓に注目。
>521
>どうしてもラッピングしたいなら、Mogeのエイリアスとなるクラスを用意して、
>そのクラスを使ってやるべき。

939 ：デフォルトの名無しさん：2010/03/22(月) 20:13:32

>>935
>>895を読んだ上で言ってるのか？

940 ：デフォルトの名無しさん：2010/03/22(月) 20:13:37

>>937
デバッグログなんか入れたら、予定外のコンテキストスイッチが起こるんじゃないか？

941 ：デフォルトの名無しさん：2010/03/22(月) 20:16:40

>>938
お前には文脈と言う概念が無いんだな。
元々Hogeクラス一つのprivateメソッドで用が足りるはずの物に対しての話だろ。
何時Hoge1,Hoge2,Hoge3が現れてそれらがfunc()の中でMogeにアクセスする話になった？
アンカしろ。

942 ：デフォルトの名無しさん：2010/03/22(月) 20:17:45

>>940
予定外のコンテキストスイッチとか言ってる時点でマルチスレッドプログラミングする資格無しｗ

943 ：デフォルトの名無しさん：2010/03/22(月) 20:18:16

>>938
class Socketを作るという方法でラッパークラスを作るというのは間違ってないのよ。
誰もそれが間違いだなんて言ってない。

問題になってるのは、privateメソッドでopen()を呼ぶのがオブジェクト指向的に間違いという主張。

944 ：デフォルトの名無しさん：2010/03/22(月) 20:20:50

ラッパー云々はどうでもいいけど、

> 問題になってるのは、privateメソッドでopen()を呼ぶのがオブジェクト指向的に間違いという主張。

ここだけ取り下げるのか取り下げないのか明確にしてくれ。

945 ：デフォルトの名無しさん：2010/03/22(月) 20:20:55

別に発生しても問題ないと思うけど。
動きかわって論理的なバグが出るなら直さなきゃならないものだし。

>>942
パフォーマンスとかの問題はあると思うけど。

946 ：デフォルトの名無しさん：2010/03/22(月) 20:23:29

デバッグログ入りだと発生しないバグというのもありそうな気がするが、まぁどうでもいい。
setter/getter使う派は、マルチスレッドなんて関係ない文脈での話ね。

947 ：デフォルトの名無しさん：2010/03/22(月) 20:25:47

>>946
そうだ、この変数の変更はイベントにしようって経験が多数あっただけだろ

948 ： ◆79cfdX7bxM ：2010/03/22(月) 20:26:56

>943-944
「オブジェクト指向的に」は既に取り下げました。
「privateメソッドでopen()を呼ぶのは間違い」は
「間違い」を「好ましくない」に改めます。

949 ：デフォルトの名無しさん：2010/03/22(月) 20:28:40

>>948
そうなんだ。やっと安心してこのスレから離脱できる。

>>947
お前、話にならんわ。

950 ：デフォルトの名無しさん：2010/03/22(月) 20:31:13

>>948
不覚にも涙が出そうになったよｗ
議論途中での間違いとかはもうどうでもいい。
俺も抜ける。

951 ：デフォルトの名無しさん：2010/03/22(月) 20:33:17

>>949
じゃあ逆にsetter/getterを使う事の問題は？パフォーマンス上の理由以外で

952 ：デフォルトの名無しさん：2010/03/22(月) 20:44:37

>>946
ビジネスロジックの「心底ウザい条件チェック」と「心底ウザい条件変更の多発」を経験してると、何だってsetter/getter経由にしたくなる

953 ：デフォルトの名無しさん：2010/03/22(月) 21:15:40

いまさら噛み付いてる奴も結構どっか問題ある連中なんだなと思う。

954 ：デフォルトの名無しさん：2010/03/22(月) 21:21:36

完全に話が終わって次の話題に移りかけてる所で蒸し返す奴も以下無限ループ

955 ：デフォルトの名無しさん：2010/03/22(月) 21:23:56

結局スレチな話題で半分埋まっちまったなぁ

956 ：デフォルトの名無しさん：2010/03/22(月) 21:38:43

何ヶ月もレスが無かったスレが言える台詞じゃないわな

と思ったが3年の歴史のあるスレがこの終り方はちょっと可哀想だわｗｗｗ

957 ： ◆79cfdX7bxM ：2010/03/22(月) 21:39:55

ごめんなさいw

958 ：デフォルトの名無しさん：2010/03/22(月) 21:49:02

このスレ2007年からなのか・・・
インデントはタブかスペースかなんてなんか長閑な話題でスタートしてたんだな。

959 ：デフォルトの名無しさん：2010/03/22(月) 22:34:13

終わりよければ全て良し。

960 ：デフォルトの名無しさん：2010/03/22(月) 22:35:36

>>951
無駄なたらい回し、ってことじゃないの？本人じゃないから真意はわからんけど。

961 ：デフォルトの名無しさん：2010/03/23(火) 00:04:02

これだからオブジェクト指向って役に立たないよな。

962 ：デフォルトの名無しさん：2010/03/23(火) 00:44:03

馬鹿の助けにはならないよね

963 ：デフォルトの名無しさん：2010/03/23(火) 00:47:22

>>951
コードが読みづらくなる。
つか、お前全部アクセッサ経由にしてるのか？

964 ：デフォルトの名無しさん：2010/03/23(火) 01:17:14

プロパティと言うステッキーな機構があるからぜんぜん読み辛くならんし

965 ：デフォルトの名無しさん：2010/03/23(火) 01:52:19

どちらも想定している言語の明示と、>934からの流れの確認をしないと
齟齬が生じると思うのだけど。

個人的にはプロパティのある言語（LLやC#）ならともかく、
C++やJava（6.x系まで）では微妙な気がする。

966 ：デフォルトの名無しさん：2010/03/23(火) 01:57:55

C++ならお得意のマクロでも使えば

967 ：デフォルトの名無しさん：2010/03/23(火) 03:18:43

プロパティなら30秒もあればアクセッサ経由に書換え可能だから、どうでもいい問題だな

968 ：デフォルトの名無しさん：2010/03/23(火) 04:05:37

コーディングの話ではなく設計の話だが、
設計から導かれる setter/getter は良い setter/getter。
実装から導かれる setter/getter は悪い setter/getter。

969 ：デフォルトの名無しさん：2010/03/23(火) 04:07:13

ちょっと意味が分からん

970 ：934：2010/03/23(火) 11:21:23

悪い、C++での話ね。

俺的にはいいも悪いも評価保留中だけど、それってどうなの的な話題ふり。
この議論は『Smalltalk Best Practice Patterns』が初出らしいんだけど、Smalltalk固有の
何かが関係しているのかどうかは不明。

ただ、俺が読んだ話（何で読んだかは忘れた）では、C++でprivateメンバ変数を
必ずアクセッサ経由で呼ぶという流派があって、その理由の一つは継承先で
getterを遅延評価に変えたりする可能性があるかららしい。

俺としては、そういう流派の人がもしいたら理由を聞きたい的なレベル。

971 ：934：2010/03/23(火) 11:22:31

つまり、コーディング規約で、privateメンバ変数にアクセスするときは、必ずアクセッサ経由にすること、
みたいな規約だったらどう思う？的なこと。

972 ：デフォルトの名無しさん：2010/03/23(火) 11:24:26

どうでもいい

973 ：デフォルトの名無しさん：2010/03/23(火) 11:29:53

的的うるせーよ

974 ：デフォルトの名無しさん：2010/03/23(火) 11:50:36

いいんじゃないの？
今時のコンパイラなら空のアクセサを直接アクセスへのコード展開ぐらいしてくれるだろうし。

975 ：デフォルトの名無しさん：2010/03/23(火) 11:54:16

アクセッサなら良くて>>541なら駄目というのはこれいかに。

976 ：デフォルトの名無しさん：2010/03/23(火) 12:00:47

アクセッサというからには、少なくともprotectedだろ。そこが>>541とは違う。

977 ：デフォルトの名無しさん：2010/03/23(火) 14:19:22

>>970
> その理由の一つは継承先で
> getterを遅延評価に変えたりする可能性があるかららしい。

サブクラスがスーパークラスの getter に変更を加えるってピンと来ないな
privateメンバの getter でしょ、protectedメンバじゃなくて

978 ：デフォルトの名無しさん：2010/03/23(火) 14:24:06

> サブクラスがスーパークラスの getter に変更を加えるってピンと来ないな

フツーにオーバーライドでは？

> privateメンバの getter でしょ、protectedメンバじゃなくて

えっ？

979 ：デフォルトの名無しさん：2010/03/23(火) 14:38:39

>>977
privateのsetter/getterって誰がアクセスするの？

980 ：デフォルトの名無しさん：2010/03/23(火) 14:56:47

はてしなく、どうでもいい話題。
アホを釣り上げて叩こうって意図？

981 ：デフォルトの名無しさん：2010/03/23(火) 17:56:12

public メンバ変数は必ず private のバッキングストア作ってアクセサ作れ
そしてクラス内でバッキングストアにアクセスするときもアクセサ使え、
って主張とちゃうの？是非はともかく。

1)
class Person {
public int age; // アクセサなんぞいらんわ
void aging() { age++; }
}

2)
class Person {
private int age;
public int getAge() { return age; }
public void setAge(int age){ this.age = age; }
public aging() { age++; } // private にアクセサ使うとか・・・
}

3)
class Person {
private int age;
public int getAge() { return age; }
public void setAge(int age){ this.age = age; }
public aging() { setAge(getAge() + 1); } // 継承対策っすよ
}

982 ：934：2010/03/23(火) 18:04:48

>>981
全てのprivateメンバ変数に対するアクセスもsetter/getterを経由しろってのは、
Personの例でいえばこんな感じ。

class Person {
public:
void setName(const char* name) {
　if (ミドルネームが存在したら) {
　　// isMiddleNameExist = true; こうはせずに
　　setIsMiddleNameExist(true);　// こうしろ
　}
}
protected:
virtual void setIsMiddleNameExist(bool b) {
　isMiddleNameExist = b;
}
private:
bool isMiddleNameExist;
}

983 ：934：2010/03/23(火) 18:05:57

>>981の3)に付け加えて、publicで公開しないものも含めてって意味。

984 ：デフォルトの名無しさん：2010/03/23(火) 18:24:09

継承先で書き換えを期待してるかしてないか、または
クラス内でもフィールドの仕様が安定してないとかで変わるんじゃないの？

virtual 付けてたり、final みたいなオーバーライド禁止付けたりしないんであれば
アクセサ経由じゃないとオーバーライドの内容次第じゃおかしなことになるんじゃない？

985 ：デフォルトの名無しさん：2010/03/23(火) 20:23:03

お客様が仕様ですの中で暮らしているか
仕様は仕様の中で暮らしているかの違い

986 ：デフォルトの名無しさん：2010/03/23(火) 23:59:18

ひょっとして、みんなprivateメンバまできっちり設計とかしてんの？

987 ：デフォルトの名無しさん：2010/03/24(水) 00:14:32

↑しても意味が無いから変更に強いコーディングスタイルにしたいんだろ
それはもう手間の面でしか判断できん

988 ：デフォルトの名無しさん：2010/03/24(水) 00:27:40

>>984
virtual付けないとオーバーライドできないけど？