1001コメント339KB

コーディング規約第3条

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2007/02/04(日) 23:28:42

カッコの位置や変数名のつけ方から、何で規約なんて決めるのという話まで
コーディング規約・スタイルに関するスレ

前スレ

コーディング規約第2条
http://pc10.2ch.net/test/read.cgi/tech/1068752664/

0002デフォルトの名無しさん

2007/02/05(月) 00:24:35

ずるしてらくしてかれいに２げっとかしらかしら～

0003デフォルトの名無しさん

2007/02/05(月) 11:52:53

3ゲットですぅ

0004デフォルトの名無しさん

2007/02/05(月) 13:34:58

for ( int cnt = 3; cnt < EOThread; cnt++ )
{

0005デフォルトの名無しさん

2007/02/05(月) 16:34:21

break;

0006デフォルトの名無しさん

2007/02/05(月) 17:10:48

}
printf("%d", cnt);

0007デフォルトの名無しさん

2007/02/05(月) 17:30:28

printf("監督の背番号は%dです\n", cnt);

0008デフォルトの名無しさん

2007/02/05(月) 17:54:27

cnt はカントクの略ですか?

0009デフォルトの名無しさん

2007/02/05(月) 20:05:29

http://pc10.2ch.net/test/read.cgi/tech/1068752664/991

ﾜﾛﾀｗ

0010デフォルトの名無しさん

2007/02/05(月) 21:34:46

GNUみたいにスペースとタブを混在したりしなければ何でもいいなあ
てゆーかインデントレベル2でタブ幅8はやめてくださいおながいします

0011デフォルトの名無しさん

2007/02/05(月) 21:40:30

プロジェクト内で統一されてるならそれで。

0012デフォルトの名無しさん

2007/02/06(火) 10:47:20

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

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

0013デフォルトの名無しさん

2007/02/06(火) 17:35:42

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

0014デフォルトの名無しさん

2007/02/06(火) 18:23:12

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

0015デフォルトの名無しさん

2007/02/06(火) 18:42:19

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

0016デフォルトの名無しさん

2007/02/06(火) 19:32:25

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

0017デフォルトの名無しさん

2007/02/06(火) 19:39:50

VCのデフォルト派

0018デフォルトの名無しさん

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;

0019デフォルトの名無しさん

2007/02/06(火) 21:14:59

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

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

0020デフォルトの名無しさん

2007/02/06(火) 21:58:24

>>19
すこしずれてる

0021デフォルトの名無しさん

2007/02/06(火) 22:29:53

>>18
俺は

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

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

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

0022デフォルトの名無しさん

2007/02/06(火) 23:12:34

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

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

0023デフォルトの名無しさん

2007/02/06(火) 23:34:43

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

0024デフォルトの名無しさん

2007/02/06(火) 23:46:51

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

0025デフォルトの名無しさん

2007/02/07(水) 00:52:06

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

0026デフォルトの名無しさん

2007/02/07(水) 01:00:41

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

0027デフォルトの名無しさん

2007/02/07(水) 03:21:27

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

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

0028デフォルトの名無しさん

2007/02/07(水) 03:30:31

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

0029デフォルトの名無しさん

2007/02/07(水) 03:38:16

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

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

0030デフォルトの名無しさん

2007/02/07(水) 07:54:28

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

0031デフォルトの名無しさん

2007/02/07(水) 09:22:23

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

0032デフォルトの名無しさん

2007/02/07(水) 10:09:26

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

0033デフォルトの名無しさん

2007/02/07(水) 10:51:29

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

0034デフォルトの名無しさん

2007/02/07(水) 10:52:26

はいはい、そうですか。

0035デフォルトの名無しさん

2007/02/07(水) 12:10:12

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

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

0036デフォルトの名無しさん

2007/02/07(水) 12:12:32

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

0037デフォルトの名無しさん

2007/02/07(水) 12:37:07

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

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

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

0038デフォルトの名無しさん

2007/02/07(水) 12:38:43

うーむ、そうかそうか。

0039デフォルトの名無しさん

2007/02/07(水) 13:21:16

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

0040デフォルトの名無しさん

2007/02/07(水) 13:25:56

そんなもんあるかボケェ

0041デフォルトの名無しさん

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のとかもあるな。

0042デフォルトの名無しさん

2007/02/07(水) 16:35:13

GNUキモいな

0043デフォルトの名無しさん

2007/02/07(水) 17:18:07

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

0044デフォルトの名無しさん

2007/02/07(水) 18:07:33

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

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

0045デフォルトの名無しさん

2007/02/07(水) 20:07:06

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

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

0046デフォルトの名無しさん

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

0047デフォルトの名無しさん

2007/02/07(水) 22:53:35

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

0048デフォルトの名無しさん

2007/02/07(水) 23:13:59

TABな人です。

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

0049デフォルトの名無しさん

2007/02/08(木) 00:23:01

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

0050デフォルトの名無しさん

2007/02/08(木) 02:47:20

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

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

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

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

0051デフォルトの名無しさん

2007/02/08(木) 06:34:06

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

0052デフォルトの名無しさん

2007/02/08(木) 14:08:08

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

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

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

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

0053デフォルトの名無しさん

2007/02/08(木) 16:30:10

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

0054デフォルトの名無しさん

2007/02/08(木) 21:57:34

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

0055デフォルトの名無しさん

2007/02/09(金) 04:31:13

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

0056デフォルトの名無しさん

2007/02/09(金) 07:26:37

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

くらいで解決できそう。

0057デフォルトの名無しさん

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>};

0058デフォルトの名無しさん

2007/02/09(金) 16:13:50

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

0059デフォルトの名無しさん

2007/02/09(金) 20:07:14

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

0060デフォルトの名無しさん

2007/02/09(金) 20:57:01

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

0061デフォルトの名無しさん

2007/02/10(土) 02:21:33

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

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

0062デフォルトの名無しさん

2007/02/10(土) 02:22:05

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

0063デフォルトの名無しさん

2007/02/10(土) 02:25:49

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

0064デフォルトの名無しさん

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
};

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

0065デフォルトの名無しさん

2007/02/10(土) 12:22:00

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

0066デフォルトの名無しさん

2007/02/10(土) 12:52:45

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

0067デフォルトの名無しさん

2007/02/10(土) 13:01:35

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

0068デフォルトの名無しさん

2007/02/10(土) 13:03:21

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

0069デフォルトの名無しさん

2007/02/10(土) 13:07:45

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

0070デフォルトの名無しさん

2007/02/10(土) 13:40:11

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

0071デフォルトの名無しさん

2007/02/10(土) 13:49:46

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

0072デフォルトの名無しさん

2007/02/10(土) 14:12:43

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

0073デフォルトの名無しさん

2007/02/10(土) 14:38:29

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

0074デフォルトの名無しさん

2007/02/10(土) 15:34:14

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

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

0075デフォルトの名無しさん

2007/02/10(土) 16:29:50

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

0076デフォルトの名無しさん

2007/02/10(土) 16:30:22

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

0077デフォルトの名無しさん

2007/02/10(土) 16:36:58

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

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

0078デフォルトの名無しさん

2007/02/11(日) 01:28:35

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

0079デフォルトの名無しさん

2007/02/11(日) 02:09:36

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

0080デフォルトの名無しさん

2007/02/15(木) 11:03:40

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

0081デフォルトの名無しさん

2007/03/12(月) 01:51:52

indent

0082デフォルトの名無しさん

2007/03/12(月) 03:04:05

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

0083デフォルトの名無しさん

2007/03/13(火) 23:50:45

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

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

0084・∀・）っ-○◎●

2007/03/14(水) 00:44:27

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

ってばっちゃが言ってた

0085・∀・）っ-○◎●

2007/03/14(水) 01:31:56

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

0086デフォルトの名無しさん

2007/03/14(水) 05:29:57

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

0087デフォルトの名無しさん

2007/03/14(水) 05:50:47

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

0088デフォルトの名無しさん

2007/03/14(水) 05:58:41

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

0089デフォルトの名無しさん

2007/03/14(水) 06:15:43

デイヴ・カトﾁｬﾝ

0090デフォルトの名無しさん

2007/03/14(水) 08:14:01

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

0091デフォルトの名無しさん

2007/03/14(水) 09:13:06

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

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

0092デフォルトの名無しさん

2007/03/14(水) 14:06:04

>>91
激しく同意

0093デフォルトの名無しさん

2007/03/14(水) 23:21:44

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

HWND hWnd;

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

HWND windowHandle;

でいいはずだが。

0094デフォルトの名無しさん

2007/03/14(水) 23:41:47

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

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

0095・∀・）っ-○◎●

2007/03/15(木) 00:09:41

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

0096デフォルトの名無しさん

2007/03/15(木) 03:32:04

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

0097デフォルトの名無しさん

2007/03/15(木) 04:08:24

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

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

0098デフォルトの名無しさん

2007/03/15(木) 05:04:25

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

0099デフォルトの名無しさん

2007/03/15(木) 05:25:13

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

0100デフォルトの名無しさん

2007/03/15(木) 09:10:00

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

0101デフォルトの名無しさん

2007/03/15(木) 09:51:22

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

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

0102デフォルトの名無しさん

2007/03/15(木) 10:15:28

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

0103デフォルトの名無しさん

2007/03/15(木) 10:21:36

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

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

0104デフォルトの名無しさん

2007/03/15(木) 10:31:57

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

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

0105デフォルトの名無しさん

2007/03/15(木) 11:02:06

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

0106デフォルトの名無しさん

2007/03/16(金) 20:26:03

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

0107デフォルトの名無しさん

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のスタイルは一応理にかなってはいるなと思っただけ。

0108デフォルトの名無しさん

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のスタイルは一応理にかなってはいるなと思っただけ。

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

0109・∀・）っ-○◎●

2007/03/17(土) 23:45:16

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

0110デフォルトの名無しさん

2007/03/18(日) 00:07:54

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

0111デフォルトの名無しさん

2007/03/18(日) 00:20:47

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

0112デフォルトの名無しさん

2007/03/18(日) 00:24:12

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

0113デフォルトの名無しさん

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 リーナスたん

0114デフォルトの名無しさん

2007/03/18(日) 01:23:23

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

0115108

2007/03/18(日) 02:14:49

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

0116デフォルトの名無しさん

2007/03/18(日) 09:17:27

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

0117デフォルトの名無しさん

2007/03/18(日) 14:04:35

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

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

GNUはやっぱキモイわ

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

0118デフォルトの名無しさん

2007/03/18(日) 15:32:05

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

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

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

0119デフォルトの名無しさん

2007/03/18(日) 15:36:57

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

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

0120デフォルトの名無しさん

2007/03/18(日) 15:38:38

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

0121デフォルトの名無しさん

2007/03/18(日) 15:59:53

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

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

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

0122デフォルトの名無しさん

2007/03/18(日) 16:32:19

GNUよりも>>118がキモイ

0123デフォルトの名無しさん

2007/03/18(日) 16:38:14

結論：>>118はキモイ

0124デフォルトの名無しさん

2007/03/18(日) 23:11:13

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

0125デフォルトの名無しさん

2007/03/18(日) 23:19:30

>>118のキモさに泣いた

0126デフォルトの名無しさん

2007/03/18(日) 23:54:09

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

0127デフォルトの名無しさん

2007/03/18(日) 23:58:36

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

0128デフォルトの名無しさん

2007/03/19(月) 00:03:09

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

0129デフォルトの名無しさん

2007/03/19(月) 11:06:30

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

0130デフォルトの名無しさん

2007/03/19(月) 13:00:16

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

0131デフォルトの名無しさん

2007/03/19(月) 15:56:43

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

0132デフォルトの名無しさん

2007/03/19(月) 22:09:09

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

0133デフォルトの名無しさん

2007/03/20(火) 01:27:02

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

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

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

0134デフォルトの名無しさん

2007/04/10(火) 13:58:05

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

0135デフォルトの名無しさん

2007/04/10(火) 14:49:21

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

0136デフォルトの名無しさん

2007/04/29(日) 03:20:35

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

0137デフォルトの名無しさん

2007/04/29(日) 07:21:40

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

0138デフォルトの名無しさん

2007/05/01(火) 03:41:22

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

0139デフォルトの名無しさん

2007/05/09(水) 03:02:45

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

0140デフォルトの名無しさん

2007/05/09(水) 03:13:07

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

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

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

0141デフォルトの名無しさん

2007/05/09(水) 03:15:14

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

0142デフォルトの名無しさん

2007/05/09(水) 03:16:50

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

0143デフォルトの名無しさん

2007/05/09(水) 03:18:15

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

0144デフォルトの名無しさん

2007/05/09(水) 03:20:35

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

0145デフォルトの名無しさん

2007/05/09(水) 03:33:15

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

0146デフォルトの名無しさん

2007/05/09(水) 13:41:49

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

0147デフォルトの名無しさん

2007/05/09(水) 14:05:50

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

0148デフォルトの名無しさん

2007/05/09(水) 18:05:54

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

0149デフォルトの名無しさん

2007/05/09(水) 19:42:35

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

0150デフォルトの名無しさん

2007/05/09(水) 21:31:46

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

0151デフォルトの名無しさん

2007/05/09(水) 21:34:24

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

0152デフォルトの名無しさん

2007/05/09(水) 21:39:04

日本語おｋ

0153デフォルトの名無しさん

2007/05/09(水) 21:59:36

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

0154デフォルトの名無しさん

2007/05/09(水) 22:07:17

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

0155デフォルトの名無しさん

2007/05/09(水) 22:11:06

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

0156デフォルトの名無しさん

2007/05/09(水) 22:34:40

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

0157デフォルトの名無しさん

2007/05/09(水) 22:36:15

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

0158デフォルトの名無しさん

2007/05/10(木) 00:26:29

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

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

0159デフォルトの名無しさん

2007/05/10(木) 13:35:57

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

0160デフォルトの名無しさん

2007/05/10(木) 14:57:56

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

0161デフォルトの名無しさん

2007/05/11(金) 02:03:18

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

0162デフォルトの名無しさん

2007/05/11(金) 02:52:04

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

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

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

0163デフォルトの名無しさん

2007/05/14(月) 13:48:41

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

かな。

0164デフォルトの名無しさん

2007/05/14(月) 21:40:44

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

0165デフォルトの名無しさん

2007/05/14(月) 23:26:27

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

0166デフォルトの名無しさん

2007/05/15(火) 02:20:54

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

0167デフォルトの名無しさん

2007/05/15(火) 21:43:21

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

0168デフォルトの名無しさん

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) が付くアンダースコアで始まる名前は、
> ある目的のために実装によって予約されています。
> 　アンダースコアで始まる名前は、グローバルな名前空間で使う名前として実装によって予約されています。

0169デフォルトの名無しさん

2007/05/16(水) 08:11:48

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

0170デフォルトの名無しさん

2007/05/16(水) 08:27:30

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

0171デフォルトの名無しさん

2007/05/16(水) 09:11:58

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

0172デフォルトの名無しさん

2007/05/16(水) 12:50:24

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

0173デフォルトの名無しさん

2007/05/16(水) 14:45:20

ほしゆ

0174デフォルトの名無しさん

2007/05/21(月) 04:21:30

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

0175デフォルトの名無しさん

2007/05/21(月) 10:20:53

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

0176デフォルトの名無しさん

2007/05/21(月) 10:25:26

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

0177デフォルトの名無しさん

2007/05/21(月) 13:07:30

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

0178デフォルトの名無しさん

2007/05/21(月) 13:33:11

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

0179デフォルトの名無しさん

2007/05/21(月) 13:51:21

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

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

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

0180デフォルトの名無しさん

2007/05/21(月) 14:43:03

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

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

0181178

2007/05/21(月) 15:01:39

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

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

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

0182デフォルトの名無しさん

2007/05/22(火) 15:38:32

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

0183デフォルトの名無しさん

2007/05/22(火) 19:08:06

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

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

0184デフォルトの名無しさん

2007/05/22(火) 20:21:39

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

0185デフォルトの名無しさん

2007/05/23(水) 00:14:54

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

0186175

2007/05/23(水) 01:40:16

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

0187デフォルトの名無しさん

2007/05/23(水) 05:03:55

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

0188デフォルトの名無しさん

2007/05/23(水) 06:51:31

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

0189デフォルトの名無しさん

2007/05/23(水) 13:52:32

機械語

0190デフォルトの名無しさん

2007/05/30(水) 08:01:29

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

0191デフォルトの名無しさん

2007/05/30(水) 08:23:20

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

0192デフォルトの名無しさん

2007/06/02(土) 00:19:25

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

0193デフォルトの名無しさん

2007/06/02(土) 00:25:52

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

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

0194デフォルトの名無しさん

2007/06/02(土) 00:41:42

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

0195デフォルトの名無しさん

2007/06/03(日) 21:19:31

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

0196デフォルトの名無しさん

2007/06/20(水) 05:09:57

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

0197デフォルトの名無しさん

2007/06/20(水) 11:45:17

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

0198デフォルトの名無しさん

2007/06/20(水) 16:30:30

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

0199デフォルトの名無しさん

2007/06/20(水) 16:37:28

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

0200デフォルトの名無しさん

2007/06/21(木) 20:07:08

>>199
おーrrらー

0201デフォルトの名無しさん

2007/06/28(木) 01:08:52

今までこう書いてたけど

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

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

0202デフォルトの名無しさん

2007/06/28(木) 01:33:07

C#だけど結局

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

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

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

0203デフォルトの名無しさん

2007/06/28(木) 23:17:56

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

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

0204デフォルトの名無しさん

2007/06/29(金) 00:11:27

MS的にNGな気がする。

0205デフォルトの名無しさん

2007/06/29(金) 01:18:09

>>163氏の命名法で

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

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

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

0206デフォルトの名無しさん

2007/06/29(金) 10:02:57

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

0207デフォルトの名無しさん

2007/06/29(金) 12:44:20

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

0208デフォルトの名無しさん

2007/07/01(日) 18:08:36

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

0209デフォルトの名無しさん

2007/07/01(日) 20:11:36

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

0210デフォルトの名無しさん

2007/07/16(月) 02:29:48

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

0211デフォルトの名無しさん

2007/07/16(月) 03:07:50

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

0212デフォルトの名無しさん

2007/08/16(木) 16:52:56

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

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

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

0213デフォルトの名無しさん

2007/08/17(金) 01:04:30

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

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

0214212

2007/08/17(金) 03:18:25

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

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

0215デフォルトの名無しさん

2007/08/18(土) 00:09:00

TypeIdとかTypeNoとか。

0216デフォルトの名無しさん

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++でもそうしたいんですが、
（メイヤーズ先生も小文字で始めてるし）
どうもここがちょっと引っかかって。

0217デフォルトの名無しさん

2007/08/24(金) 04:29:23

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

0218デフォルトの名無しさん

2007/08/24(金) 10:53:28

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

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

0219デフォルトの名無しさん

2007/08/25(土) 00:44:34

_*
m_*
がいいよ。

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

0220デフォルトの名無しさん

2007/08/25(土) 01:21:18

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

0221デフォルトの名無しさん

2007/08/25(土) 01:27:52

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

0222デフォルトの名無しさん

2007/08/25(土) 01:32:37

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

0223デフォルトの名無しさん

2007/08/25(土) 01:35:48

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

0224デフォルトの名無しさん

2007/08/25(土) 03:11:13

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

0225デフォルトの名無しさん

2007/08/25(土) 03:16:23

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

0226デフォルトの名無しさん

2007/08/25(土) 06:17:51

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

0227デフォルトの名無しさん

2007/08/25(土) 09:51:01

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

0228デフォルトの名無しさん

2007/08/25(土) 09:53:05

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

0229227

2007/08/25(土) 11:29:28

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

0230デフォルトの名無しさん

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 の間違えようがない。

0231デフォルトの名無しさん

2007/08/25(土) 22:37:30

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

0232227

2007/08/26(日) 00:16:02

>>231
やめなさいｗ

0233デフォルトの名無しさん

2007/08/26(日) 01:06:27

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

0234デフォルトの名無しさん

2007/08/26(日) 20:47:53

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

0235デフォルトの名無しさん

2007/08/26(日) 21:13:48

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

0236デフォルトの名無しさん

2007/08/27(月) 00:31:17

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

0237デフォルトの名無しさん

2007/08/27(月) 00:41:08

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

0238デフォルトの名無しさん

2007/08/27(月) 01:24:03

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

0239デフォルトの名無しさん

2007/08/31(金) 23:34:42

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

0240デフォルトの名無しさん

2007/09/01(土) 22:41:02

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

0241デフォルトの名無しさん

2007/09/04(火) 00:15:46

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

0242デフォルトの名無しさん

2007/09/04(火) 00:38:14

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

0243241

2007/09/05(水) 00:12:31

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

0244デフォルトの名無しさん

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;}
};

0245デフォルトの名無しさん

2007/09/06(木) 00:18:43

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

0246デフォルトの名無しさん

2007/09/06(木) 00:54:42

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

0247デフォルトの名無しさん

2007/09/06(木) 01:14:03

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

0248デフォルトの名無しさん

2007/09/06(木) 20:24:05

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

0249デフォルトの名無しさん

2007/09/07(金) 13:03:53

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

0250デフォルトの名無しさん

2007/09/08(土) 00:21:38

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

0251デフォルトの名無しさん

2007/09/18(火) 16:57:12

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

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

0252デフォルトの名無しさん

2007/09/20(木) 02:06:24

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

02531/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);
    }
}

02542/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;
    }
}

0255デフォルトの名無しさん

2007/10/05(金) 00:58:07

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

0256デフォルトの名無しさん

2007/10/05(金) 01:31:13

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

0257デフォルトの名無しさん

2007/10/05(金) 01:58:23

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

0258デフォルトの名無しさん

2007/10/05(金) 03:18:25

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

0259デフォルトの名無しさん

2007/10/05(金) 03:53:45

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

0260デフォルトの名無しさん

2007/10/05(金) 05:18:48

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

0261デフォルトの名無しさん

2007/10/05(金) 15:25:15

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

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

0262デフォルトの名無しさん

2007/10/05(金) 15:26:27

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

0263デフォルトの名無しさん

2007/10/05(金) 19:00:26

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

0264デフォルトの名無しさん

2007/10/05(金) 20:10:40

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

0265デフォルトの名無しさん

2007/10/09(火) 15:59:59

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

0266デフォルトの名無しさん

2007/10/09(火) 20:15:56

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

0267デフォルトの名無しさん

2007/10/09(火) 20:35:42

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

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

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

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

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

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

0268デフォルトの名無しさん

2007/10/23(火) 19:22:00

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

0269デフォルトの名無しさん

2007/12/15(土) 02:35:34

　private:
　　bool isHoge_;

だけでなく、

　private:
　　void doHoge_();

とか、

　template<class Hoge_>

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

0270デフォルトの名無しさん

2007/12/15(土) 02:39:55

>>269
どうして？

0271デフォルトの名無しさん

2007/12/15(土) 03:03:06

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

0272デフォルトの名無しさん

2007/12/15(土) 03:44:57

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

0273デフォルトの名無しさん

2007/12/15(土) 04:41:14

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

0274デフォルトの名無しさん

2007/12/15(土) 04:59:49

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

0275デフォルトの名無しさん

2007/12/15(土) 07:12:05

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

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

0276227

2007/12/15(土) 07:45:38

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

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

0277デフォルトの名無しさん

2007/12/15(土) 09:53:59

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

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

0278デフォルトの名無しさん

2007/12/15(土) 10:26:40

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

0279デフォルトの名無しさん

2007/12/15(土) 11:02:48

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

0280デフォルトの名無しさん

2007/12/15(土) 12:33:25

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

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

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

0281227

2007/12/15(土) 12:39:05

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

0282デフォルトの名無しさん

2007/12/15(土) 12:49:04

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

0283デフォルトの名無しさん

2007/12/15(土) 12:57:38

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

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

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

0284デフォルトの名無しさん

2007/12/15(土) 13:28:58

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

0285デフォルトの名無しさん

2007/12/15(土) 13:56:19

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

0286デフォルトの名無しさん

2007/12/15(土) 15:40:04

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

0287デフォルトの名無しさん

2007/12/15(土) 23:55:12

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

0288デフォルトの名無しさん

2007/12/16(日) 00:04:35

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

0289デフォルトの名無しさん

2007/12/16(日) 01:34:46

ﾅｲｼﾌｫﾛｰ

0290デフォルトの名無しさん

2007/12/16(日) 01:42:20

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

0291デフォルトの名無しさん

2007/12/16(日) 02:50:52

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

0292デフォルトの名無しさん

2007/12/16(日) 07:00:04

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

0293デフォルトの名無しさん

2007/12/16(日) 07:04:09

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

0294デフォルトの名無しさん

2007/12/16(日) 11:04:04

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

0295デフォルトの名無しさん

2007/12/16(日) 11:26:03

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

0296デフォルトの名無しさん

2007/12/16(日) 13:52:19

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

0297296

2007/12/16(日) 13:58:19

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

0298デフォルトの名無しさん

2007/12/16(日) 13:59:11

>>296
>281-282 にある

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

の例じゃね？

0299デフォルトの名無しさん

2007/12/16(日) 15:05:06

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

0300デフォルトの名無しさん

2007/12/17(月) 02:42:38

っ >168

0301デフォルトの名無しさん

2007/12/17(月) 02:50:17

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

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

0302デフォルトの名無しさん

2007/12/17(月) 02:54:48

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

0303デフォルトの名無しさん

2007/12/17(月) 08:01:37

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

0304デフォルトの名無しさん

2007/12/17(月) 08:05:56

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

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

0305デフォルトの名無しさん

2007/12/17(月) 11:48:40

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

0306デフォルトの名無しさん

2007/12/17(月) 15:58:27

>>303
_STDLIB_H_

0307デフォルトの名無しさん

2007/12/18(火) 00:11:07

>>305
それならわかるわ

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

0308デフォルトの名無しさん

2007/12/18(火) 06:32:30

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

0309デフォルトの名無しさん

2007/12/18(火) 08:17:39

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

0310デフォルトの名無しさん

2007/12/18(火) 08:33:41

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

0311デフォルトの名無しさん

2007/12/18(火) 11:31:02

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

0312デフォルトの名無しさん

2007/12/18(火) 11:46:38

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

0313デフォルトの名無しさん

2007/12/18(火) 12:17:43

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

0314デフォルトの名無しさん

2007/12/18(火) 12:21:59

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

0315デフォルトの名無しさん

2007/12/18(火) 22:50:44

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

0316デフォルトの名無しさん

2007/12/19(水) 05:46:36

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

例えが、ちがうか；

0317デフォルトの名無しさん

2007/12/23(日) 23:54:01

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

0318デフォルトの名無しさん

2007/12/25(火) 07:53:47

あ、そうそうそうすると

#ifndef _FILENAME_H
#define _FILENAME_H

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

#define H_FILENAME_H

とか？( ﾟдﾟ)

0319デフォルトの名無しさん

2007/12/25(火) 10:30:28

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

0320デフォルトの名無しさん

2007/12/26(水) 04:02:28

MACRO_OF_*は却下

0321デフォルトの名無しさん

2007/12/26(水) 04:09:12

#pragma onceでいいよもう

0322デフォルトの名無しさん

2007/12/26(水) 04:10:30

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

0323デフォルトの名無しさん

2007/12/29(土) 11:30:30

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

0324デフォルトの名無しさん

2007/12/29(土) 13:41:22

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

0325デフォルトの名無しさん

2007/12/30(日) 00:07:39

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

0326デフォルトの名無しさん

2008/02/19(火) 01:14:20

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

0327デフォルトの名無しさん

2008/02/19(火) 14:45:58

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

0328デフォルトの名無しさん

2008/03/16(日) 18:09:35

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

0329デフォルトの名無しさん

2008/04/13(日) 15:16:47

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

0330デフォルトの名無しさん

2008/07/28(月) 01:19:20

http://lolo.jp/orecode/

0331デフォルトの名無しさん

2008/07/30(水) 22:41:39

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

0332デフォルトの名無しさん

2008/08/07(木) 15:47:21

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

0333デフォルトの名無しさん

2008/08/09(土) 21:26:02

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

0334デフォルトの名無しさん

2008/08/09(土) 22:46:42

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

0335デフォルトの名無しさん

2008/08/25(月) 00:22:16

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

0336デフォルトの名無しさん

2008/10/01(水) 21:55:22

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

0337デフォルトの名無しさん

2008/10/01(水) 21:56:36

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

0338デフォルトの名無しさん

2008/10/01(水) 23:43:18

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

0339デフォルトの名無しさん

2008/10/02(木) 00:07:24

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

0340デフォルトの名無しさん

2008/10/02(木) 00:08:04

↑*追加しといて

0341デフォルトの名無しさん

2008/10/02(木) 20:45:35

\w じゃダメだろ。

0342デフォルトの名無しさん

2008/10/03(金) 01:01:52

じゃあ
operator\wktk=

0343デフォルトの名無しさん

2008/10/09(木) 08:01:21

elevaterⅡ
escalator⊿

0344デフォルトの名無しさん

2009/01/09(金) 01:29:10

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

0345デフォルトの名無しさん

2009/01/10(土) 21:16:17

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

0346デフォルトの名無しさん

2009/02/08(日) 11:22:25

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

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

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

0347デフォルトの名無しさん

2009/02/08(日) 16:00:56

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

0348デフォルトの名無しさん

2009/02/08(日) 20:56:10

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

0349デフォルトの名無しさん

2009/02/08(日) 21:59:11

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

0350デフォルトの名無しさん

2009/02/09(月) 00:02:37

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

0351デフォルトの名無しさん

2009/02/09(月) 02:15:38

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

0352デフォルトの名無しさん

2009/02/09(月) 10:51:44

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

0353デフォルトの名無しさん

2009/02/09(月) 15:12:23

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

class A {
public:
　　int i;

0354デフォルトの名無しさん

2009/02/09(月) 15:13:48

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

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

0355デフォルトの名無しさん

2009/02/09(月) 20:43:15

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

0356デフォルトの名無しさん

2009/02/10(火) 12:27:33

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

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

0357デフォルトの名無しさん

2009/02/10(火) 19:13:10

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

0358デフォルトの名無しさん

2009/02/10(火) 20:36:18

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

0359デフォルトの名無しさん

2009/02/10(火) 20:39:51

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

0360デフォルトの名無しさん

2009/02/10(火) 21:25:10

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

0361デフォルトの名無しさん

2009/02/10(火) 21:51:51

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

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

0362デフォルトの名無しさん

2009/02/10(火) 22:25:03

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

0363デフォルトの名無しさん

2009/02/10(火) 22:54:59

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

0364デフォルトの名無しさん

2009/02/10(火) 23:59:01

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

0365デフォルトの名無しさん

2009/02/11(水) 03:25:36

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

0366デフォルトの名無しさん

2009/02/11(水) 15:14:16

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

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

0367デフォルトの名無しさん

2009/02/11(水) 16:01:04

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

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

0368デフォルトの名無しさん

2009/02/11(水) 16:29:45

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

0369デフォルトの名無しさん

2009/02/11(水) 16:36:56

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

0370デフォルトの名無しさん

2009/02/11(水) 19:04:31

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

0371367

2009/02/11(水) 20:56:18

>>370
どこからその発想が出てきたのか分かりませんが
そんな人がもしいたら馬鹿ですね。同意です。

0372366

2009/02/12(木) 00:35:22

>>367
いやいや、統合環境でもがつがつ組むときだけテキストエディタを使ってる
私は、フリーだし
誰かの面倒見るときでも、基本的には個人の自由と思ってる

0373デフォルトの名無しさん

2009/02/12(木) 07:55:52

>>371
お前のレスから出た発想に決まってるだろ低脳

0374デフォルトの名無しさん

2009/02/12(木) 08:14:58

おやおや

0375デフォルトの名無しさん

2009/02/12(木) 08:25:47

暇つぶしに煽ったら皮肉で返されて逆ギレっすかｗ

0376デフォルトの名無しさん

2009/02/20(金) 19:25:27

規約とはちょっと違うかもしれないけど、他に聞くとこないのでここでいいかい？
コードを管理するディレクトリ構成のことなんだけど、
ソースとヘッダーを同じディレクトリに入れてる人っているかな？
ライブラリのコードならヘッダーのディレクトリを分離しなきゃいけないだろうけど、
そうじゃなければ一緒にした方がやりやすいってやってるところもあるのかな？

0377デフォルトの名無しさん

2009/02/20(金) 19:54:54

好きなようにしたらいいと思うぞ。どっちにしても大した問題はないように思える。

0378デフォルトの名無しさん

2009/02/20(金) 20:12:40

いちいち分けないだろ

0379デフォルトの名無しさん

2009/02/20(金) 21:29:58

分けないのか？

0380デフォルトの名無しさん

2009/02/20(金) 21:33:59

IDEにおまかせ。

0381デフォルトの名無しさん

2009/02/20(金) 21:53:41

ライブラリでも配布時にヘッダ取り出せばいいし
必要とメリットに応じて。でいいんじゃない？　自分は分けてない

0382デフォルトの名無しさん

2009/02/21(土) 00:52:52

分けてない人多いのか

ところで今さらだけど、こんな記事あった
ttp://blog.scriptionary.com/2009/01/21/hungarian-notation-what-to-do/

0383デフォルトの名無しさん

2009/02/21(土) 01:02:05

いや、多いかは知らないぞｗ　書き込んだ２人は分けてないってだけだからなｗ

0384デフォルトの名無しさん

2009/02/21(土) 01:08:30

分ける意味がわからん

0385デフォルトの名無しさん

2009/02/21(土) 01:15:42

ハンガリアン表記法はコーディングの手間になるから使わない
ただ、ポインタとグローバル変数にはpとかg_をつけてる。取り扱い注意的な意味で。

0386デフォルトの名無しさん

2009/02/21(土) 01:16:25

複数のコンポーネントからなるプロジェクトの場合は、コンポーネントごとにディレクトリを作って
なおかつ、共通で使うヘッダファイルのディレクトリも作る。
コンポーネント内部でしか使わないヘッダファイルは、コンポーネントのディレクトリに入れる。

0387デフォルトの名無しさん

2009/02/21(土) 01:30:43

ハンガリアン表記法ね
Cの時は使ってる、C++とかオブジェクト指向系の言語だと考えちゃうね

0388デフォルトの名無しさん

2009/02/21(土) 01:33:46

>>385
コーディングの手間になるから使ってる
意識する分だけ誤りが少ないし、検索するときユニークになりやすい
同じ意味で型を変換したい時には楽

0389デフォルトの名無しさん

2009/02/21(土) 01:33:57

コメントの書き方で
flag = true; //フラグを立てる
とかいうのは意味ないと思う。コードを見ればすぐ分かることを書くのは無駄。

コメントはある程度のまとまったコードに対して、どういう意味があるかを書くと、いちいちコードを解析する手間が省けるから役に立つ。

疑問があるのは、コメントにコードの変更日と変更者を記入してるタイプ。役に立ったことがないんだが、役に立つんかね

0390デフォルトの名無しさん

2009/02/21(土) 01:45:12

10年20年使われるコードでは役に立つときもある

0391デフォルトの名無しさん

2009/02/21(土) 01:46:15

80 名前：デフォルトの名無しさん[sage] 投稿日：2007/11/08(木) 19:23:34
昔も似たようなスレあったな
俺はシステムハンガリアンも有効だとレスした
IDEによる入力サポートとか、カーソルあわせての型情報とか一切無い環境もあるからな
ってか俺のとこそうだし
と書いても理解してもらえなかった。
多分ここでも理解してもらえないなｗ

この意見をどう思う？

0392デフォルトの名無しさん

2009/02/21(土) 01:47:50

>>389
納品した後の修正とかなら書くよ

0393デフォルトの名無しさん

2009/02/21(土) 02:00:33

>>391
まずはWindows APIみたいにバンバンtypedefしろ。

0394デフォルトの名無しさん

2009/02/21(土) 02:06:37

>>391
役に立つならそれはそれでありだと思う。
よほどチープな機材しかない職場なんだろうな。

0395デフォルトの名無しさん

2009/02/21(土) 02:11:41

>>389 には完全に同意だ
とくに

>疑問があるのは、コメントにコードの変更日と変更者を記入してるタイプ。役に立ったことがないんだが、役に立つんかね

には泣くほど同意見だ。
読みにくいったらないよ。
SCMがあるのになぜコメントで書くのか

0396デフォルトの名無しさん

2009/02/21(土) 02:15:24

>>389
＞とかいうのは意味ないと思う。コードを見ればすぐ分かることを書くのは無駄。
まったく同意ｗ
//このフラグはここでのみ立つので、～ほにゃらら
とか書くならよいのだが、やってることを書くのはほんとアホ

＞コメントにコードの変更日と変更者を記入してるタイプ。
おれも役に立ったことがない、コードが読みにくいだけ
だれがどう変えたにせよ、今手を入れるのは自分なんだし
いまさら前任者を恨んでどうするって感じだわｗ
ファイルヘッダに履歴があれば充分って思う

0397デフォルトの名無しさん

2009/02/21(土) 02:15:29

バージョン管理なんて使わせてくれないところかもしれないだろ。
いや、SCMがあってもそういうのを書かされる話は聞くが。

0398デフォルトの名無しさん

2009/02/21(土) 02:41:39

>>395
> SCMがあるのになぜコメントで書くのか
どこにでもリポジトリがあるわけじゃありません。

0399デフォルトの名無しさん

2009/02/21(土) 02:43:12

あー、こいつが追加変更したところだから要注意だな、みたいなことはある。

0400デフォルトの名無しさん

2009/02/21(土) 02:54:24

いまどきソフトウェア開発プロジェクトでSCMを使わない以上の罪悪を探すのは難しいけどね

0401デフォルトの名無しさん

2009/02/21(土) 03:26:36

>>394
CodeWarriorというものがあってだな…

0402デフォルトの名無しさん

2009/02/21(土) 03:47:41

>>396
変更日・変更者コメントは、同時進行で進んでいるソース流用プロジェクトが、
流用元の最近の変更と自分たちの変更を区別するために欲しがっていたな。

0403デフォルトの名無しさん

2009/02/21(土) 03:53:56

>>401
組込のIDEには入力支援や型情報ポップアップがないって意味？
俺のとこではエディタとして別のIDE使ってたよ。組込の環境は使いにくいｗ

0404デフォルトの名無しさん

2009/02/21(土) 04:15:35

アセンブラだとメモリにどう入っているか分かるほうが楽

0405デフォルトの名無しさん

2009/02/21(土) 15:04:56

CodeWarrior のクソっぷりはなんとかならんか

0406デフォルトの名無しさん

2009/02/21(土) 17:25:27

>コードを見ればすぐ分かることを書くのは無駄。

アルゴリズムやデータ構造は知ってても、コードは読めんと言う相手と
連携しなきゃならん場合は必要だぞ。

具体的に例を挙げると、↓みたいなコードを、相手方にチェックしてもらうには
「読んで字のごとし」なコードもすごく重要。
・別言語で作ったアプリが吐いたデータを、整合性を崩さないように編集するコード
・ハードウェアを直接叩くコード

0407デフォルトの名無しさん

2009/02/21(土) 17:49:42

それは、「コードを見ればすぐ分かる」ことじゃない。

0408デフォルトの名無しさん

2009/02/21(土) 19:21:45

コードをみればすぐ分かるってのは、誰でも言語の知識だけでコードからすぐに読みとれること、と言い換えたら理解しやすいかもしれんな。
自分の知識ですぐ分かること、ではないぞｗ　言語以外の知識やその行付近以外の知識を必要とする時点ですでに「すぐ分かること」ではない。

例えばこういう感じ
*((volatile char*)0xF860) = 0;　　　//&HF860番地にゼロを書く　　←無駄なコメント

*((volatile char*)0xF860) = 0;　　　//VDPリセット　　←知識があれば分かることだが役にたつコメント

0409デフォルトの名無しさん

2009/02/21(土) 19:41:39

>>408
>*((volatile char*)0xF860) = 0;　　　//VDPリセット　　←知識があれば分かることだが役にたつコメント
これはコードをみればわかることじゃあないと思うな
0を入れるのか、リセットするのか、クリアするのかは、意味が少々違うからな

「文字」「文字値」「文字配列」「文字列」の違いみたいなものも結構気になる

0410デフォルトの名無しさん

2009/02/21(土) 20:10:39

>>409
コードを見れば分かる無駄なコメント　に対する　役立つものの例として、という意味ね
「そこにゼロ書けばVDPがリセットされる」って知識がある人には、例の２つは同じ「コードをみればすぐ分かるコメント」に見えるかもしれない
でも、>>389で言っている「コードをみればすぐ分かるコメント」ってのは前者（ゼロを書く）であって、後者（リセット）のコメントの付け方ではないよ。
という説明のつもりだったｗ

0411デフォルトの名無しさん

2009/02/21(土) 21:15:41

#define VDP_ADDRESS (volatile char*)0xF860
#define RESET 0

*(VDP_ADDRESS) = RESET;

0412409

2009/02/21(土) 21:32:26

>>410
同意

>>411
そうそう、オレならそうする。

0413デフォルトの名無しさん

2009/02/21(土) 22:23:07

#define VDP_ADDRESS ((volatile char*)0xF860)
#define RESET 0
#define RESET_VDP() *VDP_ADDRESS = RESET

RESET_VDP();

0414デフォルトの名無しさん

2009/02/22(日) 01:06:49

マクロ地獄だな

0415409

2009/02/22(日) 01:09:28

>>411は、レジスタのアクセスだけなのがわかるが、
>>413だと、いくつかのシーケンスが内蔵されているように見えるね

該当のレジスタに他の値を入れることがたびたびあって、この行でリセットをしたいなら、明示的な>>411
該当のレジスタには、他でアクセスすることがなく、ここでリセットするだけなら>>413だな

0416デフォルトの名無しさん

2009/02/22(日) 17:45:00

皆さんのお知恵をお借りしにきますた

どっかの本かWEBで、ブーリアンの引数名にはNoとかNotはつけるな
ってあったんだけど、みなさんどう思いますか？
例えばbool NoScrollとか

0417デフォルトの名無しさん

2009/02/22(日) 17:57:32

>>416
賛成の反対で、これでいいのだｗ

0418デフォルトの名無しさん

2009/02/22(日) 18:08:30

>>416
本とか読んでる訳じゃないから、俺の感覚だと…

別にbool型なんだから
NoScrollにtrue入れるか、Scrollにfalse入れるかでしょ
それなら、コード中でどう使うかで使い分ければいいんじゃない

絶対に、NoScrollを主体で判断した方がいい部分で使われるのが分っているなら
NoScrollとすれば良い

それ以外で、Scrollという状態をtrue or falseで見る使い方なら
わざわざフラグを反転させる意味にしない方か良いと思う

0419デフォルトの名無しさん

2009/02/22(日) 19:02:30

>>418
どうもありがとうございます
その本だかによれば、ブーリアンは意味的に「～する」の肯定で統一したほうが混乱が少ない、みたいなことを根拠にしてました
そうやって統一すると、何かを「する」場合はtrue、「しない」場合はfalseを指定すれば良くなる、と

マァ自分的にも個々の使い分けでいいと思いました

0420デフォルトの名無しさん

2009/02/22(日) 19:22:24

>>419
直感的に、True(真)なのにNo(否定)っていうのが誤りの元にならないかってことだよね。
"できるだけ"避けるべきだとは思うなぁ

ちょっとオレが変かもしれないけど
電気ポットの注ぎ口なんかよくハッとする
「赤」なのに「出る」のが気持ち悪い

0421デフォルトの名無しさん

2009/02/22(日) 19:37:12

混在させるより統一した方がいいとは思うけどどっちでもいいと思えるほどの些細なことに見える。

0422デフォルトの名無しさん

2009/02/22(日) 19:49:32

>>420
赤＝危険という風に見ればいい

0423デフォルトの名無しさん

2009/02/22(日) 20:23:15

>>416
否定後禁止ルールは、isとかcanとか三人単数ルールとかと併用しないと意味不明になりがちだと思う。
その場合ならCanScrollとかScrollsとか。

0424デフォルトの名無しさん

2009/02/22(日) 20:25:59

酷い日本語すみませぬ…。
×否定後 → ○否定語
×三人単数 → ○三人称単数

0425420

2009/02/22(日) 20:35:41

>>422
それはわかってるんだけどねｗ
出すことを前提に操作してるのに「赤」になるのがとてもアフォーざんす

0426デフォルトの名無しさん

2009/02/22(日) 22:22:51

なして？

0427デフォルトの名無しさん

2009/02/22(日) 22:55:00

信号機だと赤は停止の色だから？

0428デフォルトの名無しさん

2009/02/22(日) 23:15:36

・水は青、お湯は赤
・熱いから危険だから赤

0429デフォルトの名無しさん

2009/02/22(日) 23:22:32

>425
そこは「お湯を注ごうとしてる人」とは違うアクターを想像するんだ。
例えば「ポットを運ぼうとしてる人」とか。

0430デフォルトの名無しさん

2009/02/23(月) 00:52:59

>>429
わかっちゃいるんだけどね、例えば、車で
アクセルを踏むと赤いランプが点くとしたら、、、気持ち悪いよね
そんな感じ

0431デフォルトの名無しさん

2009/02/23(月) 01:06:41

そのつまんねー自分語り、いつまで続けるつもり？

0432デフォルトの名無しさん

2009/02/23(月) 01:19:19

>>431
レスがある限りｗ

0433デフォルトの名無しさん

2009/02/23(月) 02:49:40

>>431
2ちゃん歴浅いんか？
嫌ならお前が別の話題を振ればいい。

0434デフォルトの名無しさん

2009/02/23(月) 09:35:12

>>433
2ちゃん歴浅いんか？
気に入らないレスならスルーしろ。

0435デフォルトの名無しさん

2009/02/23(月) 13:06:16

おまえここは初めてか？力抜けよ。

0436デフォルトの名無しさん

2009/02/23(月) 13:28:14

420うぜーぞ

0437デフォルトの名無しさん

2009/02/23(月) 16:51:41

スルーしろといってる本人がスルーできてない

0438デフォルトの名無しさん

2009/02/23(月) 17:23:41

ｵﾏｴﾓﾅｰ

0439デフォルトの名無しさん

2009/02/23(月) 20:53:40

　　　　　　　,;:'';,　　　　　,;:' '; 　
　　　　　　,;'':.:.　';,,,.,.,.,.,.,;:' 　　'; 　　　
　　　　　､:´: .　　　　　　　　　　':,　　　
　　　　,':.:..:. .　　　　　　　　　　　':,　　　　ま、お茶でも飲んで休憩すれ。
　　　　';:.:.:.:.. ／　　　　　　＼　':, 　
　　　 ';::.:.:.:. .　●　　　　　　●　　;'　
　　　　';:::.::.:.　　　（__人__）　　　;'
　　　　　'':;,:.:.:.:.:. . 　　　　　　､:'　　　　　　　　　　　　（　(
　　　　　,;:'':.:.:. 　　　　　　　　 '::,,.,.,.,.,,.,,_　　　　　　　　ヽヽ
　　　　 ,;':::: ::　　　　　　　　　　　　　　　`()＼; _＿O＿_ 　)ノ
　　　 ,;'　;:.:.　　;,　　　　　　.:.''_,.,,.,.,.,.,.,.,_,:'" ＼/=￣￣ =ソ,ﾌi!
　　 ,;'　 ;;:.:.　　 ;,　　　　　;;''　　　　　　　　 {= = = = =イ .i!
　　 ;'　　 ';;:.:.　　;,　　　　;:'　　　　　　　　　　ﾞ､_= = =_ノ　 i!　
　　;,　　　 ';,　　 ,;　　　 ;'　　　　　　　　　　　￣￣　┌―‐┐～
　　;,　　　　ﾞﾞ''''''"　　　　;　　　　　　　　　　　　　　　　　　{　茶　}
　　:;　　　　;'''"ﾞﾞ'';:　　　:;　　　　　　　　　　　　　　　　　　ﾍニニﾉ
　　:;　　　　;　　 ;:　　　;　　　　　　　　　　　　　　　||￣￣￣￣￣￣￣||
　　':,　　　 ,;　　:;　　　 :;　　　　　　　　　　　　 ||　　　　　　　 ||
　　ﾞﾞ''''''''''"　　　ﾞﾞ''''''''''"

0440デフォルトの名無しさん

2009/02/24(火) 00:23:49

いや、俺はスルーしろなんて言ってないしなあ
命令しといて自分はやらない人につっこみ入れただけだしなあ。

0441デフォルトの名無しさん

2009/02/24(火) 00:26:10

レス乞食

0442デフォルトの名無しさん

2009/02/24(火) 00:30:51

呼んだ？

0443デフォルトの名無しさん

2009/03/02(月) 01:19:09

コメントに愚痴とかいいわけ書いてるやついるよなｗ
そういうヤツのコードは１関数１５００行とかスパゲッティな依存関係とかすごく汚いコードだったｗ
そんな事書くくらいならコードの可読性をあげるコメントを書けと

0444デフォルトの名無しさん

2009/03/03(火) 01:33:42

パスカル記法ってただ頭を大文字にするだけ？
ハンガリアンみたいに詳細に説明してるサイトがないからそれしかわからん

0445デフォルトの名無しさん

2009/03/03(火) 10:05:24

>>444
>パスカル記法ってただ頭を大文字にするだけ？

そんだけ。

0446デフォルトの名無しさん

2009/03/14(土) 12:19:31

おまいらtypedefどう思う？

いちいちtypedefしてんじゃねーよカスが。

0447デフォルトの名無しさん

2009/03/14(土) 12:50:46

なんでもかんでもtypedefするカス
typedefしなきゃ書けないコードを知らずに全否定するカス

0448デフォルトの名無しさん

2009/03/14(土) 15:23:25

批判 [編集]

一部の人々は、typedefを広範に使用することに反対している。
ほとんどの議論は、typedefは単に変数の実際のデータ型を隠すだけであるという考えに集中する。
例えば、Linuxカーネルハッカーであり、ドキュメント作成を行っているGreg Kroah-Hartmanは、
関数プロトタイプ宣言を除いて、typedefの使用をやめさせようとしている。
彼は、typedefを使用することが、必要以上にコードを混乱させるだけでなく、
プログラマが巨大な構造体を単純な型と誤認識して使用してしまうことがあると主張している[1]。

0449デフォルトの名無しさん

2009/03/14(土) 17:34:56

>>448
どこからの引用なのか書けや

0450デフォルトの名無しさん

2009/03/14(土) 18:04:54

ここだな。
ttp://ja.wikipedia.org/wiki/Typedef#.E6.89.B9.E5.88.A4

0451デフォルトの名無しさん

2009/03/14(土) 18:17:03

>>446
typedefはCとC++ではまったく事情が違う。
C++でテンプレートメタプログラミングするなら必須

0452デフォルトの名無しさん

2009/04/19(日) 16:03:42

そうかなあ

0453デフォルトの名無しさん

2009/04/19(日) 22:00:52

そうだよお

0454デフォルトの名無しさん

2009/05/29(金) 15:01:49

>>451
<>の中が書きにくいとか一行が長くなるとか？

0455デフォルトの名無しさん

2009/05/29(金) 15:58:01

trait

0456デフォルトの名無しさん

2009/05/29(金) 21:46:05

>>454
超大雑把に言うと、
データを渡すために変数が必要なように、型を渡すためにtypedefが必要だということ。
身近な例だとstd::vectorのvalue_typeとか。

0457デフォルトの名無しさん

2009/06/05(金) 03:28:55

自分がメンテするわけでもないコードにコメントなんか書かない。
マクロも定義もしない。
リリースまで立ち会えば、あとは、プリプロセッサを通した綺麗なソースだけを
残す。
後のヤツは苦しめ。俺のときは動いたんだから、それを動かせないのはおまぃらが
ドン臭いからだ。

これが派遣渡り鳥の現実です。

0458デフォルトの名無しさん

2009/06/05(金) 23:57:54

>>457
こいつ最低だな。
たいした能力も無いくせに・・・。
派遣雇うような環境なら周りはレベル低いやつばかりだろうから、自ずと自分の
能力が高いとか思いこむんだろう。
こう言うのが人生負け組、嫌われ者で、同じ所から二度と仕事の依頼がないんだろうな。

0459デフォルトの名無しさん

2009/06/06(土) 00:47:50

プリプロセッサがどうのっていう奴がそんなに変なコードを書くわけが無いだろ
まあネタでしょ

0460デフォルトの名無しさん

2009/06/06(土) 05:06:08

最低だの能力が低いだのとクサしていればいいさ。
メンテナンスの必要な間の雇用が保証されて給料の支払われる正社員の方はそういうメンテナンスしやすい
コードを引けば良いんだから、その分みっちり支払ってコメントかかせればいいよ。

その場限りで使い捨て搾取するんだから、その場限りのコードしか渡されないのは、やむなし。
同じところからの仕事の依頼なんてハナから期待していない。他の仕事していれば、断らざるを得ないし、
間を空けずに次の仕事を言ってくるのに派遣でつないでるようなろくでもない経営者と働くのはそもそも
イヤだしな。
ま、どうしても困ったときには呼んでくれ。土日スポット料金でおもくそ吹っかけてやんよ。

……くらいのものかな。

0461デフォルトの名無しさん

2009/06/07(日) 20:05:58

>>460
このひねくれ具合、もうだめだねこりゃ。

0462デフォルトの名無しさん

2009/06/07(日) 21:31:53

気持ちは分からなくもない
ドキュメントもなし、前時代のコーディング規約を押し付けて、ごてごて盛り付けていったような既存のコードの改造で、
テストまでこちらにやらせて、不具合だ未実装だと難癖付けて、ズルズル拘束しておきながら、なにげに機能追加まで盛り込んで
支払いもゴネたうえに、使い捨てるようなクライアントには、そんな対応でもしてやりたくなるわな

0463デフォルトの名無しさん

2009/06/08(月) 01:02:02

プリプロセッサを通したソースって、「綺麗なソース」って言うんかいな？
（Ｃのプリプロセッサの事だよな？）

何もかも展開されて、これを「はい、ソースです」って提出するのはありえんと思う
がそうでも無いのか？

0464デフォルトの名無しさん

2009/06/08(月) 03:20:39

バイナリ必須、ソースは形式的に納入するだけでおｋという場合もあるし。

0465デフォルトの名無しさん

2009/06/08(月) 11:57:24

メンテナンスが必要になるであろう部分を派遣でどうにかしようということ自体が
間違ってるんではないの？

0466デフォルトの名無しさん

2009/06/08(月) 16:11:06

>>465
メンテが必要ないプログラムってあるのか？

0467デフォルトの名無しさん

2009/06/08(月) 17:30:51

だっらプログラムを派遣に書かせることが誤りだ。

0468デフォルトの名無しさん

2009/06/08(月) 21:32:02

>>467
社員にそれだけの能力がある会社がどれだけあるんだかｗ

0469デフォルトの名無しさん

2009/06/08(月) 21:46:59

そろそろ言ってもいいよね？

マ板でやれ

0470デフォルトの名無しさん

2009/06/09(火) 02:43:33

一般的に、社員と派遣とどっちが技術高いの？

0471デフォルトの名無しさん

2009/06/09(火) 06:35:18

>>470
一言で言えば、いろいろ。
社員だけで足りないから、外に頼む。
外に頼むと、いらんやつがもれなくついてきたりする。
システムの規模によるが、数人～十数人規模のシステムなら
賢いところは、会社と付き合わずに、個人を特定して捕まえておく。
いいコードは、製品というより作品。
どんなにドキュメントをそろえても
作った会社にメンテを頼むより、作った個人にやらせるほうが数十倍早くて正確だから。

0472デフォルトの名無しさん

2009/07/01(水) 23:02:00

クラス内のメンバの記述順ってどうしてる？
フィールド変数・プライベートメソッド・
パブリックメソッド・パブリックプロパティ順にすると
宣言と使用箇所が離れて見にくいし
宣言と使用箇所を近くするにも限界がある
散らかした部屋の中みたい
使っている言語はC#

Delphiだと宣言がいやでもまとまるので見やすかった
実現部はIDE任せでアルファベット順だった

0473デフォルトの名無しさん

2009/07/02(木) 00:02:31

>>472
C# の場合は、Visual Studio のクラスビューの並びに合わせてる。

0474デフォルトの名無しさん

2009/07/02(木) 00:48:06

メソッド・プロパティ・フィールド・イベントのアルファベット順か
決めてしまえば迷うこともないかな、やってみる

0475デフォルトの名無しさん

2009/07/03(金) 13:15:12

あれこれ考えるより、多少理屈に合わなくても機械的に決めちゃったほうが楽だよな。

0476デフォルトの名無しさん

2009/07/03(金) 18:34:59

後でどうとでもなるものは、比較的どうでもいいというか、後で考える。
書くときは気の向くまま、というと変だが、気にしないで書いて、あとで整形するから気にしない。

0477ゴロゴロ

2009/09/11(金) 21:12:39

XML を定義するときって、要素の名前は
<ABC> と <abc> のどっちがいいと思いますか？
どっちが一般的でしょうか？

0478デフォルトの名無しさん

2009/09/11(金) 23:06:19

>>477
XML のタグは大文字・小文字を区別するから、どちらか
一方に統一するのではなく、Pasacl 記法で命名してる。

タグの大文字小文字の区別、使える文字を教えて
http://www.atmarkit.co.jp/fxml/askxmlexpert/011tagname/11tagname.html

もし一方に統一する必要があるなら、XHTML などに倣っ
て小文字にするだろう。

0479デフォルトの名無しさん

2009/09/12(土) 13:26:03

やっぱり俺式コーディング規約って言語ごとに別々に作るもんなの？
それとも一個汎用的なの作ったら、あらゆる言語でそれをつき通すもんなのかな

0480デフォルトの名無しさん

2009/09/12(土) 22:16:40

あらゆる言語で突き通す馬鹿とは、できれば一緒に仕事したくないな。

0481デフォルトの名無しさん

2009/09/13(日) 23:42:41

>>479
似た様な言語なら流用するじゃないの。
例えば、Javaのコーディング規約をC#に流用するとか。マイクロソフト標準とちとずれるかもしれないけど。

0482デフォルトの名無しさん

2009/10/19(月) 01:40:22

C++でfunction_name()のように小文字＋アンダースコアの関数名って異端ですか？

0483デフォルトの名無しさん

2009/10/19(月) 01:46:55

Stroustrupがバリバリ使ってる

0484デフォルトの名無しさん

2009/10/19(月) 16:17:04

>>482
オレはそればっかり
一方、変数は頭大文字

0485デフォルトの名無しさん

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);

それぞれの長所と短所を教えてくらさい
一番長所が多いＯＲ一番短所が少ないやつにします

0486デフォルトの名無しさん

2009/11/25(水) 19:27:17

>>485
Enableって聞くと単にbool型変数の値を変更するだけじゃなく、有効にするための処理も含まれてると想像するけど。
それなら3)。
単にbool型変数の値を変更するだけなら1)かなぁ。

0487デフォルトの名無しさん

2009/11/25(水) 20:21:04

EnableXXXにすれ

0488デフォルトの名無しさん

2009/11/25(水) 20:40:51

本筋じゃないけど、属性としては enabled にしたいなあ。

0489デフォルトの名無しさん

2009/11/26(木) 01:05:56

>>485
> C++ でboolのメンバ変数を設定・参照したいんだけど

実装から名前を決めようなんて考えてる時点で根本的に間違ってる。

0490デフォルトの名無しさん

2009/11/29(日) 21:04:22

>>485
5)
bool set(int id, bool val);
bool get(int id);

１～４は変数増えたら API も増えるだろ。
生成時間もメモリ消費量も無駄に増える。

0491デフォルトの名無しさん

2009/11/29(日) 21:06:01

>>490
せめてidはenumにしろ。

0492デフォルトの名無しさん

2009/11/29(日) 21:15:44

まあ enum でも int でも char * でもいいね。

ただ、enum にするとコンパイラの最適化で short に
されちゃったりすることがある。組み込みの armcc とか。

複数のコンパイラが混在する場合は int か u32_t
みたいに CPU で決まる型にしておくのがいいよ。

0493デフォルトの名無しさん

2009/11/29(日) 23:09:00

コンパイラ規約に則ったコーディング規約か、意識したことないな

0494デフォルトの名無しさん

2009/11/30(月) 16:51:00

型チェックしたくない?

0495デフォルトの名無しさん

2009/11/30(月) 16:56:08

>>492
enumの肝は、妙なidをコンパイルエラーにしてくれるところジャマイカ?

0496デフォルトの名無しさん

2009/11/30(月) 17:02:08

>>495
C++だとチェック入るけど、Cだと実質整数だったような。

0497デフォルトの名無しさん

2009/11/30(月) 18:23:34

警告ぐらいは出たっけかなぁ・・・?

と思って gcc で試したけど、enum の型に無茶な数値入れても
警告最大だろうがなんだろうが何も言われなかった。

0498デフォルトの名無しさん

2009/11/30(月) 22:14:10

コンパイラが警告を出すか微妙な線だな。
lintなら警告するんだけど。

0499デフォルトの名無しさん

2009/12/02(水) 01:02:07

enum を signed で扱うか unsigned で扱うかも微妙で、
フラグに 0x80000000 立てるのが大好きな人にはウケが悪い。

みんな、ちゃんと -Wextra つけてるか？

if (err < 0) って書いて err が unsigned int
だったりすると恥ずかしいぞｗ

0500デフォルトの名無しさん

2009/12/02(水) 20:54:14

今どきエラーを数値で判定する男の人って…

0501デフォルトの名無しさん

2009/12/02(水) 22:23:24

処理系によっちゃ数値で判断するところもあるんじゃね？

0502デフォルトの名無しさん

2009/12/03(木) 01:22:31

中身が数値でも定数と判定しろよ、ってことじゃないの。
if (err != E_OK) とか。

0503デフォルトの名無しさん

2009/12/03(木) 02:14:26

Linux とかだと普通にあるな。

0504デフォルトの名無しさん

2010/03/05(金) 15:28:36

C++のグローバルスコープ解決演算子ってどうしてる？
（ネストしてるnamespaceで外側のスコープの解決とかも）

1. 出来るだけ解決演算子を付ける
2. 出来るだけ解決演算子を付けない
3. 名前が重複しがちな関数とか、特定のものだけ注意して付ける

俺はあんまりつけてないんだけど、何にでも付けてる人もいるし、
付けた方がいいよってガイドラインでもあるのかね。

自分の中での取り決めとか、例外とかもあれば教えてくれるとうれし

0505デフォルトの名無しさん

2010/03/06(土) 01:07:48

>>504
1 はウザすぎ、 2 はちょっとウザいことがあるかもしれない、 3 はスタイルとして成立してない。

グローバルスコープ解決演算子をどうする、とか考えるんじゃなくて、要らないものが
書いてあって見づらいなら消せばいいという当たり前の話で済まないのか？

0506デフォルトの名無しさん

2010/03/06(土) 17:15:16

2 だな。

つか、グローバルはご先祖様みたいなもんで身内と
同等の扱いだろ。

どうせ、頻繁に :: つけないといけないような実装は
他でも override とか static 忘れでバグ頻発するような
レベルのコードしか書けない奴。

0507デフォルトの名無しさん

2010/03/07(日) 01:01:21

付けるそのものにメリットがある訳じゃないが、
インテリセンス使ってる時は付けた方が便利ゆえ、
付けない事を強制するのもどうかと思う。

そもそも強制したってメリットの無いルールを強制するのは
労力の無駄遣いだと思う。
コンパイラ等でチェックできるならばしても良いとは思うけど。

0508デフォルトの名無しさん

2010/03/07(日) 21:27:31

わしは Windows のプログラム書かんから
つけないけど利便性があがるんなら
つけてもいいよ。

でも Cライブラリや Win32 API と同じ名前の関数を
自分のクラスに作るのは許さん。たとえ open/close であっても。

0509デフォルトの名無しさん

2010/03/08(月) 00:49:41

OpenやCloseならいいんですね？わかります。

0510デフォルトの名無しさん

2010/03/08(月) 04:07:55

>>508
お前とは一緒に仕事したくないわｗ

0511デフォルトの名無しさん

2010/03/08(月) 08:47:23

規約裁定時は宗教戦争が公式に認められる瞬間だからな。

0512デフォルトの名無しさん

2010/03/09(火) 22:22:49

無駄なたらい回しを否定する意味で言ってるなら508の意見には同意。
たまに m_pMember->Hoge(); を Hoge(); と短縮するのが目的みたいな
ラッパー関数が存在するが、正直止めて欲しい。

0513デフォルトの名無しさん

2010/03/09(火) 22:58:13

Hoge->m_pMember() を Member() だよね？言いたいことって。

0514デフォルトの名無しさん

2010/03/10(水) 01:55:58

>>509
CLibrary::open(char *file) {
return open(file, O_RDONLY);
}
みたいなのを書く奴がおるんよ。。。

0515デフォルトの名無しさん

2010/03/10(水) 03:06:15

>>514
そのコードの何が問題？

0516デフォルトの名無しさん

2010/03/10(水) 03:44:26

>>514
やはりお前とは仕事したくないでござる

0517デフォルトの名無しさん

2010/03/10(水) 07:29:32

C++ならそれぐらい普通だろ

0518デフォルトの名無しさん

2010/03/10(水) 07:49:22

>>514 の不人気さにわろた

0519デフォルトの名無しさん

2010/03/10(水) 07:53:57

「無駄なたらい回し」という発想がわからない。
リファクタリング読んだ？

0520デフォルトの名無しさん

2010/03/10(水) 10:30:12

Windowsの関数はマクロで別名付けたりしてるから、
SendMessageとかいう関数を作ったら、実はSendMessageWって名前になってました、とかあるよね。

0521デフォルトの名無しさん

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のエイリアスとなるクラスを用意して、
そのクラスを使ってやるべき。

0522デフォルトの名無しさん

2010/03/11(木) 01:08:46

>>521 「たらい回し」は関係ないな。

0523デフォルトの名無しさん

2010/03/11(木) 01:18:58

>>521
おいおい、このご時勢にどんだけ時代遅れなんだよ

0524デフォルトの名無しさん

2010/03/11(木) 01:22:11

>Hogeを主語とすると不自然なものは、privateであってもメンバに加えるべきじゃない。
伝説級の迷言
デザパタの半数以上がオブジェクト指向的に間違ってるらしい。

0525デフォルトの名無しさん

2010/03/11(木) 01:25:24

>>515-517
ダメだな。基本がなってない。

0526デフォルトの名無しさん

2010/03/11(木) 02:37:28

>>521
そのスタンスで何か一つでもアプリを作れたら報告してください。
最終的にあらゆるオブジェクトがお互いの参照を持たないことになるわけですが。

0527デフォルトの名無しさん

2010/03/11(木) 09:02:05

>>521
委譲って言葉を知ってるか？

0528デフォルトの名無しさん

2010/03/11(木) 09:41:11

いまんとこ>>527のツッコミが一番的確でスマート。

0529デフォルトの名無しさん

2010/03/11(木) 22:32:31

>>521とは絶対に一緒に仕事したくない

0530521

2010/03/11(木) 22:45:42

>521
>Hogeを主語とすると不自然なものは、privateであってもメンバに加えるべきじゃない。
不正確で誤解を招く表現だったので訂正&補足。

Hogeを主語とすると不自然な「関数」は、privateであってもメンバに加えるべきじゃない。
より適切なクラスに持たせて、そのクラスのオブジェクトなり参照なりを持つようにすべき。

一応文脈的に「もの」=「関数」と読み取って欲しいところだけど、
暴論過ぎますな。すんません。

0531デフォルトの名無しさん

2010/03/11(木) 23:41:15

そこ突っ込まれてると思ったのかｗ

0532521

2010/03/12(金) 01:25:02

>531
ここじゃなかったら何だろうね。
もしかしたら>521のようなコードを、「全て」否定してると勘違いしてる?
否定してるのは「クラスが関数の主語として不適切な場合」だけだけど。
ProxyやFacadeのようなパターンは否定していない。
（これらは委譲先のクラスの別称あるいは総称であり、主語として適切）

0533521

2010/03/12(金) 01:30:03

追記。
もっともProxyやFacadeのようなパターンの場合、>521のようにラッパー関数が
privateになる事はほとんど無いと思うけどね。

0534デフォルトの名無しさん

2010/03/12(金) 04:55:35

すごいな
どんどんトンチンカンになっていく

0535デフォルトの名無しさん

2010/03/12(金) 11:19:06

>>521
同僚にお前って鳩山系だよなって言われない？

0536デフォルトの名無しさん

2010/03/12(金) 14:32:08

もうやめとけ。

0537デフォルトの名無しさん

2010/03/12(金) 15:28:04

>>521=>>514なのか？

だとしたら、なぜ>>514を良くないと考えるのか、HogeとかMogeとかfunc抽象的な話をせずに、
>>514のコードがどのような理由で良くないのか、ずばっと主張してくれ。

0538デフォルトの名無しさん

2010/03/12(金) 16:06:27

>>534も必要最小限で的確なツッコミだな。

0539デフォルトの名無しさん

2010/03/12(金) 16:36:10

何が言いたいのかさっぱり分からんから具体名で提示して貰いたいもんだ
ユーティリティクラスの全否定にしか見えんが

0540デフォルトの名無しさん

2010/03/12(金) 18:15:00

>>514はシステムコールのopen()を抽象化してるので良いと思うが。
open()がコードにあちこち登場して、なおかつ"/dev/物理デバイス"をopen()するような
ことだったら目も当てられない（テスト的に）。

0541521

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のメンバに加えるのは、そもそもオブジェクト指向的に間違ってる。

0542デフォルトの名無しさん

2010/03/12(金) 22:22:39

プライベートメソッドを省略のためだけみたいな使い方するなって言ってるんだろうけど
それどこの誰がオブジェクト指向違反だって言ってるの？

そのオブジェクト内でしか使わない、昔の C で言うところの static 関数みたいな使い方も
普通によくされてることだし、教科書でも別にあーだこーだ言ってるものは見たことないが。

0543デフォルトの名無しさん

2010/03/12(金) 22:23:55

文字通りその通りのコードだとしたらまさしく無駄だが、
オブジェクト指向的に間違っているのとは違うだろ。
public/protectedでopen/write/closeを公開するのなら
間違ってるかどうかの議論になるが。

0544543

2010/03/12(金) 22:24:51

ほぼ同時刻に、ほぼ同内容でかぶってしまった orz

0545デフォルトの名無しさん

2010/03/12(金) 22:30:44

>>514は、間違って変な引数入れないように、
決め打ちで引数入れて覆い隠してしまうことならあるな。

>>541も抽象化と言われれば、まあそうなのかと思えたりもするかも。
確かに基本無駄だろうな。
例えばconfig_openとかの名前にするのはどう思う？それもだめ？
あと、サブクラスでオーバーライドする用なんて可能性はどう？
（厳しい言語はprotectedじゃないとダメなのかな？）

0546543

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という単語を使うのは見たことないなぁ。

0547デフォルトの名無しさん

2010/03/12(金) 22:50:53

>>541
例えば、数行からなる、複数メソッドで使用するdatabseのopen/write/closeをprivateメソッドとして実装するのも
オブジェクト指向的に間違っているという主張？

それとも単に1行だからNGってこと？

0548デフォルトの名無しさん

2010/03/12(金) 22:52:40

private メソッドの主語まで自身のオブジェクトに紐付けしなきゃいけないとか
はじめて聞いたわw

やっぱ自称オブジェクト指向技術者はピンキリだね。

0549512=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みたいに、必要性が薄いのに分離されてるものを別のクラスに引き込むのは
当然駄目/無駄だと思う。

0550デフォルトの名無しさん

2010/03/13(土) 04:19:20

>>549
俺は>>541のprivate methodのようなものはWrapper関数とは俺なら言わないよってだけのことで、
Wrapper関数だからclass Dataの外側に持って行けとは言ってないよ。

Wrapper云々については、俺とは認識が違うなぁというだけの話なので、今回の本筋とは全く関係ないよ。

> そのクラスとの関連が強い処理で、分離するには粒度が小さくなりすぎる場合「とか」は、
> 無理して分離する必要は無いと思う。（他にも例外はあるかと）
えーと、分離すべきかどうかの話じゃなくて、オブジェクト指向的に間違ってるかどうかという質問
なんだけど。

databseへのアクセスを提供するクラスではなくて、それを使用するクラスでdatabaseアクセス
部分をprivateメソッドに抽出することもオブジェクト指向的に間違っているのかという質問。

> ただし>541みたいに、必要性が薄いのに分離されてるものを別のクラスに引き込むのは
> 当然駄目/無駄だと思う。
うーん、Fileの場合は間違っていて、databaseの場合は無理して分離すべき必要が無いというのが
良くわからん。

0551デフォルトの名無しさん

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;
　};
になるだけなんですが。で、今度は何を派生させますか？

0552デフォルトの名無しさん

2010/03/13(土) 05:54:34

クラス無駄にポコポコ作れば俺オブジェクト指向やってるカッケーって脳汁でまくる知的障害者なんだろ

>>549の論理で徹底するとクラスの数は無限大に発散する

0553デフォルトの名無しさん

2010/03/13(土) 06:08:04

>>541の例が>>541の言いたい事を表す為には全然具体性が欠けていると言う。
それが無駄なのは明白だが、単にその例に限定して無駄なだけでは？
オブジェクト指向的に間違っていると言う話はどこへ？
Dataがセーブ先のpathを自分で管理しなければならない場合はどう実装すれば良い？

結局例も挙げられないほど自分が何言ってんのか理解してないとしか思えない。

0554デフォルトの名無しさん

2010/03/13(土) 06:08:34

無駄なたらいまわしの話なのに、オブジェクト指向的に間違っているとか言い出すから話がおかしくなる

0555デフォルトの名無しさん

2010/03/13(土) 06:10:04

つか、土曜早朝にこんな底辺のスレに人居すぎだろｗ

0556デフォルトの名無しさん

2010/03/13(土) 06:17:40

まぁ>>541マンマのコードを書くような糞馬鹿野郎が実在するなら、そいつはゴミクズである事は誰もが同意するだろう
ただし、>>Hogeを主語とすると不自然な「関数」は、privateであってもメンバに加えるべきじゃない。　には誰一人として同意しないだろう

0557デフォルトの名無しさん

2010/03/13(土) 06:25:20

Dataクラスが実用レベルまで拡張されると、>>541の例のメンバが十分な正当性を持ち始めるんだがな。
512=521=541は数万ステップのコード書いた事あるか？

0558デフォルトの名無しさん

2010/03/13(土) 06:54:17

マチガッテル君
次はそんな無意味なコードじゃなくて
オブジェクト指向的に間違ってることを表すコードをお願いします
少なくともその無意味なコードはオブジェクト指向的に間違ってるとはいえません

0559デフォルトの名無しさん

2010/03/13(土) 06:57:02

「オブジェクト指向的に間違ってる」と示されたところで、だから何なの？っていう状態は
変わらない気がする。

普通に何が問題なのか（どんな困ったことが起こるのか）を示してくれればいいんだよ。

0560デフォルトの名無しさん

2010/03/13(土) 07:01:38

破綻例を示せって事だな

0561デフォルトの名無しさん

2010/03/13(土) 07:14:22

個人的な妄想じゃないと言うならクラスが主語にならないならprivateだろうとメソッドを作るべきでないと記述されている文献の提示でもいいよ。

0562デフォルトの名無しさん

2010/03/13(土) 09:11:34

ソフトウェア業界はたまーにこういうのが潜んでるから面倒だよね。
一見わかってるふうだからたちがわるい。

0563デフォルトの名無しさん

2010/03/13(土) 09:21:22

>>562
簡単な見分け方がある
「～は駄目だ」と言う奴は99%役立たずの勘違い馬鹿
コイツの戯言は何一つ聞き入れる必要が無い

「そこは～にすると良い」と言える奴は99%有益な意見を持つ人間

この見分け方は別にソフトウェア業界に限らない

0564デフォルトの名無しさん

2010/03/13(土) 19:34:45

>>563
お前は駄目だ

0565545

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:みたいなのがあれば個人的にすっきりするかも。

なんにしろ、最初から完璧は難しいと思うから、名前は後からでも変えられると気楽に考えてみてはどうよ。
"達人自身にルールを作らせて、ルールに従わせると逆に作業効率が下がった"みたいな話もあるらしいぞ。
出典はたしかリファクタリングウェットウェア。ときには型を破ることも大切らしい。

0566デフォルトの名無しさん

2010/03/13(土) 20:27:40

嫌でも権限の纏わりつく今の世の中、DataはOpenするものだけどね

0567512=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だけが行う操作。主体はデータファイルだから
原則を徹底するなら別クラスとして切り離すべきだけど、
その場合クラスの粒度が細かくなりすぎる。

一言でまとめるなら、「無駄なたらい回し」は何を持って無駄か?ってのは、
オブジェクト指向的にどこまでが妥当か?で判断すりゃ良いんじゃないかと
言いたかった。

0568デフォルトの名無しさん

2010/03/13(土) 21:06:34

>>567 >>559

0569デフォルトの名無しさん

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。

0570デフォルトの名無しさん

2010/03/13(土) 21:30:39

>>569
> open/write/closeにDataクラス固有の処理が追加されるならまだわかるけど。
> でもその場合も必要になった時点で追加すれば良い。

なら単に例のまんまの状態では関数化が要らないっていうだけのあたりまえの話じゃないか。
オブジェクト指向とか持ち出す意味がわからん。

0571デフォルトの名無しさん

2010/03/13(土) 21:49:27

うん
全く無駄な固有例を挙げて無駄だろ？って言ってるだけで
オブジェクト指向のオの字すらも関係ないな

固有例であってケースすら示してない

0572デフォルトの名無しさん

2010/03/13(土) 21:50:04

>570
>なら単に例のまんまの状態では関数化が要らないっていうだけのあたりまえの話じゃないか。
>オブジェクト指向とか持ち出す意味がわからん。

当たり前の話というのはその通り。ただ、世の中にはそれを当たり前と思わない人達も居て、
541のような実装がまかり通っている。
（実際、今あーいうコードと格闘中。）
なので別の基準としてオブジェクト指向を持ち出してみた。

open/write/closeはその内容を見る限り、Fileに対する操作であって、
Dataに対して行う操作とは違う。
だからオブジェクト指向的にも間違ってる（妥当な実装ではない）、って事で、
これもごく当たり前な事を言ってるつもりなんだが。

0573デフォルトの名無しさん

2010/03/13(土) 21:55:55

>>572
だから何でオブジェクト指向を持ち出すんだよ？
単に無駄だってことを説明すれば十分だろ？

そんなコードを書く奴はオブジェクト指向的に正しいかどうかなんてなおさら興味ないよ。

0574デフォルトの名無しさん

2010/03/13(土) 21:59:23

追記。無駄/無駄じゃないだと、よりもオブジェクト指向的に妥当じゃないという基準の方が、
>567の違いが説明しやすいと思うんだが。

実際、無駄/無駄じゃないだと>567の後者は良くて前者が駄目だという基準が曖昧で
中々理解を得にくいが、オブジェクト指向的に考えると両者に明確な差が出て来るんで
（ちょっとだけ）納得して貰い易くなる。

0575デフォルトの名無しさん

2010/03/13(土) 22:00:51

>>572
お前さ、バカが書いたコードで苦しんでるのは分かったから
そのイラツキをオブジェクト指向に対する意味不明な誤解を広める方向に向けないでくれ
主語がなんだとかprivateに持つべきでは無いだとか、何も関係ないだろ？

0576デフォルトの名無しさん

2010/03/13(土) 22:03:44

>>574
> （ちょっとだけ）納得して貰い易くなる。

と勝手に思っていたが、このスレで実はそうはいかないと学習できたわけだ。
まぁがんばれよ。

0577デフォルトの名無しさん

2010/03/13(土) 22:09:08

>>574
馬鹿の書いたコードの無駄さと、お前のムカツキを表すためだけに
何十年もかけて多くの人間が懸命に広めてきた共通概念を都合の良い様に捻じ曲げて使うな
どこからどう見ても全然関係ないだろ

0578デフォルトの名無しさん

2010/03/13(土) 22:12:22

お前ら、とりあえず AA でクラス図描いて来い。

0579デフォルトの名無しさん

2010/03/13(土) 22:12:28

>575
>主語がなんだとかprivateに持つべきでは無いだとか、何も関係ないだろ？

主語が云々は、凄く重要な判定基準だと思うんだが違うのか。
あと「privateに持つべきでは無い」とは言ってない。「privateであっても」だ。
また「持つべきでは無い」であって「持ってはならない」とは違う。
ニュアンスの違いも読み取って欲しい所。

0580デフォルトの名無しさん

2010/03/13(土) 22:15:43

>>579が俺定義言語を使っていて、会話不能と言う事もわかった

0581デフォルトの名無しさん

2010/03/13(土) 22:20:32

>>579
オレジェクト志向のお話はもうお腹いっぱいです

0582545

2010/03/13(土) 22:33:10

>>579
命名と意味のない拡張と、どっちを問題にしたかったんだ？
あるいは両方？

・命名が良くない
継承(is a)とコンポジション(has a)では、元のクラス(インスタンス)のメソッドを拡張するとき
命名の仕方はそれぞれで変えたほうがよい。それはprivateでも一貫させる。主語が大事。

・意味のない拡張がよくない
所有しているインスタンスのメソッドをそのまま呼び出すだけでは意味がない。
publicなら委譲だが、privateでは無意味。

0583デフォルトの名無しさん

2010/03/13(土) 22:35:28

>>582
多分この子が言いたいのは後者でしょ。
そして持論を補強したくて無理に前者を持ち出してみたら袋叩きにあったと。

0584デフォルトの名無しさん

2010/03/13(土) 22:47:10

>>569
>>557だが、お前さんは「とにかく否定したい病」の患者なのかい？

>Dataクラスが実用レベルまで拡張されると、>>541の例のメンバが十分な正当性を持ち始めるんだがな。
↓
>それはない。
↓
>open/write/closeにDataクラス固有の処理が追加されるならまだわかるけど。

「拡張」の意味を知らないのか？
「持ち始める」のニュアンス(笑)を捉える力が無いのか？
そもそもオブジェクト指向的な概念の話をしているという文脈が理解できていないのか？

>>557のケースをキッパリ否定した次の行で、>>557のケースの存在を認めるって何の意図があったの？

0585デフォルトの名無しさん

2010/03/13(土) 22:56:29

>>579
無駄って言いたいのはもう分かってるからさ
お前さんの主張が書かれてるソースをお願い
オブジェクト指向としてうんたらかんたらって言ってるんだから
俺様が今考えたスタイルですってわけじゃないんだろう？

0586デフォルトの名無しさん

2010/03/13(土) 23:06:27

なんか笑いが止まらんw

0587デフォルトの名無しさん

2010/03/13(土) 23:12:31

>582
後者。「命名が良くない」自体は否定しないけど、こちらの意図とは違う。

>583
「前者」を「オブジェクト指向」に置き換えれば概ね当たり。

単に無意味である以上に、純粋にFile操作するだけの関数が
Dataのメンバであるのは間違いだという主張。
「間違い」は言い過ぎだとしても、オブジェクト指向的に
違和感があると思うんだが。

多少のツッコミは予想していたが、正直>575-577,580-581は
熱くなりすぎじゃないかと思った。
何か気に触る事言った?

0588デフォルトの名無しさん

2010/03/13(土) 23:17:14

>>587は単純にprivateが何なのか分かってない

0589デフォルトの名無しさん

2010/03/13(土) 23:18:58

>>587
× オブジェクト指向的に違和感がある
○ オレ的に違和感がある

0590デフォルトの名無しさん

2010/03/13(土) 23:19:01

>>587
したり顔で大嘘吐いてるのが気に障る

0591デフォルトの名無しさん

2010/03/13(土) 23:20:26

>>587
> 「前者」を「オブジェクト指向」に置き換えれば概ね当たり。
だからどうしてそこを置き換えないといけないんだよｗ
わざとやってるのか？

0592デフォルトの名無しさん

2010/03/13(土) 23:25:48

>584
>「持ち始める」のニュアンス(笑)を捉える力が無いのか？

拡張が必要なら、拡張する時点で追加すれば良いけど、>541の時点では
追加する必要は全く無いというのがこちらのスタンス。
同じスタンスで言ってるなら>577は同意。
ただ違う事を言ってる可能性もあるんで、ああ書かせて貰った。

0593デフォルトの名無しさん

2010/03/13(土) 23:31:35

>591
>582の「前者」は意図してないと断ってるじゃん。
それに>583を↓と置き換えて、こうすれば概ね当たりだと言って何が問題?

　>>582
　多分この子が言いたいのは後者でしょ。
　そして持論を補強したくて無理にオブジェクト指向を持ち出してみたら袋叩きにあったと。

0594デフォルトの名無しさん

2010/03/13(土) 23:38:07

>>592
・・・
「拡張」されたら「持ち始める」といってるのに、お前さんが同じ事だと理解出来る為にはこれ以上何の補足が必要なんだ？

0595591

2010/03/13(土) 23:40:27

>>593
あぁそういうことか。ごめん。読み違えてた。

0596デフォルトの名無しさん

2010/03/13(土) 23:43:47

ニュアンスを汲んで欲しいとか文脈から読み取って欲しいと偉く上から目線で言ってっけど
>>593が一番国語力ありませんがなｗｗ
自分がコミュニケーション能力不足なのを人のせいにせんといてｗｗｗ

0597デフォルトの名無しさん

2010/03/13(土) 23:52:43

汲んでほしいとか読み取れるはずとか
人のせいにばかりしてるから
そんなに日本語が不自由なんだ

0598デフォルトの名無しさん

2010/03/13(土) 23:56:11

>594
いや、理解したからこれ以上の補足は不要。
こちらの読解力が足りていなかったと言う事で。

拡張すると意味を持ち始めるから、それに備えて実装しておく意味がある、
という主張かと思ってしまっていた。

0599デフォルトの名無しさん

2010/03/13(土) 23:59:18

>596-597
日本語不自由なのは認める。
あと上から目線っぽいのは、2chだからってのと、
口調を突然変えるのもどうかと思ったから。
不評のようだから変えます。

0600デフォルトの名無しさん

2010/03/14(日) 00:03:50

>>599
オブジェクト指向の下りは全面撤回ということでおｋ？

0601デフォルトの名無しさん

2010/03/14(日) 00:10:42

>600
いや、撤回はしません。
至らぬ所があると思うんだったら、ツッコミ入れてくれれば、
納得してくれるまで説明しますよ。
ただし煽りや的外れすぎ等で回答しずらいのはスルーさせて貰います。

0602デフォルトの名無しさん

2010/03/14(日) 00:15:47

>>601
貴方の説明は要らないんで、同内容が書かれていた文献を教えてください。

0603デフォルトの名無しさん

2010/03/14(日) 00:28:20

>>601の主張内容は理解したけど
オブジェクト指向的に間違っていると言うのには全く持って同意できない

俺ルールじゃないと言うのなら絶対に参照元があるはずだし、それを示せば一発でしょ

0604デフォルトの名無しさん

2010/03/14(日) 00:36:51

このスレにオブジェクト指向の開祖が居ると聞いて。

0605デフォルトの名無しさん

2010/03/14(日) 00:50:06

「無駄な間」はオブジェクト指向的に間違っていて
「無駄でなくなった」瞬間にオブジェクト指向的に正しくなる
このこじ付けには一切正統性が無く、意味不明です。

0606デフォルトの名無しさん

2010/03/14(日) 01:12:11

privateにおいて
そのインターフェースがクラスに相応しいかどうかは
実装に依存する、ということなのか？
オブジェクト指向的に考えて

0607デフォルトの名無しさん

2010/03/14(日) 01:16:27

だとしたら噴飯物だよね
オブジェクト指向的に考えて

0608デフォルトの名無しさん

2010/03/14(日) 01:28:06

そんな些細な実装に依存してしまったらどうやってクラス図書けばいいのん

0609デフォルトの名無しさん

2010/03/14(日) 02:24:13

>602,603
自分なりの解釈に基いて書いているので、コレという「ソース」はありません。
逆にこちらが間違っていると断言できるソースがあるなら示して下さい。

>606,607
「privateであっても」の部分が引っかかるというなら、
まずその部分は取っ払って考えて下さい。
（例えば>541のopen/write/closeは「Data」の操作と言えますか?）

オブジェクト指向的に相応しくないメンバであるなら、
privateであっても極力排除した方が良いと思いますが。
privateなら良しとするべき理由があるならともかく。

0610デフォルトの名無しさん

2010/03/14(日) 02:31:41

追記。
privateにすれば無問題というのは、オブジェクト指向プログラミングという
技法的には間違ってないと思うけど、思想的には間違っているはず、
と言った方が伝わるでしょうか。

>605
無駄かどうかとは別の角度、つまりオブジェクト指向的に妥当か否かでも
判断できるよねと言う話であって、両者をこじつけたい訳じゃありません。
こじつけて語ってしまった部分もあるかもしれませんが。

0611デフォルトの名無しさん

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であっても極力排除した方が良いと思いますが。

そうしないと、どんな困ったことが起こるというの？

0612デフォルトの名無しさん

2010/03/14(日) 02:45:32

>>609
悪魔の証明を求めないで下さい。
こちらは、そんな寝ぼけた主張をしている文献があるはずが無いと言ってるんです。
なにを言われてるか理解できていますか？補足が必要ですか？

0613デフォルトの名無しさん

2010/03/14(日) 03:25:04

>611
>そうしないと、どんな困ったことが起こるというの？

privateならOKとか言い出すと、例えば全ての関数を
1個のクラスにprivateメンバとして詰め込んだ実装も
オブジェクト指向的に間違いじゃないと言えてしまいますが。

privateであっても「そこにあるべきと言えないもの」は極力分離すべき、
というのが原則で、クラスの粒度が過度に小さくなるのを防ぐ、
等の理由があるなら例外として認められる、というのが
オブジェクト指向的に正しい考えかただと思いますが違うんで?

0614デフォルトの名無しさん

2010/03/14(日) 03:44:49

粒度の判断も分割すべき次元も人それぞれの裁量に任されるべきで、オブジェクト指向はそこに踏み込みません
本質とは全然関係無い話なんで、勝手にすればいいとされています

>>613はオブジェクト指向を全然理解せず、実装に引きずられ過ぎです
書籍は1冊も読んだ事が無いと容易に伺えます
>>613にはオブジェクト指向を語る資格がありません

0615デフォルトの名無しさん

2010/03/14(日) 03:47:33

>>613
611じゃないけど、その例なら個人的にはありだな。
そのクラスでしか使わないものを、そのクラスに閉じ込めておくのは
他で使われる心配をしなくて済んでいいと思うぞ。
その関数を修正するとき、そのクラスだけ意識すればよくなる。
privateのいいところだな。

0616デフォルトの名無しさん

2010/03/14(日) 03:48:24

>>613
おまえ隠蔽の意味が全然分かってないだけ。

>privateならOKとか言い出すと、例えば全ての関数を
>1個のクラスにprivateメンバとして詰め込んだ実装も
>オブジェクト指向的に間違いじゃないと言えてしまいますが。

実装としてどうなんだ？と言う話で、オブジェクト指向的にはどこにも間違いが見当たらない。

0617デフォルトの名無しさん

2010/03/14(日) 04:03:09

>>613は、ただの実装の善し悪しとオブジェクト指向の正誤を取り違えちゃってる子

0618デフォルトの名無しさん

2010/03/14(日) 04:11:30

>>613
> オブジェクト指向的に間違いじゃないと言えてしまいますが。
あぁそうだ。そしてそう言えるとしても誰も困らない。

１個のクラスにすべて詰め込んだ実装はいろいろとマズイわけだが、
それはオブジェクト指向とは関係なく説明できる。

> オブジェクト指向的に正しい考えかただと思いますが違うんで?
何を聞いても最終的にオブジェクト指向（しかも脳内）しか出てこない
のもおかしい。その先にある具体的な利点や解決される問題点を示す
ことができないのなら、そんなオブジェクト指向には何の意味も無い。

0619デフォルトの名無しさん

2010/03/14(日) 04:17:46

>>618
だよなｗ
何を聞いても最終的には「俺の中のオブジェクト指向ではそれは正しくない」で話が終わってしまうｗ

0620615

2010/03/14(日) 04:31:48

すまん、どうやら読み間違えたようだ。
全てのってそのクラスしか無い状態か。
いままでprivateの外にいた奴らは、追い出せばいいんじゃないか？
・・・また読み間違えてる気がする。

0621デフォルトの名無しさん

2010/03/14(日) 05:12:42

ここまで長々やって一人も賛同者が居ないと言うのに、自分を疑うと言う事を知らないのか？

0622デフォルトの名無しさん

2010/03/14(日) 06:53:58

80年代ならまだしも、2010年にもなって>>613みたいな、勘違いを公衆に発信してる奴を見るとなんか虚しくなるな･･･
言ってしまえばオブジェクト指向の要点なんて情報のカプセル化しか無いだろうに、何でこんな酷い勘違いが出来るんだか･･･
なんというか、数の数え方も知らずに数学について語ってるみたいな奴･･･

0623デフォルトの名無しさん

2010/03/14(日) 08:43:20

まあオブジェクト指向がらみにはこういう変な理解しちゃった子結構いるからなぁ。
ちょっと前まではそういう人たちは XP に移ってたけど、今はどこで何してるんだろう？

0624デフォルトの名無しさん

2010/03/14(日) 08:50:54

これ思い出した。
モスバーガーのきれいな食い方教えれ
http://guideline.livedoor.biz/archives/50970830.html

0625デフォルトの名無しさん

2010/03/14(日) 09:19:15

>622
「カプセル化」のとはprotected/private化するだけじゃなくて、
クラスとして抽出して外部に追い出す事も含まれると思いますが。
（クラス化自体カプセル化の一種であるというのは、何かで読んだ気がするので探してみます）

でもって>541みたいに必要も無いのに他のクラスのメソッドを引き込むのは、
隠蔽レベルを下げる行為だと見なせますよね?

0626デフォルトの名無しさん

2010/03/14(日) 10:19:33

>>クラスとして抽出して外部に追い出す事も含まれると思いますが。
一切微塵も欠片も小指の先ほども含まれて居ない。
「クラスの抽出をする事をカプセル化と言う」などと解説している物があるなら提示を。

>>隠蔽レベルを下げる行為だと見なせますよね?
Dataを外から見た場合、open write closeは完全に隠蔽されている。
というか、privateなのに一体どこで何が下っているのか、想像も付かない。

そして、全く同じシグネチャでも、必要性があれば隠蔽レベルを下げているとは言わず
必要性が無い時だけ隠蔽レベルが下るという主張も意味不明。
全く同じコードでも、閲覧者の主観によって隠蔽レベルが変わるというなら、コンパイラは一体何をすればいいのか。

隠蔽について、まともな本を読み勉強しなおせ。

0627デフォルトの名無しさん

2010/03/14(日) 10:30:06

ttp://e-words.jp/w/E382ABE38397E382BBE383ABE58C96.html
カプセル化とは、オブジェクト指向プログラミングが持つ特徴の一つ。
データとそれを操作する手続きを一体化して「オブジェクト」として定義し、
オブジェクト内の細かい仕様や構造を外部から隠蔽すること。

c++で言うなら、データと手続きをクラスとして抽出し、
細かい仕様や構造をprivate等のアクセス修飾子を使って隠蔽する事が
カプセル化。
隠蔽というのは、あくまでカプセル化の一部。（カプセル化⊃隠蔽）

0628デフォルトの名無しさん

2010/03/14(日) 10:31:48

>627を踏まえて>625を訂正。

でもって>541みたいに必要も無いのに他のクラスのメソッドを引き込むのは、
カプセル化のレベルを下げる行為だと見なせますよね?

0629デフォルトの名無しさん

2010/03/14(日) 10:35:41

C++の薄汚れた擬似オブジェクト指向はあんま好きじゃないな
Smalltalkとは言わないからせめてJavaレベルで話して欲しい

0630デフォルトの名無しさん

2010/03/14(日) 10:38:02

>>628
使用者はDataのSaveToFileを呼び出すだけで良い事は変わらないのでカプセル化は保たれています。
Dataの中がどうなっていようが関係ありません。
関係ないからカプセル化です。

0631デフォルトの名無しさん

2010/03/14(日) 10:41:20

>>613=>>625=>>627=>>628？
613でも何でもいいから名前固定してくれ
つかれる

0632613=625=627=628

2010/03/14(日) 10:52:08

>630
Dataのヘッダに、Fileの実装やDataがどの関数を使用しているかという
振る舞いが一部見えてます。
（コンパイラは見て見ぬフリをしますが）
open/write/closeを追い出せば、カプセル化はより完璧になります。

0633デフォルトの名無しさん

2010/03/14(日) 10:55:14

「それ」に「オブジェクト」を認め、「カプセル化」するとした時に
「カプセル化」の手段として「クラス」があり「隠蔽」がある。

「カプセル化」され、「隠蔽」されているなら、どのような「実装」だろうと関係ない。
ましてや「実装」により「隠蔽」や「カプセル化」が脅かされる事は、絶対に無い。
絶対に、無い。

0634デフォルトの名無しさん

2010/03/14(日) 10:56:42

>>632
オブジェクト指向にヘッダなんて概念は存在しません。
そろそろ死んでください。

0635デフォルトの名無しさん

2010/03/14(日) 11:02:42

ここまでで唯一分かった事

613はC++の言語仕様の事をオブジェクト指向と呼んでいる

　　　　　　　　　　　　　　　- 完 -

0636632 ◆79cfdX7bxM

2010/03/14(日) 11:10:55

Dataクラスの利用者から見て、Fileは以前隠蔽されたままだと言いたいのはわかります。
でも「抽出・分離」して隠蔽することを「カプセル化」と言うのだから、
Fileクラスとして抽出・分離されているものを、Dataクラスに必要以上に
結合するのはカプセル化を逆行してるでしょうに。

0637デフォルトの名無しさん

2010/03/14(日) 11:26:55

DataクラスとFileクラスはDataクラスにprivateメソッドを作ろうが作るまいがデータ結合です。
結合度は変わりません。オブジェクト指向として理想的です。

>Fileクラスとして抽出・分離されているものを、Dataクラスに必要以上に
>結合するのはカプセル化を逆行してるでしょうに。
意味不明のオレ概念です。使用を控えてください。

そしていい加減死になさい。

0638デフォルトの名無しさん

2010/03/14(日) 11:38:49

>>でも「抽出・分離」して隠蔽することを「カプセル化」と言うのだから、
だから違うと何度も言ってるだろう。
「カプセル化」とは「オブジェクト」を具現化する事であり、抽出も分離も隠蔽もその手段でしかない。
そこまで致命的にトップダウンな思考が出来ないのなら、一生オブジェクト指向を理解することは無い。

0639デフォルトの名無しさん

2010/03/14(日) 12:04:13

>>627
お前はe-wordsをチョロっと読んだだけで、浸透まで何十年もかかったパラダイムを理解した気になっている･･･のか･･･？
失笑と言うか････脱力感が･･･ヤバイ･･･

0640デフォルトの名無しさん

2010/03/14(日) 12:39:26

何を聞いても最終的にカプセル化（しかも脳内）しか出てこない
のもおかしい。その先にある具体的な利点や解決される問題点を示す
ことができないのなら、そんなカプセル化には何の意味も無い。

0641デフォルトの名無しさん

2010/03/14(日) 12:39:36

e-wordsで200文字読むだけで今日から君も立派なOOPerだ！やったね！

0642デフォルトの名無しさん

2010/03/14(日) 12:45:45

>>640=632?
やっと後釣り宣言出たって感じ？

0643 ◆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;
　};

このように、「別クラスに抽出」して「隠蔽」する事をカプセル化と言うのであり、
単に隠蔽するだけをカプセル化と言うのじゃありません。
多くの解説書でアクセス制御=カプセル化として説明してますから
誤解するのも無理は無いと思いますがね。

0644デフォルトの名無しさん

2010/03/14(日) 19:05:26

>>643
> 例えばopen に引数が追加されたら、Data::openも変更が必要です。
> 一方、Fileの派生クラスまたはラッパークラスを用意し、そちらに定義しておけば
> シグネチャ変更の余波は、Dataに到達する前に止められます。

わざわざ作った「Fileの派生クラスまたはラッパークラス」には変更が及ぶんだろ。
そこに変更が及ばないようにまた何かラッパークラスでも作るの？
それで誰が喜ぶんだよｗ

0645デフォルトの名無しさん

2010/03/14(日) 19:27:22

>>643
Fileのパブリックメンバのシグネチャ変えたら使用側全てに変更が及ぶなんて当たり前すぎて何が言いたいのかわからない。
それにData::openの実装の修正は必要だがシグネチャの変更は不要。
お前はなぜ何故実装とシグネチャの区別が付かない。

そうやって無限ラップ地獄の明らかに破綻した論理を大事に墓まで抱えていけば。

0646デフォルトの名無しさん

2010/03/14(日) 19:30:50

パブリックなシグニチャの変更を極力抑えるのが隠蔽でもあるんだけど愚かだねー

0647デフォルトの名無しさん

2010/03/14(日) 19:39:48

>>643　こいつは主語が分かってない
DataクラスがDataクラスに対して隠蔽してどうすんだ
馬鹿すぎる

0648デフォルトの名無しさん

2010/03/14(日) 19:58:09

ここまでの論理破綻は中々お目にかかれないでござるの巻

0649デフォルトの名無しさん

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は救われませんが。

0650デフォルトの名無しさん

2010/03/14(日) 21:01:47

>>643の主張はDataをDataFileに置き換えても再帰的に成り立つ
なぜなら、DataFileも本来関係ないはずのFileの変更に影響されるべき物ではないからだ。

0651デフォルトの名無しさん

2010/03/14(日) 21:06:35

あ、一応言っとくけど>>650は>>643が明らかに破綻してる事の証明だからね。

0652デフォルトの名無しさん

2010/03/14(日) 21:16:03

コイツがここまで不勉強な奴だったとは･･･
>>541みたいなコードを書いたという元コーダの正当性も再評価する必要があるな。
全うにコーディングしてたら馬鹿に絡まれ馬鹿に馬鹿と晒し上げられた、ただの被害者の可能性がある。

0653 ◆79cfdX7bxM

2010/03/14(日) 22:37:18

ここまで馬鹿ばかりだとは…
そもそも Data::open を作る意義が何なのか分かってますか? >全員

0654デフォルトの名無しさん

2010/03/14(日) 22:41:47

さぁやーっとオチがつくぞー

0655デフォルトの名無しさん

2010/03/14(日) 22:42:51

Data の取得方法ってファイルだけなのか？

0656デフォルトの名無しさん

2010/03/14(日) 23:00:57

>>653
わからないし、そこを明らかにしないと作成の是非なんか話にならないはずなのに、
「オブジェクト指向的に間違ってる」だの「カプセル化が不完全」だの抽象的な
概念（しかも脳内）を具体的な問題点と繋げないまま繰り返し言うだけで、それで
納得しなかったら馬鹿よばわりとか、どんだけ

0657デフォルトの名無しさん

2010/03/14(日) 23:03:52

平和だなぁ

0658デフォルトの名無しさん

2010/03/14(日) 23:06:37

>>653
>>541のケース「限定」で「Data::openは無駄だ」という当初の主張から翻り、今度は作る意義ですか。

さっぱり分かりませんが、作る意義って何の事を言ってるんですか？

個人的に作る意義は沢山存在しますが。貴方の言ってる事は本当に意味不明です。

0659デフォルトの名無しさん

2010/03/14(日) 23:34:51

関数つくる意義なんてたいてい抽象化じゃないのか？
オブジェクト指向でも構造化プログラミングでも。

0660デフォルトの名無しさん

2010/03/14(日) 23:47:17

ほんと笑いがとまらんwwww

0661 ◆79cfdX7bxM

2010/03/15(月) 01:14:06

>659
その通り。抽象化です。(カプセル化、あるいは隠蔽化でも良いと思いますが)
では次。
①抽象化のメリットは何ですか?
②Data::open は何に対して、何を抽象化してますか?

0662デフォルトの名無しさん

2010/03/15(月) 01:19:47

　　　　　　　　 ,. -‐'''''""¨¨¨ヽ
　　　　　　 (.＿＿_,,,... -ｧァﾌ|　　　　　　　　　　あ…ありのまま今　起こった事を話すぜ！
　　　　　 |i i|　　 }!　}} /／|
　　　　　　 |l､{　　j}　/,,ｨ//｜　　　　　　　『おれは奴に具体的な問題点を聞いていた
　　　　　　　 i|:!ヾ､_ﾉ／ u {:}//ﾍ　　　　　　　　思ったらいつのまにか聞かれていた』
　　　　　　　 |ﾘ u' }　 ,ﾉ　_,!V,ﾊ |
　　　　／´fト､_{ﾙ{,ィ'ｅﾗ　, ﾀ人　　　　　　　　な…　何を言ってるのか　わからねーと思うが
　　　　 /' 　ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ　　　　　　　　おれも何をされたのかわからなかった…
　　　　,ﾞ　／ )ヽ iLﾚ　u' |　| ヾｌﾄﾊ〉
　　　 |／_／　ﾊ !ニ⊇　'／:} 　V:::::ヽ　　　　　　　　頭がどうにかなりそうだった…
　　　 /／二二二7'T'' ／u'　__ /:::::::/｀ヽ
　　　/'´r　-―一ｧ‐ﾞＴ´　'"´ ／::::／-‐ 　＼　　　　催眠術だとか超スピードだとか
　　 / // 　广¨´ 　/'　　／:::::／´￣｀ヽ ⌒ヽ　　　　そんなチャチなもんじゃあ　断じてねえ
　　ﾉ ' /　ノ:::::`ー-､___／:::::／/ 　　　ヽ　　}
_／｀丶　/::::::::::::::::::::::::::￣`ー-{:::...　　　　　　ｲ　もっと恐ろしいものの片鱗を味わったぜ…

0663デフォルトの名無しさん

2010/03/15(月) 01:26:18

>>661の言ってる事がさっぱりわからない
オブジェクト指向とか本読むのめんどくせえから1から俺に教えてくれって事？

0664デフォルトの名無しさん

2010/03/15(月) 01:27:48

とりあえず◆79cfdX7bxMにはキチガイ認定を

0665 ◆79cfdX7bxM

2010/03/15(月) 01:33:32

こっちの方が考え方としては分かり易いか。

ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060607/240196/
>役割とは，「オブジェクトが果たすべき機能」のことで，オブジェクト指向では
>「責務（Responsibility）」と呼ぶ。通常はクラスにメソッドを実装することで，責務を実現する。
>
>オブジェクトに最適な役割を割り当てることは，
>「適切なクラスに適切な責務を配置する」ことに他ならない。

ファイルのopen/write/closeという責務は Fileが負ってくれているのだから、
Dataまで担う必要ありません。

0666 ◆79cfdX7bxM

2010/03/15(月) 01:43:16

これもどうぞ。

Single Responsibility Principle (SRP) - 単一責任原則
ttp://syboos.jp/sysdesign/doc/20080608013448257.html

クラスの責務（役割）は一つでなければならない。

0667デフォルトの名無しさん

2010/03/15(月) 01:59:02

↓以下、Dataが担っているのはDataのopen/write/closeだといい始めるループ

0668デフォルトの名無しさん

2010/03/15(月) 02:05:39

>>665
オレジェクト指向の宣教活動は自重してください
スレ違いですし、単純に迷惑です

0669 ◆79cfdX7bxM

2010/03/15(月) 02:05:46

>667
その先は付きあい切れません。
ではおやすみ。

0670 ◆79cfdX7bxM

2010/03/15(月) 02:07:32

>668
ここまで物分りが悪い奴ばかりと思ってませんでした。
（もしかして釣られたのか。）
では今度こそおやすみ。

0671デフォルトの名無しさん

2010/03/15(月) 02:09:21

privateで言うのもおかしいが、DataはそのままFileに委譲してるのにFileの責務を負ってるらしい
自己都合によって捻じ曲げるとこんな醜態を晒すという例

0672デフォルトの名無しさん

2010/03/15(月) 02:10:14

>>669
寝る前にどこ立て読みかネタばらし頼む
俺もスッキリ寝たい。

0673デフォルトの名無しさん

2010/03/15(月) 02:12:34

>>670
馬鹿は絶対に自らの間違いを認めない特性を持つが故に、馬鹿は死んでも直らないと言われる。
俺がこれをどちらに向けて言ってるかは、お前が決めれば良い。

0674デフォルトの名無しさん

2010/03/15(月) 02:56:15

典型的な救いようの無いタイプの馬鹿でワロタ

0675デフォルトの名無しさん

2010/03/15(月) 03:10:03

なんとなく言いたい事が分かってきたかもしれん。
DataとFileが密結合になるのが嫌なのだと思う。

まずDataの中にFileをコンポジションで所有するのが、気に入らない。
DataにFileの特性が入り込んでしまう。継承よりは疎結合だし、必要なので我慢する。
だがDataからFileのメンバを使うのは、それだけ結合が増えるので嫌だ。なるべく避けよう。
でもSaveToFile関数でopen/write/closeの３個を使うのは、避けられないから我慢する。
だがopen/write/closeを分けて委譲するのは、同じ３個でも３カ所に分かれるのは結合が強まる。
それに委譲を作るのも、まるでオーバーライドのようで結合が強まっているようだし、そもそもDataの特性に合わない。
SaveToFile関数のローカル内だけで済んでいた結合がDataクラス全体に拡散してしまうなんて悪夢だ。

という考え方なんだと推測したがどうだろう？

0676デフォルトの名無しさん

2010/03/15(月) 04:46:39

>>675
多分そうなんだろうねー
でもそれらのどこでも結合は強まってないんだけどねー
Data内部でopen/write/closeに分けた方が抽象化の度合いが高まって、より疎になってるんだけどねー

0677デフォルトの名無しさん

2010/03/15(月) 06:24:49

Dataはopenする物ではないという決め付けにまず驚愕

0678デフォルトの名無しさん

2010/03/15(月) 07:18:17

そしてこんだけ延々とスレチを続けるあたりがもうね。

0679 ◆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

0680デフォルトの名無しさん

2010/03/15(月) 09:38:42

>>679
> 通常はクラスにメソッドを実装することで，責務を実現する。
↓
> つまりopen/write/closeを追加する事自体、責務を増やしている。

private に open/write/close を追加したことで増えた Data クラスの責務って何よ？

0681デフォルトの名無しさん

2010/03/15(月) 10:29:35

>>679
その Data クラスにありそうな拡張って例えば、
・最後に保存してから変更があったかどうかのフラグの処理
・ロギング
のようなものが考えられると思うが、両方とも欲しい場合には
FileWithLoggingAndModificationFlag みたいな派生クラス
を作れって言ってるの？

0682551

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のようなメソッドがあることが
なぜオブジェクト指向的に間違っているかだ。

> ニュアンスの違いも読み取って欲しい所。
いやいや、お前がニュアンスを文章として的確に表現しろよ。

0683デフォルトの名無しさん

2010/03/15(月) 11:16:48

>>679
> m_pFile を持てば十分なのだから増やす必要は無い。

オブジェクト指向的というなら、そもそもclass Dataにm_pFileを持たせること自体がどうかと思う。
Dataには、自分自身を表現するメソッド、例えばtoString()とかイテレータを実装しておき、
永続化を担当するクラスの方に、Dataを渡す方がいいんじゃないか？

0684デフォルトの名無しさん

2010/03/15(月) 13:14:00

その先は付きあい切れません。
↓
あーあー、見苦しいなw

わろた

0685デフォルトの名無しさん

2010/03/15(月) 14:13:48

>>683
シーッ！
ペラい経験と先入観で気持ち良さそうに語っちゃってる痛い子にそんな事言っても理解不能です

0686デフォルトの名無しさん

2010/03/15(月) 14:34:39

>>682
>public/protectedならともかく、privateに>>541のようなメソッドがあることが
>なぜオブジェクト指向的に間違っているかだ。
ヘッダを読むと見えちゃうかららしいｗ
そこで爆笑したｗ

0687デフォルトの名無しさん

2010/03/15(月) 15:45:43

ヘッダを読むとは何の話ですか。
オブジェクト指向で言うと、どの行為に当たりますか。

0688デフォルトの名無しさん

2010/03/15(月) 15:50:26

>>682
俺も思ったけど一番肝心な所が//省略されてて意味不明だった
何が話されてるのかさっぱり分かってないただの馬鹿と判断してスルーしたけど

0689デフォルトの名無しさん

2010/03/15(月) 15:55:44

>>679
>m_pFileを通してFileが丸見えだから
イミフミエ

0690デフォルトの名無しさん

2010/03/15(月) 18:07:58

そもそも>>541にm_pFileというメンバは存在しないところから謎は始まった。

0691 ◆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
細かい事は気にせず書いてるから、多少おかしな部分はあるかもしれません。
ツッコミたければ好きなだけどうぞ。全部甘んじて受けておきますよ。
以降は、些細なミスについては一々弁解・謝罪するつもりは無いのでよろしくお願いしますね。

0692デフォルトの名無しさん

2010/03/15(月) 20:48:21

>>691
> 例えばopen等のメンテの度に、Data全体をコンパイルし直さなければならないというコストです。

そのメンテの度にコンパイルし直さなければならないという発生するコストは、
SaveToFile() の中で全部やってなかったら発生しなかったというのかね？

0693692

2010/03/15(月) 20:50:52

ごめん書き直す。

>>691
> 例えばopen等のメンテの度に、Data全体をコンパイルし直さなければならないというコストです。

聞いたのはクラス Data の「責務」なんだけど、なんでコストの話になったの？

コストの話にしてもおかしいよね。
そのメンテの度にコンパイルし直さなければならないというコストは、
SaveToFile() の中で全部やっていれば発生しなかったというのかね？

0694デフォルトの名無しさん

2010/03/15(月) 21:06:10

いいかげんスレタイ読み直せ

0695 ◆79cfdX7bxM

2010/03/15(月) 21:28:22

>692,693
「コスト」という表現が分かりにくいなら、open等のメンテの度にDataも影響を
受けざるを得ない、要はopenと一連托生になる、ではどうでしょうか。
（話が逸れますが、openとDataはm_pFileを共有する、共有結合だって事も分かりますか?）

>SaveToFile() の中で全部やってなかったら発生しなかったというのかね？
File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
まぁ open等を作った場合も同じ方法で発生を抑えられますが。
けどそれやったら、丁度>551のような状態になります。
Data内のopen等が無用の長物と化しますね。

オブジェクト指向で考えても、結局行きつく結論は「無駄」でしたね。
皆様お疲れ様でしたw

0696デフォルトの名無しさん

2010/03/15(月) 22:11:15

おまえらIDの出ない板でよく集中力もつなｗ

0697デフォルトの名無しさん

2010/03/15(月) 22:42:20

最後に書いた人の勝ちルールでやってるからっしょ。

0698デフォルトの名無しさん

2010/03/16(火) 00:17:07

>>（話が逸れますが、openとDataはm_pFileを共有する、共有結合だって事も分かりますか?）
天変地異級の大勘違いです。

一体今までの話のどこにグローバル領域が存在したというのか。

そもそも、クラスと、そのクラス自身のメソッド間で結合度？
どこまで馬鹿なんですか？
結合度とは、オブジェクト(クラス)間の関連を語るものです。

0699デフォルトの名無しさん

2010/03/16(火) 00:27:48

>File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
File* を外部から渡しても無意味だと思うのですが、実際にDataをコンパイルしなおす必要がない設計をしてもらえますか。
何を想定してるのかさっぱり想像がつかないので
とりあえずFileのopenが廃止され、open_streamのみになったケースに対応してください。

0700551

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メソッドに括り出すのって無駄なたらい回しだよね」以上の
オブジェクト指向的な何かが関係してるとは読めないよ。

0701551

2010/03/16(火) 00:51:12

>>695
> File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
の完全な実コードをお願い。

> まぁ open等を作った場合も同じ方法で発生を抑えられますが。
の完全な実コードをお願い。

> けどそれやったら、丁度>551のような状態になります。
> Data内のopen等が無用の長物と化しますね。
この二行の意味がわからないので。

0702デフォルトの名無しさん

2010/03/16(火) 00:53:17

ふつうは
File->Save(Data); じゃないの？

0703デフォルトの名無しさん

2010/03/16(火) 01:03:24

>>691
念のため言っておきますが、あなたが突っ込まれてる箇所はオブジェクト指向の基本中の基本で、
非常に致命的でお話にならない勘違いをしている所ばかりです

度合い的に言うと、÷記号って両辺の数字を足せばいいんだよね？レベルです
（しかもあなたは、÷記号は両辺を足すという意味なのを理解してないの？お前ら馬鹿じゃないの？と言うスタンスで語っています）

細かい所なんて誰も突っ込んでません
突っ込みきれる量じゃないからです

0704デフォルトの名無しさん

2010/03/16(火) 02:05:22

すげーな

◆79cfdX7bxMが書いてる事でオブジェクト指向的に正しいことが本当に一つも無い

細かい事気にしてないとか　そんなチャチなもんじゃあ　断じてねえ

0705デフォルトの名無しさん

2010/03/16(火) 03:15:28

>>695のプログラマ歴って業務で何年なの？
俺5年なんだけど(お陰で周りは正しいOOPに満ちていた)>>695の言ってる事がちっともわからん。
「無駄」から話が始まったはずなのに「結局行きつく結論は「無駄」でしたね。」とか再発見されても、困惑する。
一体どこを目指していたの？

0706デフォルトの名無しさん

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が主語に来ることは在り得ない。

∴どちらを主語にしても成立しない。

0707デフォルトの名無しさん

2010/03/16(火) 03:40:19

次に分からない部分。

> File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
> まぁ open等を作った場合も同じ方法で発生を抑えられますが。
↓
> けどそれやったら、丁度>551のような状態になります。
↓
>Data内のopen等が無用の長物と化しますね。

話が繋がってない。
重要な言葉を略しすぎで、人に伝える能力が無い。

0708デフォルトの名無しさん

2010/03/16(火) 04:24:23

>m_pFileを通してFileが丸見えだから
指摘したのに細かいとか一蹴されててワロス
Fileの公開メソッドへアクセス可能なことを丸見えといってるのか、
DataのprivateメンバにFileのインスタンスが存在する事をもって丸見えと言ってるのか
どちらにしろ超絶馬鹿
イミフミエ

0709デフォルトの名無しさん

2010/03/16(火) 10:09:00

さらしage

0710デフォルトの名無しさん

2010/03/16(火) 10:12:41

ちゃんと「ごめんなさい」が言える子に育ててもらえなかったんだね。かわいそうに。

0711デフォルトの名無しさん

2010/03/16(火) 12:56:00

>>627
> データとそれを操作する手続きを一体化して「オブジェクト」として定義し、
> オブジェクト内の細かい仕様や構造を外部から隠蔽すること。
その通り。

>>628
> でもって>541みたいに必要も無いのに他のクラスのメソッドを引き込むのは、
> カプセル化のレベルを下げる行為だと見なせますよね?
見なせない。外部からは何も変わっていない。

>>636
> でも「抽出・分離」して隠蔽することを「カプセル化」と言うのだから、
微妙に言い回しを変えてるが、>>627にあるとおり「外部から隠蔽する」というのが
カプセル化の定義。

> Fileクラスとして抽出・分離されているものを、Dataクラスに必要以上に
> 結合するのはカプセル化を逆行してるでしょうに。
何が「必要以上」なのかさっぱり分からんが、privateメソッドを作ろうが作るまいが、
DataとFileの結合度には何の影響も与えない。

そもそもあるクラスがあるクラスを使う（use関係）というのは、カプセル化とは
何の関連もない。
さらには、あるクラスがあるクラスを使うと決定した時点で、結合するのは逃れられない。
ちなみに、その結合を逃れる手段は>>683。

0712デフォルトの名無しさん

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クラスが有用な場合はもちろんあるが、これが壮大なたらい回しクラスの
固まりだと誰かに言われたらなんと反論するのだろうか。

0713デフォルトの名無しさん

2010/03/16(火) 13:15:46

>>712
クラスの「ニュアンス」を読み取って、コーダの主観だけを根拠に、ラッパーの必要の無いところは外してほしい(ｷﾘｯ

0714デフォルトの名無しさん

2010/03/16(火) 13:22:18

>>530の最後の一文からコイツクッセエエエと思ってたが、やはりキチガイさんでしたな

自分の話が相手に伝わらない原因を相手に求めだす奴にまともな奴は一人も居ない

0715デフォルトの名無しさん

2010/03/16(火) 13:24:31

リファクタリングを知らないのかな。
リファクタリングだと、一行だけprivateメソッドに抽出するなんて普通すぎて、誰も疑問に思わないんだけど。

0716デフォルトの名無しさん

2010/03/16(火) 13:26:39

おっとインドリさんの悪口はそこまでだ。

0717デフォルトの名無しさん

2010/03/16(火) 13:28:47

ここで爆笑した。

>>670
> ここまで物分りが悪い奴ばかりと思ってませんでした。
> （もしかして釣られたのか。）

確かに爆釣成功だけどな。

0718デフォルトの名無しさん

2010/03/16(火) 13:35:11

ごめんなさい出来ない子とは遊ぶなってばっちゃが言ってた
ばっちゃありがとう

0719デフォルトの名無しさん

2010/03/16(火) 13:41:56

インドリでググったらやたらタイムリーな記事書いてるな
で、こいつがなんなの？

0720デフォルトの名無しさん

2010/03/16(火) 13:58:45

そもそもprivateが何なのか知らなかったんじゃないのかねぇ

0721デフォルトの名無しさん

2010/03/16(火) 14:57:01

privateメソッドって、Cで言うところのファイルスコープのstatic関数のようなものだと
思ってたが、何か違うの？

0722デフォルトの名無しさん

2010/03/16(火) 19:30:02

どっかで見た書き込みだなぁと思ったら>>542だった。

0723デフォルトの名無しさん

2010/03/16(火) 22:34:29

>>721
運用による。
private メンバ/メソッドにアクセスしないなら、依然ファイルスコープ static でも構わない。
C の頃から OO 的モジュール分割してたのなら、その解釈でいいと思う。

0724 ◆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に固有の機能などありませんから、
無用の長物としか言えません。

0725デフォルトの名無しさん

2010/03/16(火) 23:44:00

メンドウならもう書かなくて良いのに

0726 ◆79cfdX7bxM

2010/03/17(水) 00:06:33

>715
漏れが無駄と言ってるのは、「他のクラスの関数に処理を丸投げするだけの関数」です。

ちなみに Proxy や Facade のようなパターンでは例外的にそういった関数が登場すると思いますが、
その場合はアリだとも断ったはずです。(>532)
またその場合、問題の関数がprivateなワケがありません。

0727デフォルトの名無しさん

2010/03/17(水) 00:07:19

>>724
もう、あなたが書くべき言葉は「ごめんなさい」の一つしか残されていません。

0728デフォルトの名無しさん

2010/03/17(水) 00:10:21

>>726
あの、↓の実装お願いできませんか？
出来たら本当に凄いことだと思うので。

>File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
>まぁ open等を作った場合も同じ方法で発生を抑えられますが。

0729デフォルトの名無しさん

2010/03/17(水) 01:33:42

>>724
「では」以降何を言っているのかさっぱりわからないが、それprivate関数であっても、
クラス名が主語になるようなメソッドしか作成してはならない、の説明なのか？

額面通りに受け取って話が通じるような文章にしてくれよ。

あまりにお前が一生懸命に何か言おうとしてるから、何を言いたいのか知りたいんだけど、
大抵何言ってるのかさっぱりわからんのだよ。

それと、もうクラス名の主語たりえろ云々はもうどうでもいいから、>>728だけは回答してくれ。

0730デフォルトの名無しさん

2010/03/17(水) 01:48:36

結局、俺様の崇高な文章がわからないお前ら馬鹿という所で思考停止してしまって、
推敲するとか文章読本読むとかするつもりゼロなんだろうなぁ。

ニュアンス読み取れってことは、自分の伝えたいことが伝わってないということで、
それは自分の文章に原因があるってことに気づかないのかね。

プログラマなんだからコードで語れよ。

>File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。

「等の条件」はお前にしか解らないんだから。
コードで示せば一発で相手を理解させることができるのに。

0731デフォルトの名無しさん

2010/03/17(水) 02:15:10

次に◆79cfdX7bxMは　「こまけえこたぁいいんだよ」　と言う

0732デフォルトの名無しさん

2010/03/17(水) 02:21:47

あれ、責務とか結合度とかカプセル化の話はどこいったんだ？

0733デフォルトの名無しさん

2010/03/17(水) 02:25:48

◆79cfdX7bxMにとっては「Dataのメソッドを書き換えるときに、Dataをコンパイルし直さなければいけない事」が一番重要な問題だったんだよ！！
もういいだろみんな！！！

0734デフォルトの名無しさん

2010/03/17(水) 02:32:53

>File* を外部から渡す構造にしておく、等の条件付ですが発生しない設計にできますよね。
当たり前の様に言ったコレ
間違いを認めて全面撤回と謝罪をするか、サクっと実コードを示すか
最後にコレだけ頼む

0735デフォルトの名無しさん

2010/03/17(水) 02:45:25

1対他全員の構図になってるのに、めげずに書き込むのは何がそうさせるんだろう？
そろそろ自分が間違ってるカモと思い始めてもいい頃なのに。

0736デフォルトの名無しさん

2010/03/17(水) 02:54:04

>>726
だーかーらー、一行をたらい回すprivateメソッドなんて無駄だよねってのはみんなが同意するところで、
オブジェクト指向的に間違ってるのはどこがどう間違ってるのかという話なんだけど。

0737デフォルトの名無しさん

2010/03/17(水) 02:54:24

無知や矛盾や破綻を指摘される度に一応ググってるらしく
段々使ってる語呂が増え、語呂もオブジェクト指向の物になって来てるんだけど
一つも漏らさず全部の単語の用法が致命的に間違ってると言う素晴らしさ

一生改善しない、まさに死ぬまで馬鹿が約束された、馬鹿の中の馬鹿

0738デフォルトの名無しさん

2010/03/17(水) 09:07:57

皆今日も華麗に舞って俺を楽しませてくれ

0739デフォルトの名無しさん

2010/03/17(水) 11:27:40

飽きた

0740デフォルトの名無しさん

2010/03/17(水) 11:30:26

もしかして：語彙

ﾌﾟｷﾞｬ-ｗｗｗ

0741 ◆79cfdX7bxM

2010/03/17(水) 19:54:07

>735
そろそろ気付いて下さい。

※但し釣りじゃありません。

0742デフォルトの名無しさん

2010/03/17(水) 20:18:19

レッツパリィー！

0743デフォルトの名無しさん

2010/03/17(水) 21:57:34

コードも書けない、負け逃げも嫌

屑

0744デフォルトの名無しさん

2010/03/18(木) 00:08:50

>>741
そろそろ自分で出来るって言ったコード書けよゴミクズ

0745デフォルトの名無しさん

2010/03/18(木) 00:56:51

Cライブラリの関数ポインタ集みたいなクラス作って
何が抽象化だよｗ

0746デフォルトの名無しさん

2010/03/18(木) 01:28:27

>>741の名前はクニオ
間違いない

こんなに自分の発言に責任を持たないキチガイは二人と居ない

0747 ◆79cfdX7bxM

2010/03/18(木) 01:43:07

反例出せば即決なのに。

0748デフォルトの名無しさん

2010/03/18(木) 01:46:15

>>747
お前は出来ると言った

俺は出来ないと考える

悪魔の証明を求めるとか本当に馬鹿だな

どうせ悪魔の証明って言葉自体知らんのだろうけど

0749デフォルトの名無しさん

2010/03/18(木) 01:48:20

>>747
この期に及んで、明らかに不可能な発言すら撤回しないの？本当にごめんなさい出来ないクズだな

0750デフォルトの名無しさん

2010/03/18(木) 02:08:51

出してもいない例に対する反例を出せとかｗｗｗｗｗｗｗｗｗｗばかすｗｗｗｗｗｗｗｗｗ

0751デフォルトの名無しさん

2010/03/18(木) 02:35:07

>>747
おれの理論を使えば誰でも簡単に時間旅行が出来る。
そんなことありえないだって？ならお前が反例だせ。

これ位の馬鹿さを晒しています。
気付いてください。

0752デフォルトの名無しさん

2010/03/18(木) 04:58:01

>>747が仕事でコード触ってるとか嘘乙すぎるｗ

0753デフォルトの名無しさん

2010/03/18(木) 06:30:27

>>747
どの発言の何の反例を求めてるんだ？
お前の発言はどれもめちゃくちゃでわからんぞ。

0754デフォルトの名無しさん

2010/03/18(木) 09:05:32

>>747
何の反例を求めてるんだか、唐突で全く意味不明。
反論の間違いだとしたら、死ぬほど反論されてお前が無視してるだけだから、スレを読み直して回答しろ。

0755デフォルトの名無しさん

2010/03/18(木) 09:07:02

もう、自分が正し*げ*だという立場表明のほのめかし発言しか出来なくなったようだな。
それでもこのスレを読むのもやめられず、悔しくて発言するのもやめられない。

0756デフォルトの名無しさん

2010/03/18(木) 09:11:51

>>724
> 言葉を額面通りでしか受け取れない人達ばかりですねぇ。

普通の人間なら、額面通りに受け取ってもらえる文章を書こうとするんだが。

0757デフォルトの名無しさん

2010/03/18(木) 14:01:04

>>747 に質問なんだが
Data::open() が固定パスのファイルを開くメソッドで有ったり、インデックスを特定のルールでパスに変換して開くメソッドである場合も
File の派生クラスを用意して役割分担させるべきと考える？
同様に Data::write() がテキストをHEXで書き込むメソッドである場合もその責務を File の派生クラスに負わせるべき？
この考えだと File の派生クラスは Data の完全な下請けクラスになっちゃうけどこれってオブジェクト指向的に正しいの？

0758デフォルトの名無しさん

2010/03/18(木) 14:22:59

>>747
短文にどこまでツッコミ所を込められるかのテストか？ｗｗｗ

0759デフォルトの名無しさん

2010/03/18(木) 15:56:27

結論

>>747は病気

0760 ◆79cfdX7bxM

2010/03/18(木) 19:38:45

今日も空気を読まずにカキコ。
Data は DataHolderと書いといた方が分かり易かったかと今更後悔。

ところで念の為に聞いておくけど、↓のような実装もオブジェクト指向的には
全く問題無い、と思っておられる方は居るんでしょうか。

　class DataHolder : private File
　{
　　public: void SaveToFile(){
　　　open();
　　　write();
　　　close();
　　}
　};

0761デフォルトの名無しさん

2010/03/18(木) 19:44:31

くだらん話題なんか振らなくていいから、まずお前のすべきことをしろ。

0762デフォルトの名無しさん

2010/03/18(木) 19:52:09

念の為だって、奥様ｗ

0763デフォルトの名無しさん

2010/03/18(木) 20:18:16

> と書いといた方が分かり易かったかと今更後悔

まだこいつ自分が正しいと思ってるのか

0764デフォルトの名無しさん

2010/03/18(木) 20:24:24

マ板のおじゃばってコテを思い出した。

0765デフォルトの名無しさん

2010/03/18(木) 20:26:13

こいつのトリップぐぐったらMoonWolfと一致するな。偶然かもしれないが。

0766デフォルトの名無しさん

2010/03/18(木) 20:27:46

DataHolderみたいなピンとこねぇ名前で、
そういう単位でクラスをつくる奴の気は知れねぇが。

class DataHolder {
　　public: void SaveTo(File f){
　　　f->open();
　　　f->write();
　　　f->close();
　　}
};

みたいになぜしないのか不思議。
流れ読んでなくてすまんが。

0767 ◆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( ); }
　};

0768 ◆79cfdX7bxM

2010/03/18(木) 22:17:24

>757
一応Data::openは固有の引数を与えるとかすら無い、
「完全に丸投げ」な関数だから問題としてます。
あとFileの派生クラスがDataの下請けクラスになるのは正しいと思いますが。
Dataがそのクラスに処理を一部委譲してるって事ですよね。

>765
多分トリップの無い様が簡単過ぎるからかと。

0769デフォルトの名無しさん

2010/03/18(木) 23:54:48

>>768
下請けクラスを作成する事がオブジェクト指向的に正しいのか答えてないね

あるクラスの機能を実装するときにこの機能はこのクラスの派生が持つべきだからって理由で下請けクラスを
複数作るのは原理主義過ぎて現場にはそぐわないと思うんだが

0770デフォルトの名無しさん

2010/03/19(金) 00:06:53

>>768
うるせークズ
お前はまずやるべき事をやれ

0771デフォルトの名無しさん

2010/03/19(金) 00:10:47

>>767

　　全　　部　　論　　外

0772デフォルトの名無しさん

2010/03/19(金) 02:02:04

うわ、こいつこれまでの数々の恥ずかしい勘違いを無かったことにしようとしてるぞ

0773デフォルトの名無しさん

2010/03/19(金) 02:15:22

>>768
> 「完全に丸投げ」な関数だから問題としてます。

問題だから問題です以上の何かは、もう言えないということだな。

private継承を持ち出して、また何か持論を展開しようとしてるみたいだが、まずお前の結論・主張を書け。
つか、まず>>541の問題に決着をつけろ。

0774デフォルトの名無しさん

2010/03/19(金) 02:32:56

散々嘘吐いて話逸らして誤魔化し続けた不誠実の極み見たいな馬鹿が
まーた論点ずれた問いかけをして誰かに答えてもらえるとでも思ったの？

0775デフォルトの名無しさん

2010/03/19(金) 02:34:43

>>760
仮にそれが問題ありだとして、>>541とどう関連づけるつもりなんだろう？

0776デフォルトの名無しさん

2010/03/19(金) 02:36:57

private継承などという言語specificな話題を持ち出した時点で、オブジェクト指向的な是非とは
離れてしまったということに気づかないのかな。

0777デフォルトの名無しさん

2010/03/19(金) 02:48:40

>>776
だからコイツにとっては
オブジェクト指向=C++の言語仕様
なんだって
本人にとっては何もぶれちゃいないツモリ

ヘッダでprivateメソッドの痕跡が見れるのが
オブジェクト指向的に見て大問題とかいっちゃうブットビ具合

0778デフォルトの名無しさん

2010/03/19(金) 02:59:01

これだからC++は塵言語なんだ
マルチパラダイム言語とか「１０人の天才の足を引っ張る一人のキチガイ」を大量生産するだけだろ

0779デフォルトの名無しさん

2010/03/19(金) 03:42:56

普通の人間には、ここまで支離滅裂な行動をとる事は、実は難しい。

0780デフォルトの名無しさん

2010/03/19(金) 03:56:38

このスレで、なんとか名誉挽回しないと心の平穏が保てないんだろうなぁ。

0781デフォルトの名無しさん

2010/03/19(金) 06:41:21

あーあー、見苦しいなｗ

0782デフォルトの名無しさん

2010/03/19(金) 07:56:52

多分今晩にはこの馬鹿の勝利宣言が聞けるな

相手にされなくなってからの勝利宣言ほど惨めな物は無いが
いい加減しつこ過ぎるしさっさと勝利宣言して気持ちよく消えてくれ

0783デフォルトの名無しさん

2010/03/19(金) 09:08:44

C++におけるコーディング規約：
・private継承はしない

え？やりたい？うるせー馬鹿。うぜー。

0784デフォルトの名無しさん

2010/03/19(金) 10:10:14

>>767
基底クラスと派生クラスの役割と、派生クラスは継承して何をやりたいかを明確にしないと
private継承のことは語れません。
private継承は、それを行うと便利なときのみに使います。
どのような時に便利なのかは、（More?) Effective C++やModern C++ Designに載ってます。

0785デフォルトの名無しさん

2010/03/19(金) 10:16:59

基本的にはprivate継承は、派生クラスのクライアントコードから基底クラスの公開メソッドを隠すために使う。
A-Eが何なのか解らないと答えようがないのは>>784と同じ。

0786デフォルトの名無しさん

2010/03/19(金) 18:45:48

そろそろ来るぞー
「誰にも答えられなかったようですね」と言う虚しい勝利宣言がー

0787デフォルトの名無しさん

2010/03/19(金) 19:16:43

OOPの話題をしているかと思ったら、
private継承を混ぜてきたとか（；´Д｀）

だいたい、privateメソッドに着目してウンタコータラ言い続けるのも不思議。
そんなもんの変更は、クラス内で完結しちゃってるだろうに。

0788 ◆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だけだと思いますが。

0789 ◆79cfdX7bxM

2010/03/19(金) 23:54:59

誰もまともに答えるつもりがなさそうなので質問を変えてみますが、
BのようなコードをC～Eのように書く（書き直す）のはありでしょうか?
無闇に書き直すのは間違いとかいうのは無しですよ。

0790デフォルトの名無しさん

2010/03/20(土) 00:10:58

もはや誰一人としてどういう観点からありなしを語ってるのかすら分からないだろう
こいつは根っこから馬鹿なんだな
余りにも話を伝える能力が無い

0791デフォルトの名無しさん

2010/03/20(土) 00:11:19

答えて欲しいなら問題を書き直してくれ
>>767 では問題として題意が不明瞭な為に回答ができないとの意見が多い
修正点を上げるだけでは読むほうにとって面倒なので問題を作り直して提示するのが筋だ

0792デフォルトの名無しさん

2010/03/20(土) 00:57:38

この馬鹿まだやってるのかよｗ

0793デフォルトの名無しさん

2010/03/20(土) 01:57:26

幼稚園児の方がまだ話が通じるわ

0794デフォルトの名無しさん

2010/03/20(土) 02:37:10

意味不明で答えようも無い質問を出してるのにコイツは何時になったら気付くの？

まともに答えるつもりが無い？質問を変えてみます？

何でコイツはコンナニモ馬鹿なのにコンナニモ上から目線なの？

0795デフォルトの名無しさん

2010/03/20(土) 02:48:37

>>789
まず、お前が積み残した質問に答えろ

0796デフォルトの名無しさん

2010/03/20(土) 02:55:09

自分以外の馬鹿が釣れるまで質問し続けて、
決定的な間違いをした奴を叩いて溜飲を下げてから
このスレから立ち去る戦法。

0797デフォルトの名無しさん

2010/03/20(土) 02:55:35

>>789
お前が大半のレスを無視した結果がこれだよｗ

0798デフォルトの名無しさん

2010/03/20(土) 02:59:31

>>789
BをCに書き換えたらそれは>>541で、Cはオブジェクト指向的に間違いだという主張じゃなかったのか？
今までさんざん指摘があったのは全部無視か？

>A～Eが何なのかは、まず身近なコードでAとBの関係になってるものを探して、

いやいや、質問したいなら、お前の身近なコードで具体例を示せよ。

0799デフォルトの名無しさん

2010/03/20(土) 03:13:50

今頑張って馬鹿が釣れそうな問題考えてるから明日の夜まで待ってくれ
じゃないの？

0800デフォルトの名無しさん

2010/03/20(土) 03:26:46

◆79cfdX7bxMの汚点まとめ
１．馬鹿
２．不遜
３．尊大
４．横柄
５．論点無視
６．論理飛躍
７．他者批判
８．責任転嫁
９．認知障害
１０．有言不実行
１１．自意識過剰
１２．自制心不足
１３．認知的不協和

0801デフォルトの名無しさん

2010/03/20(土) 05:45:24

>>788にとってはpublic/privateの違いなんて、「ならこれでも良いです」って位の
どーーーーーーーでもいい些事なんだな

オブジェクト指向のオの字すら語る資格が無い

0802デフォルトの名無しさん

2010/03/20(土) 05:52:44

正直ここまでpublic/privateの区別が出来てない奴も珍しい
プロジェクトに組み込まれたら災害レベルの無能を発揮するだろう

0803デフォルトの名無しさん

2010/03/20(土) 08:40:49

さあ連休だ。
存分に踊れ。

0804デフォルトの名無しさん

2010/03/20(土) 10:31:14

明らかに間違った事を主張する　2010/03/11(木)
↓
矛盾点を指摘、質問される
↓
論点がずれた意味不明な回答をする
↓
全然解決されなかった矛盾点を再度指摘、質問される
↓
めんどくさいんでスルーしますと言い出す
↓
全てを無かった事にして意味不明な質問をしだす
↓
意味不明すぎて誰からも相手にされない
↓
質問の要点が不明瞭なまま角度だけを変えた意味不明な質問を繰り返す
↓
意味不明すぎて誰からも相手にされない　←いまここ
↓

0805デフォルトの名無しさん

2010/03/20(土) 10:42:54

この一文にすべてが凝縮されてる。

>>679
> 超ド素人でも感覚で理解してるような原則を延々説明しなきゃならんとか、

ド素人の自分が超ド素人時代に、感覚で理解したと勘違いしたことを延々と垂れ流しているだけ。
何の根拠も理論武装も無い。無いが故に、何故正しい自分がわかってもらえないのかという所
から抜け出せない。
あまつさえ、全員が自分を釣っているのではという疑念を抱く始末。

0806デフォルトの名無しさん

2010/03/20(土) 10:56:15

こんなにはっきり「お前のそれは間違ってる」と言われているのに
「こいつら一から説明しなきゃ分からないのか」と超絶変換される脳みそ持ってる事は、本当にお気の毒だと思う
まぁ79cfdX7bxMの脳みそと性格は絶対直らないから早く死ぬといいよ

0807デフォルトの名無しさん

2010/03/20(土) 21:36:10

Money, Employee, Order, Printer, Customer, Movie, Rental, Account, Chargeとかさ、
OOの設計とかリファクタリングとかTDDとか、その手の書籍見たらこんな感じの簡単な
具体例が良く出てくる。
Animal, Dog, Catはもう古いけどさ。
こういう具象クラスを例に挙げないと、会話が進まないよ。
本気で会話したいのかどうか知らないけど。

0808デフォルトの名無しさん

2010/03/20(土) 21:45:55

もう居なくなった 79cfdX7bxM の話は終わりにしないか？

0809デフォルトの名無しさん

2010/03/20(土) 22:19:51

>>504が発言するまで三ヶ月も放置されてたし、やりたいならとことんやれば？ｗ

0810 ◆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( ); }
　};
と書き直すのはありなんですか?

0811デフォルトの名無しさん

2010/03/20(土) 23:29:17

なし。

0812デフォルトの名無しさん

2010/03/21(日) 00:10:30

>>810
Awrapper を Bsuper に変更すれば問題無いんじゃないの

0813デフォルトの名無しさん

2010/03/21(日) 00:31:13

何か自由度が増えるとか関数ポインタの参照をする依存度が
減るとかメリットあるのか？

0814デフォルトの名無しさん

2010/03/21(日) 01:13:54

>>813
class B と同列に class B' を作るなら class Bsuper から派生させるのは良くある事だと思うけど
俺に聞いてるんじゃなかったかな？

0815812

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 にして、人から桃太郎を派生させる様にすれば問題は無いんじゃなかろうか

0816デフォルトの名無しさん

2010/03/21(日) 01:41:43

>>810
意味ない質問してるの解ってるのかな。
責務とか言ってたの誰だっけ？

0817デフォルトの名無しさん

2010/03/21(日) 01:43:23

>>815
お前それ本気で言ってんの？

0818815

2010/03/21(日) 02:15:19

>>817
うーん微妙、>>810 の反応が見たいから書いてみたけど少し無理が有るしなぁ...

0819デフォルトの名無しさん

2010/03/21(日) 02:20:08

>>816
いやいや、その前にたとえprivateであっても主語がうんたらかんたらが先だろ

0820デフォルトの名無しさん

2010/03/21(日) 04:35:35

>>810の馬鹿ついに全部パブリックにしだした

0821デフォルトの名無しさん

2010/03/21(日) 05:52:19

こんなイン○リみたいな奴がイ○ドリ以外に居る事に驚愕を禁じえない
それとも、俺が知らないだけでC++界隈にはこの手の馬鹿が多かったりするのか？

0822デフォルトの名無しさん

2010/03/21(日) 07:44:12

イソドリ本人だったりしてな
こんなのそうそう出ない上に、その破壊力が強烈だから目立つだけじゃね？
℃ｏｄｅＺｉｎｅみたいに、ライターとして記事を採用するようなバカやらなきゃ、実被害は出んよ

0823デフォルトの名無しさん

2010/03/21(日) 08:21:29

いや、でもこういう手合いってPGSEには一定割合で存在してるような気もするよ。

0824デフォルトの名無しさん

2010/03/21(日) 08:40:01

だからインドリって何だよ
ここで話に挙げたいなら纏めろ

0825デフォルトの名無しさん

2010/03/21(日) 10:18:06

ググればすぐわかるのに

0826 ◆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に与えてるのは同じですよね。

まぁこれは原理主義的過ぎる考え方だとは思いますがね。

0827デフォルトの名無しさん

2010/03/21(日) 10:44:21

相手が何か特殊な単語を使うと鸚鵡返しのように次のレスに組み込んでくるな
まぁ相変わらずイミフ

0828デフォルトの名無しさん

2010/03/21(日) 10:52:08

賢そうな単語に見えたんで早速真似してみましたって行動パターンが哀れ過ぎる。
そして悉く使い所が間違ってると来ると、もはや涙無しには語れない。

0829 ◆79cfdX7bxM

2010/03/21(日) 11:08:09

>827-828
特殊な単語ってどれ?

0830デフォルトの名無しさん

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の是非はイコールではない。
なぜイコールだと思うのか、その根拠を書け。

0831デフォルトの名無しさん

2010/03/21(日) 11:41:19

継承という話を持ち出した時点で、is-a関係やs-implemented-in-terms-of関係か
どうかという事抜きに話をするのは意味がない。

それら抜きに書き換え可能かどうかと言えば、答えは書き換えられるとしかいいようがなく、
それが無駄なたらい回しかどうかは、その場合もあればそうでない場合もあるとしか言えない。

0832デフォルトの名無しさん

2010/03/21(日) 11:48:16

コンテキスト抜きにClass ABCとかFunc1とか言っても駄目。
なんでコンテキストがしっかりしている>>541から逃げるのか。

0833デフォルトの名無しさん

2010/03/21(日) 11:50:15

>>832
もはや反論しようが無いからABCで誤魔化して逃げてる

0834デフォルトの名無しさん

2010/03/21(日) 11:53:09

>>826
> Awrapper が明示的に抽出されていないだけで、
> その役割をBに与えてるのは同じですよね。

まだわかってねーな。
privateメソッドに抽出してもclass Dataの役割は何も変わってないし、カプセル化の度合いも変化なし。
そのこととその抽出したprivateメソッドをクラスに引き上げるのとは全然別。

0835 ◆79cfdX7bxM

2010/03/21(日) 12:19:37

>830
>なぜイコールだと思うのか、その根拠を書け。

826に書いてある通りです。
Awrapper が明示的に抽出されていないだけで、
Awrapperとしての役割をBに与えてるのは同じですよね。
（役割と言う表現が妥当かは、若干自信がありませんが。）

あとCode2は A-B が has-a な関係なのは明らかですから
is-a 関係とは言えないと思います。
※Javaのように多重継承を許さない言語系では、
　is-aな関係でも委譲の形で実装する事はあるでしょうが、
　その場合 func1 を private にする事はないはず。

0836デフォルトの名無しさん

2010/03/21(日) 12:27:59

何言ってるのかさっぱりわからない。
Code2はhas-a関係でCode1はis-a関係でしょう。

0837 ◆79cfdX7bxM

2010/03/21(日) 12:29:05

>834
DataとFileから見た両者の関係は?
少なくともData自身から見れば、Fileとの関係について
privateかどうかは関係無いと思いますが。

0838 ◆79cfdX7bxM

2010/03/21(日) 12:30:51

>836
何でCode1とCode2を比べているのですか。
>830が言ってるのはCode2とCode3では。

0839デフォルトの名無しさん

2010/03/21(日) 12:35:18

>>837
DataとFileはデータ結合だっつってんだろカスが

0840デフォルトの名無しさん

2010/03/21(日) 12:37:53

>>838
何でそんなに文盲なの。

0841>>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そのものにも問題がある場合があって、それは具象例でなければ語れない。

わかった？

0842>>830=836

2010/03/21(日) 12:43:21

付け加えて言うなら、Code2とCode3はいつでも違うのかというと同じ場合もあって、
それはやはり具象例でなければ語れない。

>>541のような具象例だと話が早いし、是非も語れる。
そして、>>541のコードだったら無駄なたらい回しだよねという結論だが、
オブジェクト指向的に間違いかどうかには決着が付いてない。

0843デフォルトの名無しさん

2010/03/21(日) 12:43:28

完全に実装の是非の話をしているのに、ABCABC繰り返すだけでお話にならん

0844 ◆79cfdX7bxM

2010/03/21(日) 12:46:09

>841
>Code3はクラスを抽出したということと、private継承下という点でCode2と異なる。
>故にCode3の是非とCode2の是非は同一ではない。

ここを詳しく。
Code3はダメでCode2はOKという例を出してくれればOKです。

0845デフォルトの名無しさん

2010/03/21(日) 12:48:15

１．馬鹿
２．不遜
３．尊大
４．横柄
５．論点無視
６．論理飛躍
８．責任転嫁
９．認知障害
１２．自制心不足
１３．認知的不協和

今日だけでこれだけ再発

0846デフォルトの名無しさん

2010/03/21(日) 12:52:37

>>844
お前は絶対実例出さないのに人にだけはそんな偉そうな態度で例示させるんだなｗｗｗ

0847>>830=836

2010/03/21(日) 12:55:09

お前が主張したいのは、Code3は駄目である、なぜならCode2が駄目であるからということだろうが、
そもそもその命題の建て方が間違ってるという指摘なんだが。

何度も言うが、具象例を出せ。

0848デフォルトの名無しさん

2010/03/21(日) 12:56:24

そもそもprivate継承はオブジェクト指向に無い概念だから論外だろ
お前は一体何の話がしたいの？

0849 ◆79cfdX7bxM

2010/03/21(日) 13:01:49

>847
逆。
Code3がダメだからCode2もダメだと言いたい。
あるいはBにAのラッパーとしての性格を持たせるのがナンセンスと言いたい。

0850>>830=836

2010/03/21(日) 13:03:54

>>844
ちゃんと説明しないとわからないか。

Code3が良いなら、それはis-implemented-in-terms-of関係なの（他のprivate継承の
例もある）だから、Code2も良い。

しかし、Code2が良いならいつでもCode3が良いとは言えない。
良い場合もあれば悪い場合もある。（だからCode2が良くてCode3が悪い例を考えても
意味がない）

そして、Code3が悪ければCode2も悪いことにはならない。

0851 ◆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;
};

0852>>830=836

2010/03/21(日) 13:07:05

クライアントがclass Dataを使用するという関係と、class Dataとclass Fileの関係を
ごっちゃにするなよ。
class Dataが何を保有しようと、privateメソッドに何を持とうと、クライアントには
Fileラッパーの性格は見えない。

0853>>830=836

2010/03/21(日) 13:10:30

>>851
ごめん、理解不能。

0854デフォルトの名無しさん

2010/03/21(日) 13:15:10

>>852
それと全く同じ指摘は200～300レス前からされてる。
その時の返答はヘッダファイルから見えるだった。

0855>>830=836

2010/03/21(日) 13:15:59

あ、これ言っとかなきゃ駄目か。
Code3は良い場合がある。それは、is-implemented-in-terms-of関係の場合だ。

今日はこれにて撤退。

0856>>830=836

2010/03/21(日) 13:17:45

あ、それから具象例というのは具体的なコード＋具象クラスのことだからよろしく。

0857デフォルトの名無しさん

2010/03/21(日) 13:24:03

お疲れ様でした

0858デフォルトの名無しさん

2010/03/21(日) 13:26:03

privateで隠せば何やってもOKと言うなら、
大半の問題ケースが許されてしまうと思うんだが。

0859デフォルトの名無しさん

2010/03/21(日) 13:28:47

>>858
クラス設計的な誤りと、それを隠蔽するかどうかと、>>541がオブジェクト指向的に
誤りかどうかは別の話。

0860デフォルトの名無しさん

2010/03/21(日) 13:46:02

private継承で実装手段以外の例としては、non-copyable-mixinだな。

0861デフォルトの名無しさん

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パターンとなる。

0862デフォルトの名無しさん

2010/03/21(日) 13:55:22

もうさ、
static A_Func1();
でいいんじゃね？ｗ

0863 ◆79cfdX7bxM

2010/03/21(日) 14:03:15

>861
>実装にある型の存在を予感させたりするのはブサイク。
A::Func1 へ丸投げするだけの B::Func1 を実装するのも
ブサイクと思うんですが。（例えB::Func1がprivateだとしても）

それをオブジェクト指向的に云々と表現するのが間違いって言うなら、
単純に漏れが言葉の選択をミスっているという事で納得できますが。

0864デフォルトの名無しさん

2010/03/21(日) 14:09:48

>>861と>>863に同じ臭いを感じるんだがどうすればいい？

0865デフォルトの名無しさん

2010/03/21(日) 14:27:43

>>861
まぁ、なんだ
>>504から読み直せ

0866 ◆79cfdX7bxM

2010/03/21(日) 14:49:29

…
とりあえず別人証明したいなら協力します、と言っておく。>861
（なんならfusianasanもする。）

0867砂漠の帝王 ◆.CzKQna1OU

2010/03/21(日) 16:18:33

俺もなんか ◆79cfdX7bxM が正しいんじゃないかって気がしてきたよ。

0868デフォルトの名無しさん

2010/03/21(日) 16:26:18

あーあ・・・

0869デフォルトの名無しさん

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() であっても、良くはないが許せる。

0870デフォルトの名無しさん

2010/03/21(日) 18:36:14

>>866
同じ臭いと言われただけでなんですぐ自演に結びつくのかね

0871デフォルトの名無しさん

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() は冗長だから問題が有るがオブジェクト指向的な理由では無い

0872 ◆79cfdX7bxM

2010/03/21(日) 22:10:20

>869
>インスタンスへのアクセスを集約しておくことは、後で思いがけず役に立ったりもする。
void B::Func1() {_a->Func1();} と実装したところで、Bの他のメンバが
a->Func1(); とFunc1を直接呼び出すのを禁止できないから、
集約するという役割は果たしていないと思うのですが。

>871
>B::Func1() が何の為に存在するのか理解してないだろ
何の為に存在すると言うのですか。

0873デフォルトの名無しさん

2010/03/21(日) 22:16:24

A とか B とか抽象的な名前にした時点で
議論するの意味なくね？

File と Data はどこ行った？

0874デフォルトの名無しさん

2010/03/21(日) 22:26:46

> void B::Func1() {_a->Func1();} と実装したところで、Bの他のメンバが
> a->Func1(); とFunc1を直接呼び出すのを禁止できないから、
> 集約するという役割は果たしていないと思うのですが。

もう何なのこの馬鹿
メンバが使う事を制限できないとか言い出したら全てが破綻するだろ

>>872
Awrapperを作ったとしてもAwrapperのメンバがA*に直接アクセスするのを制限できない問題について語れ

0875871

2010/03/21(日) 23:09:24

>>872
>>869 = 874 が書いてるんだけどなぁ
B:Func1() の存在意義は A のラッピング

君がラッパーの存在意義を理解してない事は >>872 で露呈されたよ

0876 ◆79cfdX7bxM

2010/03/21(日) 23:32:12

>874
Awrapperは、A*を隠蔽して、Awrapper::Func1の使用を
Bのメンバに強制できます。

>875
ですからラッピングしてる対象に直接アクセスできるのですから、
役割を果たしてないじゃないですか。

0877デフォルトの名無しさん

2010/03/21(日) 23:38:56

>>872
「一つのクラス内のメンバすら管理できないクソ共が途轍もなくクセェ」ってだけで、他に何か問題でもあるのか？

0878デフォルトの名無しさん

2010/03/21(日) 23:39:38

>>876
馬鹿乙

0879デフォルトの名無しさん

2010/03/21(日) 23:41:51

>>876
お前正気か？ふざけてんのか？

Awrapperを作ったとしてもAwrapperのメンバがA*に直接アクセスするのを制限できない問題について語れ

千回音読した後死ね

0880 ◆79cfdX7bxM

2010/03/21(日) 23:54:03

>Awrapperを作ったとしてもAwrapperのメンバがA*に直接アクセスするのを制限できない問題
そんなモノ無い。でおしまい。
そもそも public である Awrapper::Func1 は、自身からA*を隠すのが目的ではありませんよね。
private である B::Func1 との違いを良く考えて下さい。

0881デフォルトの名無しさん

2010/03/22(月) 00:06:14

同次元の話だが

0882 ◆79cfdX7bxM

2010/03/22(月) 00:10:31

>877
>他に何か問題でもあるのか？
ぶっちゃけ言うとそれを見つけるのが漏れの目的。
馬鹿の思索に付き合わせてすまんかった。
とりあえず「単に無駄」の領域を出ませんねこりゃ。

敢えて言うなら、コレに意味があると思う人達が居るのが問題?

0883デフォルトの名無しさん

2010/03/22(月) 00:25:54

十日以上の時を費やして何も得る物が無かったでFAなｗｗ
無能すぎｗｗｗ

0884デフォルトの名無しさん

2010/03/22(月) 00:26:45

>>876
言いたい事は分かるけどね

プロマネが『B::Func1() は A::Func1() のラップ関数ですので将来の事を考えて B のメソッド実装において B::Func1() を使って下さい』
と言ったときに君は『その実装だと A::Func1() の使用を禁じる事ができませんので Awapper を用意すべきです』って返す訳だ
俺がプロマネだったら『帰れ』って言うね

0885884

2010/03/22(月) 01:03:10

>>882
先に負け惜しみ書いて逃げてたのね、気付かずにレスして損した気分

コレって B::Func1() の事か？
完全なラッパー（生メソッドの使用を禁じる事ができる）でなくともラップの目的を果たせるのであれば意味は有るだろ
やはり何故ラップするのかって理由が判ってないんじゃないか？

B:Func1() と Awrapper で実装の手間も変わらないとか言うなよ、それこそ素人の証明になる

0886デフォルトの名無しさん

2010/03/22(月) 01:07:29

>>885
おいもうそっとしておけ
やっと「オブジェクト指向的に問題ある」と言う妄言を撤回したんだから

0887デフォルトの名無しさん

2010/03/22(月) 01:11:59

負け惜しみと言うより全面降伏だな
非常に見苦しかったが、決着はついた。

0888 ◆79cfdX7bxM

2010/03/22(月) 01:26:39

とりあえずけじめは付けるつもりでトリ付けてるので、貶すなりなんなりどうぞ。

>885
>やはり何故ラップするのかって理由が判ってないんじゃないか？
将来性考えて云々は分かりますが、B::Func1を拡張する時点で
何処で使われているか確認しないと、危険だって事は分かってますか?

0889デフォルトの名無しさん

2010/03/22(月) 01:32:34

>>888
俺たちがお前を貶めているんじゃなくて、お前が勝手に堕ちてってんだろ
悪いこと言わんからもう黙っとき

0890デフォルトの名無しさん

2010/03/22(月) 01:34:12

>>888
拡張って何？
メソッドの機能を後で変更する話ならラップ関数に限定した話では無いよね
話をすり替えてないか？

0891 ◆79cfdX7bxM

2010/03/22(月) 01:38:07

流石に>885はツッコミ入れておかないとマズイのでは…
下手すると漏れより…

0892 ◆79cfdX7bxM

2010/03/22(月) 01:40:01

>890

884 名前：デフォルトの名無しさん[sage] 投稿日：2010/03/22(月) 00:26:45
>>876
言いたい事は分かるけどね

プロマネが『B::Func1() は A::Func1() のラップ関数ですので
将来の事を考えて B のメソッド実装において B::Func1() を使って下さい』
~~~~~~~~~~~~~~~~

0893デフォルトの名無しさん

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 をラップした様なもんだからこの例えは変だけど良いのが浮かばなかったから勘弁

0894 ◆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を使い回せます。

0895デフォルトの名無しさん

2010/03/22(月) 02:20:33

>>894
勿論、B 以外のクラスでも A の機能を利用したい場合ならラッパークラスを作成するのは当然
B::Func1() はもっと手軽にラップを実現しようとした例で、もし B 以外のクラスも A を利用するならタコ実装だ

完全なラップ手法をとらなくとも用が足りてれば何の問題も無い
B::Func1() に意味が有ると言うのはそういう意味だ、いい加減に理解してくれ

0896デフォルトの名無しさん

2010/03/22(月) 07:14:48

今までの流れから、話の前提として在るのは「BがAを使う上でB独自の拡張を強制するためにAwrapperを作るか否か」なのに
Awrapperを他のクラスで使いまわすとか言い出すのはタコ過ぎるだろｗ

0897デフォルトの名無しさん

2010/03/22(月) 09:20:40

>>895-896
の書いたことは、いつもどおり通じないと思う…。
もう>>894には何も通じないとおもわれ。

Bのprivateメンバ変数を、Bがどう使うか、
BがBの都合によりどう呼び出すかは、
Bが決めることだから、
Bが用意した自分のためのprivateメソッドを、
Bが自分のために使うことは正常。

privateメソッドすら用意しなかった場合のことを考えると、
そのメリットが分かる。クラス実装上の保守性を高めている。

>>893
> そもそも Awrapper って書き方自体が変なんだよ

おれもそっちが気になる。
オブジェクト指向的に、っていうんなら、
クラス内部の実装のためのprivateメソッドがどうかというよりも、
Awrapperなんていうクラスを作ってしまうことが不気味。

0898砂漠の帝王 ◆.CzKQna1OU

2010/03/22(月) 09:22:44

おまえらクズだな

0899デフォルトの名無しさん

2010/03/22(月) 09:52:45

>>897
ラッパーって言葉は知ってたけど、その目的や存在意義を知らなかっただけでしょ
慌てて >>894 で見当違いなレスしてきたけど、今まで書いてきた事と整合性が取れてないよ
Awrapper から B を派生するのと B がラップメソッドを持つのを比較してたりしてたんだから
そして沈黙だし...

現場を知らない学生さんと見てるけど皆さんはどう思う？

0900デフォルトの名無しさん

2010/03/22(月) 09:54:18

なんという衝撃的な結末。
まさか折れるとは思わなかった。

0901デフォルトの名無しさん

2010/03/22(月) 09:58:19

>>880
> void B::Func1() {_a->Func1();} と実装したところで、Bの他のメンバが
> a->Func1(); とFunc1を直接呼び出すのを禁止できないから、
> 集約するという役割は果たしていないと思うのですが。

イコール

折角Awrapperを実装したのに、タコ男君はBのメンバを実装中にAwrapperを無視してAへ直接アクセスしてしまいました。
これではアクセスをAwrapperに集約するという役割が果せていません。
このタコ男君にAwrapperの使用を強制するにはどうすれば良いのでしょうか？？

結論
タコ男君、明日から来なくていいよ。

0902デフォルトの名無しさん

2010/03/22(月) 10:04:01

>>901
ちょｗ的確な指摘だなｗ

0903デフォルトの名無しさん

2010/03/22(月) 10:17:06

別にもう来るなとは言わないけどね
>>541 で『こーいうのが無駄だと言いたい』ではなく『何故こーいうのが必要なんですか』ってスタンスだったら
皆優しく接してたはずだろう
なんで >>541 みたいな書き方しかできないんだろうって思うよ
誰かが書いてたけど御免なさいって言えないのも悲しいし

0904デフォルトの名無しさん

2010/03/22(月) 10:23:26

またこのスレ閑散としちゃうのん・・・
なんだかんだで楽しかったのに

0905デフォルトの名無しさん

2010/03/22(月) 10:37:50

あの発言は間違ってましたごめんなさい
じゃ無く

発言は撤回しないけどキミらが貶したいなら勝手にすれば？(訳注：俺から見るとキミらの発言は「貶し」でしかないの意)
いやまてそんなことより実は○○の方が俺より酷くないか？(訳注：やっぱり俺だけ叩かれるのはイヤだの意)
だもんなｗ

これが釣りでも一字一句意識した煽りでもないんだとしたら、本当に屑野郎としか言いようが無い

0906デフォルトの名無しさん

2010/03/22(月) 10:44:15

もうあとは↑みたいな何の実もない書き込みだけが続きます。

0907デフォルトの名無しさん

2010/03/22(月) 10:49:57

祭りは終わったんだよ…

0908デフォルトの名無しさん

2010/03/22(月) 10:52:49

実は沢山なってたのに
一つも口にする事が無かった◆79cfdX7bxM
合掌

0909デフォルトの名無しさん

2010/03/22(月) 10:56:10

ここからは底辺PG名物の「人格否定」による戦犯嬲りが初まるよ！

0910デフォルトの名無しさん

2010/03/22(月) 11:03:39

>>909
つ[鏡]

0911デフォルトの名無しさん

2010/03/22(月) 11:12:03

最後に ◆79cfdX7bxM がインドリさんなのかだけ教えてもらえないでしょうか。

0912デフォルトの名無しさん

2010/03/22(月) 11:42:30

> ◆79cfdX7bxM がインドリさんなのか
流石に違うと思われ
インドリは、異論・指摘のある者全てをアラシ認定して暴れるから
奴のブログや、CodeZineでの並列処理関係の連載のコメント欄見れば分かる
いや、だからといって見る事はオススメしないけど

0913デフォルトの名無しさん

2010/03/22(月) 11:55:19

インドリさんは他のブログまで乗りこんでくるからな。

0914デフォルトの名無しさん

2010/03/22(月) 17:49:19

○ンドリブログでの直近のやり取り
ttp://indori.blog32.fc2.com/blog-entry-1003.html#cm

疲れた体に一服の清涼剤・・・

0915デフォルトの名無しさん

2010/03/22(月) 19:05:45

限界以上に簡素にしようとして、元から同じ認識を持つ人間にしか理解出来ない無意味な糞文になってるが
別に言ってる事は、まともじゃね？

↑のURLしか見てないが
◆79cfdX7bxM＝インドリと言ってる奴は相当の節穴
技術レベルが園児と高校生位は差があるっつの
インドリ憎しで汚物を撒き散らすな

0916デフォルトの名無しさん

2010/03/22(月) 19:07:18

知識レベルでは差があるかもしれないが技術レベルでは似たようなもんだと思いました。

0917デフォルトの名無しさん

2010/03/22(月) 19:15:59

>>915
どっちが園児でどっちが高校生?
いや、素で・・・

0918デフォルトの名無しさん

2010/03/22(月) 19:20:49

パイソンの人はインデント議論なんてしないのかな？
聞いた話によるとパイソンのインデントはアレなようで。

0919デフォルトの名無しさん

2010/03/22(月) 19:30:48

>>914
ざっと読んだけど（目がちかちかする）、コメント欄でかみついてる方が何言ってるのかわからない。

並列処理で起こりうる問題点を話してるのに、グローバル変数をローカル変数に持って行ったら、
グローバルで参照しているところがみれなくなるとか、なにそれな指摘。

インドリという奴がどのコミュニティでどれだけ有名なのか、あるいは全く無名なのか知らないけど、
気に入らないならそこで叩けよ。

0920 ◆79cfdX7bxM

2010/03/22(月) 19:34:05

>895,897
コードの不完全さを、運用でカバーするというスタンスはどうかと思いますよ。
他に方法が無いならともかく。

>896
>Awrapperを他のクラスで使いまわすとか言い出すのはタコ過ぎるだろｗ
使い回せるってのは>893が挙げた、AがXに変わった場合のケースですよ。
個々のクラスにラップ関数用意するのは、むしろ仕事増やしてるだけでしょうに。
クラス数×関数の数だけ修正が必要って事分かってますか?

>899
>そして沈黙だし...
メーカー系勤務なので今日も出勤です。

>901
>タコ男君、明日から来なくていいよ。
むしろこちらから願い下げです。

0921デフォルトの名無しさん

2010/03/22(月) 19:39:49

相変わらずのブッチギリ馬鹿で安心した

0922デフォルトの名無しさん

2010/03/22(月) 19:40:22

DLLでは明示的に公開クラスに指定しないと使えないけど、誰もそういう話してない？
ラッパーの話になってから、両者ともすげー読みづらいので読む気大幅ダウン。
Unix/Linuxのsoだとどうなのかな？

0923デフォルトの名無しさん

2010/03/22(月) 19:43:11

誰もそんな話はしてないな

0924デフォルトの名無しさん

2010/03/22(月) 19:46:21

>>920
いい加減自分に都合の良い前提を暗黙的に出したり引っ込めたりするのを止めろ
何時Awrapperは複数のクラスから参照される事になった

0925デフォルトの名無しさん

2010/03/22(月) 19:48:55

ぶっちゃけ、>>869以降、◆79cfdX7bxMの方が正しげな気がする。
◆79cfdX7bxMの相手をしてる方が何を主張したいのか良く解らない。

0926デフォルトの名無しさん

2010/03/22(月) 19:51:59

>>925
主張すべきものは何も持ってないのであまり触らないであげて下さい。

0927デフォルトの名無しさん

2010/03/22(月) 19:54:37

>>861ががんばってんのかな。
>>861が何を言いたいのか良くわからん。
derrivedという単語も知らんのかいな的な疑念もあるしｗ

0928デフォルトの名無しさん

2010/03/22(月) 19:56:44

derived?

0929デフォルトの名無しさん

2010/03/22(月) 19:56:47

>>918
マゾっぽいんですね。わかります。

0930デフォルトの名無しさん

2010/03/22(月) 20:03:00

>>521 >>541あたりの
privateであっても主語なんたらかんたらオブジェクト指向的に間違ってるなんたらかんたらを撤回させたいだけなんだがな。
>>920
>>882で撤回したと受け取っていいの？
凄い勢いの言い訳で撤回してるか微妙。

>敢えて言うなら、コレに意味があると思う人達が居るのが問題?
一応突っ込んでおくが、そんな奴居ないから。
お前のオブジェクト指向絡みの糞解釈を否定してるだけで誰一人その糞例を肯定していない。

0931デフォルトの名無しさん

2010/03/22(月) 20:04:14

AWrapperを作るって、例えば生Winsock APIをラップするclass Socketを作りましたって事のメタファーじゃないの？

0932デフォルトの名無しさん

2010/03/22(月) 20:05:09

この流れは>>598-601で既に見た

0933デフォルトの名無しさん

2010/03/22(月) 20:07:48

>>931
話の発端は>>521だから、そんな解釈はありえない。常識的に考えて。

0934デフォルトの名無しさん

2010/03/22(月) 20:08:04

privateメンバ変数へのアクセスを、必ずsetter/getter経由で行う流儀の人たちがいるんだけど
どうなんだろ的な話題を振ってみたりして。

0935 ◆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から派生させて作ればもっと手間が減らせます。

0936デフォルトの名無しさん

2010/03/22(月) 20:09:25

>>933
AWrapperという名前がおかしいという指摘に対する感想ね。

0937デフォルトの名無しさん

2010/03/22(月) 20:09:30

>>934
マルチスレッドのデバッグでログ入れたりするから普通にアリ。完。

0938 ◆79cfdX7bxM

2010/03/22(月) 20:11:33

>933
↓に注目。
>521
>どうしてもラッピングしたいなら、Mogeのエイリアスとなるクラスを用意して、
>そのクラスを使ってやるべき。

0939デフォルトの名無しさん

2010/03/22(月) 20:13:32

>>935
>>895を読んだ上で言ってるのか？

0940デフォルトの名無しさん

2010/03/22(月) 20:13:37

>>937
デバッグログなんか入れたら、予定外のコンテキストスイッチが起こるんじゃないか？

0941デフォルトの名無しさん

2010/03/22(月) 20:16:40

>>938
お前には文脈と言う概念が無いんだな。
元々Hogeクラス一つのprivateメソッドで用が足りるはずの物に対しての話だろ。
何時Hoge1,Hoge2,Hoge3が現れてそれらがfunc()の中でMogeにアクセスする話になった？
アンカしろ。

0942デフォルトの名無しさん

2010/03/22(月) 20:17:45

>>940
予定外のコンテキストスイッチとか言ってる時点でマルチスレッドプログラミングする資格無しｗ

0943デフォルトの名無しさん

2010/03/22(月) 20:18:16

>>938
class Socketを作るという方法でラッパークラスを作るというのは間違ってないのよ。
誰もそれが間違いだなんて言ってない。

問題になってるのは、privateメソッドでopen()を呼ぶのがオブジェクト指向的に間違いという主張。

0944デフォルトの名無しさん

2010/03/22(月) 20:20:50

ラッパー云々はどうでもいいけど、

> 問題になってるのは、privateメソッドでopen()を呼ぶのがオブジェクト指向的に間違いという主張。

ここだけ取り下げるのか取り下げないのか明確にしてくれ。

0945デフォルトの名無しさん

2010/03/22(月) 20:20:55

別に発生しても問題ないと思うけど。
動きかわって論理的なバグが出るなら直さなきゃならないものだし。

>>942
パフォーマンスとかの問題はあると思うけど。

0946デフォルトの名無しさん

2010/03/22(月) 20:23:29

デバッグログ入りだと発生しないバグというのもありそうな気がするが、まぁどうでもいい。
setter/getter使う派は、マルチスレッドなんて関係ない文脈での話ね。

0947デフォルトの名無しさん

2010/03/22(月) 20:25:47

>>946
そうだ、この変数の変更はイベントにしようって経験が多数あっただけだろ

0948 ◆79cfdX7bxM

2010/03/22(月) 20:26:56

>943-944
「オブジェクト指向的に」は既に取り下げました。
「privateメソッドでopen()を呼ぶのは間違い」は
「間違い」を「好ましくない」に改めます。

0949デフォルトの名無しさん

2010/03/22(月) 20:28:40

>>948
そうなんだ。やっと安心してこのスレから離脱できる。

>>947
お前、話にならんわ。

0950デフォルトの名無しさん

2010/03/22(月) 20:31:13

>>948
不覚にも涙が出そうになったよｗ
議論途中での間違いとかはもうどうでもいい。
俺も抜ける。

0951デフォルトの名無しさん

2010/03/22(月) 20:33:17

>>949
じゃあ逆にsetter/getterを使う事の問題は？パフォーマンス上の理由以外で

0952デフォルトの名無しさん

2010/03/22(月) 20:44:37

>>946
ビジネスロジックの「心底ウザい条件チェック」と「心底ウザい条件変更の多発」を経験してると、何だってsetter/getter経由にしたくなる

0953デフォルトの名無しさん

2010/03/22(月) 21:15:40

いまさら噛み付いてる奴も結構どっか問題ある連中なんだなと思う。

0954デフォルトの名無しさん

2010/03/22(月) 21:21:36

完全に話が終わって次の話題に移りかけてる所で蒸し返す奴も以下無限ループ

0955デフォルトの名無しさん

2010/03/22(月) 21:23:56

結局スレチな話題で半分埋まっちまったなぁ

0956デフォルトの名無しさん

2010/03/22(月) 21:38:43

何ヶ月もレスが無かったスレが言える台詞じゃないわな

と思ったが3年の歴史のあるスレがこの終り方はちょっと可哀想だわｗｗｗ

0957 ◆79cfdX7bxM

2010/03/22(月) 21:39:55

ごめんなさいw

0958デフォルトの名無しさん

2010/03/22(月) 21:49:02

このスレ2007年からなのか・・・
インデントはタブかスペースかなんてなんか長閑な話題でスタートしてたんだな。

0959デフォルトの名無しさん

2010/03/22(月) 22:34:13

終わりよければ全て良し。

0960デフォルトの名無しさん

2010/03/22(月) 22:35:36

>>951
無駄なたらい回し、ってことじゃないの？本人じゃないから真意はわからんけど。

0961デフォルトの名無しさん

2010/03/23(火) 00:04:02

これだからオブジェクト指向って役に立たないよな。

0962デフォルトの名無しさん

2010/03/23(火) 00:44:03

馬鹿の助けにはならないよね

0963デフォルトの名無しさん

2010/03/23(火) 00:47:22

>>951
コードが読みづらくなる。
つか、お前全部アクセッサ経由にしてるのか？

0964デフォルトの名無しさん

2010/03/23(火) 01:17:14

プロパティと言うステッキーな機構があるからぜんぜん読み辛くならんし

0965デフォルトの名無しさん

2010/03/23(火) 01:52:19

どちらも想定している言語の明示と、>934からの流れの確認をしないと
齟齬が生じると思うのだけど。

個人的にはプロパティのある言語（LLやC#）ならともかく、
C++やJava（6.x系まで）では微妙な気がする。

0966デフォルトの名無しさん

2010/03/23(火) 01:57:55

C++ならお得意のマクロでも使えば

0967デフォルトの名無しさん

2010/03/23(火) 03:18:43

プロパティなら30秒もあればアクセッサ経由に書換え可能だから、どうでもいい問題だな

0968デフォルトの名無しさん

2010/03/23(火) 04:05:37

コーディングの話ではなく設計の話だが、
設計から導かれる setter/getter は良い setter/getter。
実装から導かれる setter/getter は悪い setter/getter。

0969デフォルトの名無しさん

2010/03/23(火) 04:07:13

ちょっと意味が分からん

0970934

2010/03/23(火) 11:21:23

悪い、C++での話ね。

俺的にはいいも悪いも評価保留中だけど、それってどうなの的な話題ふり。
この議論は『Smalltalk Best Practice Patterns』が初出らしいんだけど、Smalltalk固有の
何かが関係しているのかどうかは不明。

ただ、俺が読んだ話（何で読んだかは忘れた）では、C++でprivateメンバ変数を
必ずアクセッサ経由で呼ぶという流派があって、その理由の一つは継承先で
getterを遅延評価に変えたりする可能性があるかららしい。

俺としては、そういう流派の人がもしいたら理由を聞きたい的なレベル。

0971934

2010/03/23(火) 11:22:31

つまり、コーディング規約で、privateメンバ変数にアクセスするときは、必ずアクセッサ経由にすること、
みたいな規約だったらどう思う？的なこと。

0972デフォルトの名無しさん

2010/03/23(火) 11:24:26

どうでもいい

0973デフォルトの名無しさん

2010/03/23(火) 11:29:53

的的うるせーよ

0974デフォルトの名無しさん

2010/03/23(火) 11:50:36

いいんじゃないの？
今時のコンパイラなら空のアクセサを直接アクセスへのコード展開ぐらいしてくれるだろうし。

0975デフォルトの名無しさん

2010/03/23(火) 11:54:16

アクセッサなら良くて>>541なら駄目というのはこれいかに。

0976デフォルトの名無しさん

2010/03/23(火) 12:00:47

アクセッサというからには、少なくともprotectedだろ。そこが>>541とは違う。

0977デフォルトの名無しさん

2010/03/23(火) 14:19:22

>>970
> その理由の一つは継承先で
> getterを遅延評価に変えたりする可能性があるかららしい。

サブクラスがスーパークラスの getter に変更を加えるってピンと来ないな
privateメンバの getter でしょ、protectedメンバじゃなくて

0978デフォルトの名無しさん

2010/03/23(火) 14:24:06

> サブクラスがスーパークラスの getter に変更を加えるってピンと来ないな

フツーにオーバーライドでは？

> privateメンバの getter でしょ、protectedメンバじゃなくて

えっ？

0979デフォルトの名無しさん

2010/03/23(火) 14:38:39

>>977
privateのsetter/getterって誰がアクセスするの？

0980デフォルトの名無しさん

2010/03/23(火) 14:56:47

はてしなく、どうでもいい話題。
アホを釣り上げて叩こうって意図？

0981デフォルトの名無しさん

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); } // 継承対策っすよ
}

0982934

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;
}

0983934

2010/03/23(火) 18:05:57

>>981の3)に付け加えて、publicで公開しないものも含めてって意味。

0984デフォルトの名無しさん

2010/03/23(火) 18:24:09

継承先で書き換えを期待してるかしてないか、または
クラス内でもフィールドの仕様が安定してないとかで変わるんじゃないの？

virtual 付けてたり、final みたいなオーバーライド禁止付けたりしないんであれば
アクセサ経由じゃないとオーバーライドの内容次第じゃおかしなことになるんじゃない？

0985デフォルトの名無しさん

2010/03/23(火) 20:23:03

お客様が仕様ですの中で暮らしているか
仕様は仕様の中で暮らしているかの違い

0986デフォルトの名無しさん

2010/03/23(火) 23:59:18

ひょっとして、みんなprivateメンバまできっちり設計とかしてんの？

0987デフォルトの名無しさん

2010/03/24(水) 00:14:32

↑しても意味が無いから変更に強いコーディングスタイルにしたいんだろ
それはもう手間の面でしか判断できん

0988デフォルトの名無しさん

2010/03/24(水) 00:27:40

>>984
virtual付けないとオーバーライドできないけど？

0989デフォルトの名無しさん

2010/03/24(水) 00:28:26

前スレ二個も、いったい何を議論してんだろうか。
次スレいるのか？

0990デフォルトの名無しさん

2010/03/24(水) 00:38:34

要らないかな

0991デフォルトの名無しさん

2010/03/24(水) 03:15:58

3年間続いたこのスレに黙祷

0992デフォルトの名無しさん

2010/03/24(水) 07:23:58

終焉記念パピコ

0993デフォルトの名無しさん

2010/03/24(水) 09:21:05

>>988
だから、「virtual 付けてたり」「finalみたいなオーバライド禁止尽けたりしないん」であれば
オーバーライドの内容次第でおかしくなるだろってこと。

0994デフォルトの名無しさん

2010/03/24(水) 10:03:57

virtual付けてなければオーバーライド出来ないんだからおかしくならないのでは？

0995デフォルトの名無しさん

2010/03/24(水) 17:06:21

>>994
だから、「virtual”付けてたり”」「finalみたいなオーバライド禁止尽けたりしないん」であれば
オーバーライドの内容次第でおかしくなるだろってこと。

0996デフォルトの名無しさん

2010/03/24(水) 17:24:34

オーバーライドの内容次第でおかしくなるか？
privateメンバだぞ？

0997デフォルトの名無しさん

2010/03/24(水) 17:31:22

protected、public なアクセサの話だぞ？
>>981 >>982 みれ

何ぞこのアホな幕引きは・・・

0998デフォルトの名無しさん

2010/03/24(水) 17:32:30

> アクセサ経由じゃないとオーバーライドの内容次第じゃおかしなことになるんじゃない？

要するに何が言いたいんだろう？
オーバーライドしようがしまいが、アクセッサ経由でしかアクセスできないだろ。

0999デフォルトの名無しさん

2010/03/24(水) 17:33:44

>>997
privateメンバ変数の話だぞ？>>934見ろ馬鹿。

1000デフォルトの名無しさん

2010/03/24(水) 17:34:59

最後は激烈馬鹿で終了。

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。

コーディング規約 第3条

コーディング規約第3条