社会人であり、技術者であり

オブジェクト指向再考 連載目次
2012/11/18 コメント欄の指摘を受け、全面改定しました。

最近、忙しくてすっかりブログを更新していませんでしたが、それでもADPの開発は続けておりその関連で調査をしていましたら、あまりにも程度の低い小説がありましたのでちょっとコメントしてみます。

発端は今から2年前のこの記事になります。

実はオブジェクト指向ってしっくりこないんです！（みながわけんじ）
よく解らない内容の記事なのですが炎上した記事です。ちなみにこの記事のコメント欄のryoというのは私です。


その後、この小説が書かれました。

高慢と偏見（1）隣は何をする人ぞ
高慢と偏見（2）使徒襲来
高慢と偏見（3）コードレビューは踊る
高慢と偏見（4） 嵐の金曜日
高慢と偏見(5) そして戦いがはじまる
高慢と偏見（6） いつかの誰かのためのドキュメント
高慢と偏見（7） 28日後……
高慢と偏見（8） 敵は身内にもあり
高慢と偏見(9) 誰がスケジュール遅らせた？ それはあなたとプロマネは言った
高慢と偏見（10） 夏への扉
高慢と偏見（11） 現実は映画じゃない
高慢と偏見(12) 新人くんのささやかな主張
高慢と偏見(13) 一矢
高慢と偏見（終）　エピローグ

大変長い小説で、著者（リーベルG）さんはフィクションと言っていますが、この小説は先の記事に対する程度の低い風刺になっています。

こういうのは捨て置いていたらよいのですが、私も齢４０を過ぎ、後輩の方達へきちんと伝えるべきことを伝えたほうがよろしいかと思い何が問題か指摘します。

特定の人物を不当に貶める

一番に聞いてみたいことですが、この小説の著者は名誉棄損または誹謗中傷という言葉を知らないのでしょうか？、この著者（リーベルG)さんはいじめ問題がどのような人間の心理から出てくるかわからないのでしょうか？
もっとも今は何を言われても分からないかもしれません。が、まぁ後１０年経てば分かるかもしれません。

高慢と偏見の最終話ですが後半は『実はオブジェクト指向ってしっくりこないんです！。』のパロディと思わせるないようとなっています。

後半の出だしを引用します。

アツコさんから久しぶりにメールが届いた。そこには「面白いもの見つけたよ」とあり、1つのURLが載っていた。

　開いてみるとブログだった。タイトルは、

　「SEのサバイバル入門」

　サブタイトルに「過酷なSE業界を生き延びるノウハウを伝授する」とある。ブロガーは「スリービーチ」。スリービーチ？ 3つの浜辺？ ひょっとして……

　最新の日記は、

　「オブジェクト指向など、実業務では使いものにならない！」


このタイトル「SEのサバイバル入門」とサブタイトル「過酷なSE業界を生き延びるノウハウを伝授する」は当時の、
みながわさんのコラムのタイトルとサブタイトルのパロディであることが分かるでしょう。
今のみながわさんのコラムのタイトルとサブタイトルは違うものになっていますが、当時のみながわさんのコラムのタイトルとサブタイトルは、こちらで確認できます。

その他の類似例を表にまとめます。
高慢と偏見最終話実はオブジェクト指向ってしっくりこないんです！ －本文－
staticを使えば、わざわざインスタンスを作る必要などない「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。
独自にクラスを作る必要などない。クラスは使うものだ。作るものではない「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。
オブジェクト指向など、実業務では使いものにならない！オブジェクト指向は、結局のところホントにモノ（オブジェクト）に使われている記法、例えばGUI コンポーネント、データベース、ファイルなどであって、プログラムのアルゴリズムとは無関係のものである。
 
高慢と偏見最終話実はオブジェクト指向ってしっくりこないんです！ －コメント欄－
私はT大学大学院卒だ私は学部は東北大学で大学院が東工大です。
あなたはSIerだろう。私は客側の人間だ。客の言うことは絶対だ私はIS部門の人間なんです。SIerの客なんですよ。私に嫌われたらどうなりますか？

類似点は他にもあるのですが、これを見れば、「高慢と偏見の最終話」にあるスリーピーチ（三浦さん）のブログのモデルは、『実はオブジェクト指向ってしっくりこないんです！』であり、スリーピーチ（三浦さん）はみながわさんということを示唆していると受け取られても仕方がないでしょう。実際にそのように受け取っている方もいらっしゃいます。
「高慢と偏見の最終話」のコメント欄からいくつか引用してみましょう。

toanna 2011年2月21日 (月) 23:33 （一部引用）
まとめサイトしても読める！！
まとめサイトというのは『実はオブジェクト指向ってしっくりこないんです！』の炎上部分を示唆していると受け取れます。

音速の気功師 2011年2月24日 (木) 01:27 （一部引用）
あれが論外なのは言うまでもない事実です。それは認めます。
あれというのは誰かは指摘しなくても解るでしょう。

通して読みました 2011年8月 9日 (火) 19:04 （一部引用）
ただ、途中からコメント欄に書いてある(ネタバレ？）を
見ていて、純粋に読み物として読んでいて、つまらなくなってしまいました。
内容がコメント欄とかぶってくるのか、単に例の人を貶めるような内容として、
読み進んでしまったのが、自分としての反省です。

さて、このコメントでは『例の人を貶めるような内容として、読み進んでしまったのが』と書かれています。
貶めるというのは、本文中の

たまに別のWebサイトのコメント欄に、オブジェクト指向批判を書くこともあった。当然、技術的な裏付けも何もない、思い込みによる批判だから、正論で完膚なきまでに叩きのめされてしまう。正面から議論を展開できるだけの知識がないから、スリービーチさんにできることは、「その日本語はおかしい」とか「若い人はすぐに感情的になるから議論にならない」などと、負け惜しみを書くことだけだった。

という書き込みの他、

ソースを調査したコンサルティング会社のエンジニアは、あまりに効率の悪い前時代的なコーディングに絶句したらしい。そりゃそうだろう。私だって、事前知識なしであのソースを見たら驚く。

　「時代錯誤も甚だしい」

　「保守性というものをまった考慮していない」

　「最低でも6カ月を要する、根本的な大改造が必要」

　コンサル会社からの報告書には、このような指摘が続々と連なっていたという。調査の過程で、開発方針が途中で大幅に変更された事実も明らかになり、三浦マネージャは連日のように、専務やら常務やらの前で釈明に追われることとなった。平良さんら何人かの常駐メンバーも事情を聞かれたが、三浦マネージャを積極的に擁護しようとする人はいなかったようだ。中には、あからさまに批判するメンバーもいたらしい。

とか、締めの文章

　高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。

　三浦技術担当マネージャは、そのようなエンジニアの生きた見本のような人だった。

とか随所にあります。その他いちいち抜き出すことはしませんが、『高慢と偏見の最終話』の後半部分、『そして数カ月後。』からを読んで頂ければ解るでしょう。

ちなみに文中にあります『ポリモリズム』は『ポリモーフィズム』の間違いです。みながわさんは『実はオブジェクト指向ってしっくりこないんです！』のコメント欄でポリモーフィズムを数回、書き間違えておられました。それをもじったものだと推測されるでしょう。


これでは三浦マネージャ＝みながわ氏が成立し、特定の人物を貶める内容になっているのではないでしょうか？

その他の例（ポリモーフィズムの例）

この小説は、他にも『三浦マネージャ＝みながわ氏』をうかがわせると思われるエピソードがあります。
高慢と偏見（3）コードレビューは踊る の『List userNameList = new ArrayList();』にまつわる論争部分です。

これは、以下のコメント欄の論争から取られていることがうかがわされるでしょう。

http://el.jibun.atmarkit.co.jp/densol/2010/08/post-8443.html オブジェクト指向。教科書と現実のはざまで
このコラムのコメント欄にみながわさんが書き込んでいますが、いきなりAC/DCさんが、みながわさんを批判し、コラム主から注意を受けています。

さて、みながわさん、AC/DCさんどちらがマナーのある人でしょうか？

もちろんですが、みながわさんがstaticが・・・と言い出したらそのときにまた反論すればよろしいかと思います。

さらにflatlineさんが

＞たとえば、Javaで、
＞List userNameList = new ArrayList();

とコラムの趣旨とは異なる議論を吹っかけています。
みながさんもこれに対して

＞ArrayList list = new ArrayList();
＞のように基底クラスを使わない例が一般的です。


と応戦してしまっています。

ここで、この"一般的"の趣旨について補足します。まず
　List userNameList = new ArrayList();
の書き方はjavaが出た当時はある意味画期的だったのですが（当時そういう風に紹介している書籍もあった）、他の言語では、良くない例とされています。根拠は「Effective STL」に書いていますしCMPさんと同名の方や他の方も「高慢と偏見（3）コードレビューは踊る」のコメント欄に同様の趣旨のことを書かれています。要するにArrayListとLinkedListの概念を統合・抽象化（Listインタフェース）しても意味がないのです（ほぼゴミ）。そのような訳でして実は、C++/STLや後から出てきたC＃ではみながわさんが言ったような書き方 し か 出来ません。
これに"一般的"という言葉を使うことが適切かどうかという批判はあるかと思いますが、java以外の”一般的な”オブジェクト指向言語という意味ではまぁOKでしょう。

flatlineさんは「一般的です」という断定の言葉尻をとらえるのではなくてみながわさんが言っていることの意味（というかその背景）をもっと深く、理解する必要があります。

このような状況下で、flatlineさん個人の感想として、みながわさんのことを『話を聞かない人』と思うのは構いませんが、客観的にみると？と思うわけです。
もちろん、みながわさんも『C＃では一般的』と言えば話が進んだのでもう少しコメントするときに考えて頂ければとは思いました。

そういう意味では『どっちもどっち』ということになります。

以上を踏まえて、「高慢と偏見（3）コードレビューは踊る」を読むと、ものすごい誤解から一方的に書かれていることが分かるかと思います。私には何が面白いのかまったく分かりませんでした。

（主人公目線で）みながわさんがオブジェクト指向が解らないから『ArrayList list = new ArrayList();』と書かれていますが、ちがうことが解りますよね。
ちなみにこの「高慢と偏見（3）コードレビューは踊る」でも、

　「ポリモーフィズムです。ポリモリズムでもポリフォリズムでもありません」

　三浦マネージャの顔色が一瞬変わったが、すぐに薄ら笑いを浮かべた。

とポリモーフィズムの間違いのエピソードが出てきています。



以上、『高慢と偏見』がみながわさんのコラムおよびその他のエンジニアライフのコラムの論争のパロディであることをうかがわせるような内容となっています。
このようなパロディは他にもあり、当時の論争を知らない人にはぱっと見て解らないかと思いますが、『高慢と偏見』の本文とコメント欄をみれば、どういうことが解るかと思います。


エンジニアなら技術的な論争があった場合、あくまでも技術的かつ論理的に反論しましょう。相手が聞く耳を持たないと判断する前にもう一度、ご自身の説得力に問題がないか検証しましょう。論争相手を貶めるようなことはエンジニアとしては慎みたいものです。

2012/11/03 加筆、修正
2012/11/06 修正
2012/11/14 修正 質疑応答をアップしました
2012/11/18 コメント欄での指摘を受け、全面改定
2012/12/02 修正
2016/01/31 関連記事をアップしました
2012-11-01 | コメント:66件
通りすがりより
2012-11-07 14:51:07
もうちょっとしっかり読んだ方がいいんじゃないの？
高慢と偏見は、オブジェクト指向って素晴らしい、という話じゃないよね。
みながわさんが、人の話を聞く気がないのは、彼のサイトをみれば明らかでしょう。例のコラムでも、都合の悪い質問はスルーするか見当違いの答えでごまかしてるし。
あなたこそ、思いこみで誹謗中傷だと決めつけてる。よく読みもしないで。そういう態度は、エンジニアとして慎みたいものだな。
おおふじより
2012-11-07 19:19:30
通りすがりさん

コメントありがとうございます。このような方がいらっしゃると思ったのでわざわざ記事にしました。
が私の記述がたりませんでしたか。
とりあえずコメントされるのなら以下の点を明確にしてコメントして下さい。

・名前を名乗って下さい（ハンドル名でよい）
・連絡先を書いて下さい（有効なメールアドレス、ウェブサイト）
・間違いの指摘は具体的に行って下さい。

今後は上記の記述がない方の投稿は削除させて頂く場合があります。

＞高慢と偏見は、オブジェクト指向って素晴らしい、という話じゃないよね。
あなたがどこまでオブジェクト指向について理解しているかわかりませんが、高慢と偏見で扱っている技術的な面について不充分な点を指摘しています。不充分な知識を元に議論したら、みながわさんでなくても『それは違う』と反論するでしょう。それは『人の話を聞かない』ことにはなりません。

＞例のコラムでも、都合の悪い質問はスルーするか見当違いの答えでごまかしてるし。
繰り返しになりますが、私のコメント他、何人かの意見については聞いています。通りすがりさんこそきちんと読みましょうね。

＞あなたこそ、思いこみで
思い込みではありません、きちんと根拠があります。もう一度いいます。みながわさんは私および他の何人かの意見については聞いています。それを『人の話を聞かない』と言えば違うとしか言いようがありません。

おおふじより
2012-11-07 19:45:37
連投失礼、補足します。

>みながわさんが、人の話を聞く気がないのは、彼のサイトをみれば明らかでしょう。
彼のサイトは見ましたが、示唆に富んでいます。研究の為、ちょくちょく訪れようかと思っています。
掲示板をみてみましょう。少ないですが私以外にもまともだという書き込みがありますよ。

みながわさんは人の話を聞かないのではなく、論理的、技術的に考えておかしいことをおかしいと言っているだけです。
これは裏を返せばきちんとした説明であれば、答えてくれるということです。
『実はオブジェクト指向はしっくりこないんです』は、かなり激しいやり取りがあったので適切でない表現もあったでしょう。
コメント欄が長いので混乱するかと思いますが、もう一度私(ryo)とみながわさんとのやりとりをみてください。

きちんと説明すればみながわさんは納得してくれることがわかります。
CMPより
2012-11-09 15:53:27
＞みながわさんは人の話を聞かないのではなく、論理的、技術的に考えておかしいことをおかしいと言っているだけです。
しっくりこない、理解しにくいという評価は共感こそすれど、StaticにすればOK!という暴言にはそれこそ「後輩の方達へきちんと伝えるべきことを伝えたほうがよろしいかと思います」が。
で、その暴言に対して「訂正」なり「修正」はしましたか？（私が見落としているだけかも知れないので、あるのであれば、教えてください）

論理的、技術的にもおかしいと指摘されていることに対して、論点をずらしたり無視することが「話をちゃんと聞く人」のすることですかね？
おおふじより
2012-11-09 20:48:06
CMPさん

あちらではなくこちらの方へコメントを書いて頂きありがとうございます（あっちだと荒れますからね）。

>論理的、技術的にもおかしいと指摘されていることに対して、論点をずらしたり無視することが「話をちゃんと聞く人」のすることですかね？

あちら側の私のコメントで、”一般的”という皆さんが誤解しそうな表現については私なりの解釈を入れましたが、バイタルさんも本気で分からないみたいなのでちょっと補足記事を書こうと思ってたとこです。
ちょっとお時間を頂戴しますが、それを読んで頂ければと思います。
あと、当然ですが、みながわさんの発言がすべてちゃんとしているとは言ってないのでその点はご理解下さい。

＞で、その暴言に対して「訂正」なり「修正」はしましたか？

まず、すべてをstaticで書いてしまったらプログラムは動かないでしょう。そういう意味ではみながわさんもインスタンスを作っているはずです。
次に、私も含めて、ほとんどのエンジニアは例の記事の内容には同意していません。ので、後輩達にきちんと伝えるべき事とは認識していません。

以下、私が同意していないことを主張している箇所を指摘します。

まず、このブログでは例の記事を『よく解らない内容の記事』と評しています。

続いて例の記事のコメント欄

>ryo 2010年4月23日 (金) 15:45 から
>>staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。
>と書くと「己の無知を知らない恥ずかしい人が他人を笑っている」としか受け取れません。

>ryo 2010年4月27日 (火) 16:34 から
>後輩：せんぱーい、この人staticって言いたいだけで、何が言いたいのかさっぱり解りません。

>ryo 2010年4月28日 (水) 10:58
>まぁ、『staticって言いたいだけでした。愚かな私に教えを！』というのならまたお邪魔するかもしれません。

>ryo 2010年5月 1日 (土) 01:21
>元々、staticを覚えたてのおじちゃんがうれしがって書いた冗談みたいな記事

と何回も書いていますよ。
CMPより
2012-11-10 02:21:39
返答ありがとうございます。
おおふじさんがいろいろ説明してたくだりはちゃんと読みました。

ですが、みながわ氏は結局誤った内容を記載したコラムに対して、訂正や修正、（よい子はまねしないでね）等の注意喚起の追加が一切ありませんよね？
むしろ、「Staticを推奨して何が悪い」と開き直ってるとしか思えませんが。
とてもじゃないが、みながわ氏が「話をちゃんと聞く人」という評価にはなりえません。

後輩達にきちんと伝えるべき事は「みながわ氏みたいにはなるな」の一言に尽きます。
おおふじより
2012-11-10 10:06:35
CMPさん

ご返信ありがとうございます。


＞訂正や修正、（よい子はまねしないでね）等の注意喚起の追加が一切ありませんよね？
私のコメントを読んだということでしたら、なぜ注意喚起をしなかったかは解るかと思うのですか？
[[追加]]私は『もうのりません。』と書いています。

＞とてもじゃないが、みながわ氏が「話をちゃんと聞く人」という評価にはなりえません。

私が主張しているのは、『話を聞かない人』ではないということです。「話をちゃんと聞く人」ではありません。
「話をちゃんと聞く人」かどうかの判断は各自でお任せします。

どうも『話を聞かない人』ではない＝＝「話をちゃんと聞く人」という話になっていますが、違いますよね。


＞後輩達にきちんと伝えるべき事は「みながわ氏みたいにはなるな」の一言に尽きます。

SE・PGというのは、お客さんや同僚、上司、部下等、さまざまな人達と話をします。中にはみながわさんのようなお客さんもいらっしゃるでしょう。「みながわ氏みたいにはなるな」という評価を下すとその時点で偏見が生まれコミュニケーションが取れなくなります。
私はみながわさんに『了解！』と言わせました。なぜそういうことができたかと思われますか？
会話の言葉尻や表面的な態度を鵜呑みにし、相手の真意を理解せずに『あいつはこういう人間だ！』と決めつけないで技術的かつ論理的に話をしましょう。というのが、私が後輩達に伝えたいことです。
CMPより
2012-11-10 15:17:35
すみません、ごちゃごちゃして申し訳ないです。整理します。

えっと、
[1]おおふじさんとみながわ氏とはコミュニケーションは取れていた。
これは事実です。ただ、おおふじさんのコメントの内容をきちんと理解しているかは胡散臭いですが。（その後のコメントを読んだ上での感想）

[2]「『話を聞かない人』ではない＝＝「話をちゃんと聞く人」」では”ない”。
おおふじさんの指摘とおりです。これは私が飛躍しすぎました。

[3]私はみながわさんに『了解！』と言わせました。なぜそういうことができたかと思われますか？
おおふじさんのコメントは「ちゃんとしてる」文章となっています。この点はみながわ氏も同意してます。
ですが、この「ちゃんとしてる」が曲者で、技術系の記事ではこれが原因でよく炎上しています。
「ちゃんとしてる」の意味は書かなくてもいいですよね？このブログにも書いてあるし。

[4]「『話を聞かない人』ではない」という評価は「実はオブジェクト指向ってしっくりこないんです！」でのみの評価
残念ながら、私はそれだけでなく他のコラムニストへのコメントを含めて評価しています。
今は完全に「話を聞かない人」になってます。昔は「『話を聞かない人』ではない」のかも知れませんが。
＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾
↑これを言いたかっただけかも・・・。
おおふじより
2012-11-11 10:21:08
CMPさん、よく整理されているかと思いますのでこのまましばらくこのコメントが目立つようにさせてください。
ということで私の返信は後で行います。
CMPより
2012-11-13 12:11:14
構いませんよ。それだけの覚悟を持ってここに書き込んでいるのですから。

でも、なるべく早いうちに返信お願いします。
自分のことながら、何時までもここのURLを覚えてるとは思いませんので（＾＾；
おおふじより
2012-11-13 20:22:07
CMPさん

お待ち頂きましてありがとうございます。あっちが落ち着ついたので、もう進めてもよいかと思います。と思ったら・・・もう。

さて [1], [2]については合意ということで（胡散臭いところは・・・胡散臭くお茶を濁させてください）。

[3] 私のこのブログの趣旨は伝わったかと思います。
　『ちゃんとしてる』のが曲者については後ほど、コメントしますが、一部[4]のコメントに関連した内容を書きます。

[４] これが、今回、私が出張ってきた理由です。
　ご存知のとおり「実はオブジェクト・・・」のコラムは炎上して多くの人が書き込みました。そこで、『一本とった』と感じた人や、興味がなくなった人はエンジニアライフに寄り付かなくなったかと思います（私もそうですし）。
そして、エンジニアライフでは『話を聞かない人』と感じた多くの人が残ったようで、その後、執拗にみながわさんを追っかけたようです。

例えば、以下のコラムがあります。

http://el.jibun.atmarkit.co.jp/densol/2010/08/post-8443.html

このコラムのコメント欄にみながわさんが書き込んでいますが、いきなりAC/DCさんが、みながわさんを批判し、コラム主から注意を受けています。

さて、みながわさん、AC/DCさんどちらがマナーのある人でしょうか？

もちろんですが、みながわさんがstaticが・・・と言い出したらそのときにまた反論すればよろしいかと思います。

さらにflatlineさんが

＞たとえば、Javaで、
＞List userNameList = new ArrayList();


とコラムの趣旨とは異なる議論を吹っかけています。
みながさんもこれに対して

＞ArrayList list = new ArrayList();
＞のように基底クラスを使わない例が一般的です。


と応戦してしまっています。

ここで、この"一般的"の趣旨について補足します。まず
　List userNameList = new ArrayList();
の書き方はjavaが出た当時はある意味画期的だったのですが（当時そういう風に紹介している書籍もあった）、他の言語では、良くない例とされています。根拠は「Effective STL」に書いていますしCMPさんと同名の方や他の方も「高慢と偏見（3）コードレビューは踊る」のコメント欄に同様の趣旨のことを書かれています。要するにArrayListとLinkedListの概念を統合・抽象化（Listインタフェース）しても意味がないのです（ほぼゴミ）。そのような訳でして実は、C++/STLや後から出てきたC＃ではみながわさんが言ったような書き方 し か 出来ません。
これに"一般的"という言葉を使うことが適切かどうかという批判はあるかと思いますが、java以外の”一般的な”オブジェクト指向言語という意味ではまぁOKでしょう。

flatlineさんは「一般的です」という断定の言葉尻をとらえるのではなくてみながわさんが言っていることの意味（というかその背景）をもっと深く、理解する必要があります。

それには、
『クラスではなく、インターフェースに向かってプログラミングしろ』
という一見きれいな格言に惑わされずに、多くの具体例にあたり精進する必要があります。

つまり、当時の文面から想像されるflatlineさんの知識（およびコミュニケーション能力）では、みながわさんにポリモーフィズムを教えることは厳しいだろうというのが、私が感じたことです。加えてflatlineさんがその事に気がついていないようだということも感じていました（こういうのが一番厄介なんですよだからこういう状況下で技術的な議論をしてはダメで先ずは逃げるが勝ちとなります）。

このような状況下で、flatlineさん個人の感想として、みながわさんのことを『話を聞かない人』と思うのは構いませんが、客観的にみると？と思うわけです。
もちろん、みながわさんも『C＃では一般的』と言えば話が進んだのでもう少しコメントするときに考えて頂ければとは思いました。

そういう意味では『どっちもどっち』ということになります。が、みながわさん一人が『話を聞かない人』と言われるとおかしいと思う次第です。

こういう事が積み重なると、みながわさんにとっては相当なストレスだったろうと想像できますし、頑になるのはしょうがないかと思います。

以上を踏まえて、「高慢と偏見（3）コードレビューは踊る」を読むと、ものすごい誤解から一方的に書かれていることが分かるかと思います。私には何が面白いのかまったく分かりませんでした。
CMPより
2012-11-14 00:34:51
おおふじさん、いろいろご苦労様です（笑）。

＞CMPさんと同名の方
これ、私です。
よけいな一言付きでお恥ずかしい（＾＾;

＞http://el.jibun.atmarkit.co.jp/densol/2010/08/post-8443.html
このコラムとコメントは初めて見ました。
みながわ氏なりに勉強はしてたんだなということがわかりました。
が、感想は「やることやってから発言すべき。それまでは表にでてくるな！」です。

私はおおふじさんの言いたいことの全体像（経緯と背景）が理解できました。
他の人もそうだと思います（というか思いたい）が、「フィクションと現実を直結しすぎてるのはおおふじさんじゃない？」ってことです。
事件を知らない読者はそこまでは見てないかと。
仮に事件を知られてしまっても、みながわ氏が発言の撤回や内容の修正などしていれば、問題ないはずですがね。（炎上させた事実だけは残りますが）

私のみながわ氏への評価を「『話を聞かない○▽■○』」から「『話を聞かないわけではない』が、表舞台へは○▽■○▽■○▽■○▽■○▽■」」に変更ということで話を終息したいのですがよろしいでしょうか？


おおふじより
2012-11-14 08:07:20
CMPさん

CMPさんがコメントしないのではあればそれで構いませんが、みながわさんへの評価を決めるのは早すぎるかと思います。

＞『話を聞かないわけではない』が、表舞台へは○▽■○▽■○▽■○▽■○▽■」

落ち着いて読み返してください。これでは、ただの暴言ですよね？

私はCMPさんやその他、みながわさんのことを「話を聞かない人」と言っている人たちを攻めるつもりはありません。
あくまでも誤解を解きたいだけです（まぁその辺りは分かってもらえているかと思いますが）。

＞他の人もそうだと思います（というか思いたい）が、「フィクションと現実を直結しすぎてるのはおおふじさんじゃない？」ってことです。

これは私だけではありませんよ。

あのコメント欄

＞『音速の気功師 2011年2月24日 (木) 01:27』さんの発言
＞『あれが論外なのは言うまでもない事実です。それは認めます。』

とか

＞通して読みました 2011年8月 9日 (火) 19:04

＞内容がコメント欄とかぶってくるのか、単に例の人を貶めるような内容として、
＞読み進んでしまったのが、自分としての反省です。

とかね。

悪影響が出ていることは事実です。それで高慢と偏見の作者は何かケアをしましたか？
おおふじより
2012-11-14 12:12:50
どうも、私がフィクションと現実を混同しているという話ですので、補足です。まぁ全体が整理されてから別途まとめ記事を書きますが、とりあえずコメント欄（あっちに書くと荒れるのでこっちに書きます）に、
フィクション
および
　「"みながわさん＝三浦マネージャ"で間違いない」
の点の根拠について。


フィクションについては、以下、のページをご覧下さい。

『事実をフィクションとして書いたら名誉毀損やプライバシー侵害になりますか？』
http://www.bengo4.com/bbs/142497
では、
『ケースバイケースです。そのような注釈付きでも、特定の人物のことを示しているということが分かれば、名誉毀損・プライバシー侵害になる場合もあるでしょう。』と専門家の方が回答されていますね。


「"みながわさん＝三浦マネージャ"」
に関してですが、特定の人物を示すという点ですが、こちらはあまり異論はないでしょうが

http://ja.wikipedia.org/wiki/名誉毀損罪
から
『被害者の氏名を明確に挙示しなかったとしても、その他の事情を総合して何人であるかを察知しうるものである限り、名誉毀損罪として処断するのを妨げない（最判昭和28年12月15日刑集7巻12号2436頁）。』
とあります。『処断するのを妨げない』という言い回しが分からない方がいるかと思いますので、ニュアンスを言い換えますと『処断する場合がある』ということになります。

つまり多くの人が高慢と偏見のモデルはみながわさんと判別できている時点で、
　高慢と偏見の三浦マネージャ　＝　みながわさん
としてよいでしょう。

ここまではOK？
CMPより
2012-11-14 13:34:42
＞落ち着いて読み返してください。これでは、ただの暴言ですよね？
ただの暴言です。
そのまま書くとなんか負けたような気がしたので、暴言にのせて主旨変更させていただきました。
これこそ名誉毀損ですね。

＞「"みながわさん＝三浦マネージャ"」
＞に関してですが、特定の人物を示すという点ですが、こちらはあまり異論はないでしょう
＞つまり多くの人が高慢と偏見のモデルはみながわさんと判別できている時点で、
＞　高慢と偏見の三浦マネージャ　＝　みながわさん
＞としてよいでしょう。
＞ここまではOK？
書き込まれたコメントからも「特定の人物への誘導を示す」ものが見受けられます。
また、有名な事件のあったサイトである以上、特定の人物へ結びつけやすいとも言えるでしょう。
つまり、まわりの状況が特定の人物へ結びつける環境を作っていると言えます。

ですが、リーベルＧさんはみながわ氏を三浦マネージャをモデルとしていると明言してますか？
明言していれば、おおふじさんの言うとおりです。
たまたま、みながわ氏と同類の人が半径３ｍにいただけかも知れませんよ？
その人をモデルとしてた場合はどうなるんでしょう。
それこそ、おおふじさんが言いがかりつけてるだけになりますよ？
ってことを理解してほしいです。

ここはリーベルＧさんへの批判より、ミスリードしやすい環境であるにも関わらず掲載を許した編集部を批判すべきではないでしょうか。
通りすがりより
2012-11-14 15:29:58
メインの話題とは全く関係無いんですが。

> 未だに、業務アプリのビジネスロジックにオブジェクト指向をうまく適用できた具体例を聞いた事がありません。あれば教えてください。

なぜ、「業務アプリのビジネスロジック」という限定をするのか良くわかりませんが、"業務システム"でJavaが採用されているのをどうお考えですか？それらは、すべてうまく適用できていないと思いますか？

POSAやPoEAAという言葉はご存じですか？ご存じの場合、それらは"業務システム"には全く適用できないものなんでしょうか。

なお、私の少ない経験の中でも、EJBを使った銀行系の超大規模システム(5000人月超え）は成功しましたし、NTTDがやったNTTの料金システムなどでもJavaが使われていたはずです。
通りすがりより
2012-11-14 15:34:23
書き忘れましたが、富士通やNTTDなどは、業務ロジックを構築するための「なんちゃらframework」というのを結構製品化してますよ。（その他の大手の動向は知りませんが）

それらを採用するのは意味が無いことなんでしょうか。
また、採用したところは全て失敗（というと言い過ぎですが）してるのでしょうか。

私はそうは思いません。
おおふじより
2012-11-14 21:02:02
通りすがりさん

コメントありがとうございます。ご指摘のとおりちょっと言い過ぎた面があります。

ただ、例えば『なんちゃらフレームワーク』の場合、
これらのフレームワークが、例えば、RDBのように市民権を得るまでには今のところ成功していないでしょ？
というのが先の私のコメントの趣旨です。ある事は知っていますが、無いと業務アプリが作れない（RDBのように、それを使うと劇的にコストが下がるとか信頼性が高まるとか）ということでもないでしょうということです。

もっとも、元の私の文章ですが、『高慢と偏見』に書かれている内容に対してで、それを一般論化さるのは誤解を生みますし、時間が取れた時に修正しようかと思います。
おおふじより
2012-11-14 21:04:15
CMPさん

＞これこそ名誉毀損ですね。

なるほど、了解しました。一応、ここも公開の場なので、不適切な発言については修正（○○を入れます）しますが、OKですか？

＞書き込まれたコメントからも「特定の人物への誘導を示す」ものが見受けられます。
＞また、有名な事件のあったサイトである以上、特定の人物へ結びつけやすいとも言えるでしょう。
＞つまり、まわりの状況が特定の人物へ結びつける環境を作っていると言えます。

同感です。本来ならそのようなコメントは削除すべきだと思います。
もちろん、私の最終話に対するコメントもこの騒動が収束すれば削除依頼を出そうかと思っています。

＞ですが、リーベルＧさんはみながわ氏を三浦マネージャをモデルとしていると明言してますか？
＞明言していれば、おおふじさんの言うとおりです。
＞たまたま、みながわ氏と同類の人が半径３ｍにいただけかも知れませんよ？
＞その人をモデルとしてた場合はどうなるんでしょう。

これはすこし無理があるかと思います。高慢と偏見の最終話ですが後半は『実はオブジェクト指向ってしっくりこないんです！。』のパロディとなっています。

＞それこそ、おおふじさんが言いがかりつけてるだけになりますよ？
＞ってことを理解してほしいです。

言いがかりではないですが、責めていると批判されても仕方がないかもしれません。ただ解って頂きたいことですが、どのような言葉・態度を示しても、『言いがかり』と感じる人が出てきてしまうことも事実です。
そのぐらい、あの小説はきれいに書いてあることは理解します。
ので編集部の方がGOを出すのもしかたがないかと思います。それでも一部の方（および私）は問題点を感じとったわけです。

＞ここはリーベルＧさんへの批判より、ミスリードしやすい環境であるにも関わらず掲載を許した編集部を批判すべきではないでしょうか。

あくまでも作品に対する批判およびその要望の為、リーベルGさんに質問という形をとっています。
もし私のブログの表現で誤解を与える箇所があれば訂正致します。

＞ミスリードしやすい環境であるにも関わらず掲載を許した編集部を批判すべきではないでしょうか。

同感です。ただ、こちらについては現在、対応を依頼している最中ですのでその結果を待ってみてもよろしいかと思います。
CMPより
2012-11-14 23:15:39
あっちこっちでの対応、本当にご苦労様です。

＞＞これこそ名誉毀損ですね。
＞なるほど、了解しました。一応、ここも公開の場なので、不適切な発言については修正（○○を入れます）しますが、OKですか？
この件はおおふじさんにおまかせします。修正せず公開処刑しても構いませんし、ブログの品位に関わるから即修正でも構いません。

＞＞ですが、リーベルＧさんはみながわ氏を三浦マネージャをモデルとしていると明言してますか？
＞＞明言していれば、おおふじさんの言うとおりです。
＞＞たまたま、みながわ氏と同類の人が半径３ｍにいただけかも知れませんよ？
＞＞その人をモデルとしてた場合はどうなるんでしょう。
＞これはすこし無理があるかと思います。高慢と偏見の最終話ですが後半は『実はオブジェクト指向ってしっくりこないんです！。』のパロディとなっています。
これについては、前述でもあるとおり、「事件を知らない読者はそこまでは見てないかと。」です。
最後の最後で事件を知っている人は確実に連想させる内容ですが、知らない人にはパロディであることはわかりません。
読者へのリップサービス♪って言われても、悪意がないかと言われるとちょっと否定はできないですね。

今までのことを総合すると、おおふじさんの批判すること自体は問題ないと思います。
ですが、批判しなければならないところがちょっとずれたかなと。
出だしの「特定の人物を不当に貶める」は問題ないですが、
『高慢と偏見（終）　エピローグの最後の締めの文章で、"そのささやかな幸せがいつまでも続くといいね。　高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。"
と書かれています。この言葉はどう見ても、みながわさんに向けられた言葉で、みながわさんは他人の話を聞かないと断定しています。』
ここから主旨がずれてはじめたと思います。
これ以降は「みながわ氏への評価は正当か？」→「作品内のオブジェクト指向についての技術論」→「結論」となっています。

こんなまわりくどいことをせずに、
＞高慢と偏見の最終話ですが後半は『実はオブジェクト指向ってしっくりこないんです！。』のパロディとなっています。
ってところだけを抜き出し、「これでは三浦マネージャ＝みながわ氏が成立し、特定の人物を貶める内容になっているではないか！」って言えば、私も含め向こうのコメント欄の人たちも「ああ、確かに」で納得すると思います。であとは、名誉毀損とは等のリンクを張ればＯＫかと。
ただ、何度も言いますが「事件を知らない人にはパロディであることはわかりえない」と思います。

一人一人のみながわ氏の評価を変えるという膨大なリソースを使用する作業すらする必要もないですよ（笑）。
どうでしょう、おおふじさん。
おおふじより
2012-11-14 23:31:14
CMPさん
ありがとうございます。
確かに、みながわさんの擁護と名誉毀損の話がごっちゃになってますね。
だいぶ炎上してしまったので速めに修正します。
通りすがりより
2012-11-15 10:41:27
通りすがりなので、私からのコメントはこれで終了です。

> 無いと業務アプリが作れない（RDBのよう
> に、それを使うと劇的にコストが下がるとか信頼性が高まるとか）ということでもないでしょう

私は1,000人月を超える中～大規模プロジェクトで、かつJavaかC++を使っているプロジェクトに参加したことは3,4回しかなく、また業界の動向を常に探っているわけではありませんが、その狭い視野で言えば、劇的にコストは下がり、信頼性は高まります。

大規模プロジェクトになると、製造工程では数社入りみだれ100～300人ほどが同時にコーディングしてたりしますが、それぞれなんの「基盤」もなくコーディングした方が低コストで高信頼性のものができると思いますか？
普通に考えれば、まず「基盤」となる部分を、既に製品化されているなんちゃらFramewrokなり、そのプロジェクト独自のものなりを先行して開発し、それをみんなで使う方が低コストで高信頼性のものができると思います。

一方、中～小規模なプロジェクトでは、それはもう空気のようにオブジェクト指向が使われているというのが私の感触で、「オブジェクト指向をうまく適用できた具体例を聞いた事がありません」と言われると、それはあなたが知らないだけなんじゃ無いの？と思う次第です。

またTIOBEによれば、JavaやC++は非常に人気が高いです。それらの人達の大半がプロジェクトでオブジェクト指向をうまく適用できず、炎上したりプロジェクトが失敗したりしているとは思えません。もしそうであるなら、もっとシェアが低くなるはずです。
CMPより
2012-11-16 00:04:00
今回の騒動は、フィクションといえど一番ぼかさなきゃいけないところがぼかしきれてないのが原因かなと思います。（読んでた当時はそんなこと露とも思わなかったんですけどね）

＞　「あなたの出身校はどこだ？ 私はT大学大学院卒だ」
ここはパロディの肝となる部分ですが、これはダイレクトすぎたと思います。
名誉毀損の判例などを見た後では、ほぼ黒に近いグレーである印象に変わりました。
ここが「あなたの会社はどこだ？私の会社は東証一部上場企業だ」だったら、「どこからどう見てもフィクションだろが！」と言い切れたんですけどねえ。
（心の底では、まだぎりぎりセーフ・・・かな？ぎりぎりセーフ・・・だよね？と思ってます）

だから、私の結論としては「名誉毀損のことを考慮するなら、もうちょっと配慮が必要だった」とさせていただきます。
とはいっても、俺って読者の一人でしかないんですけどね（大汗）。

とはいえ、おおふじさんにはいい迷惑だったかも知れませんが、いろいろと議論（会話？対話？）ができて楽しかったです。
あとは、おおふじさんがどう終息させるのかを野次馬根性剥き出しで見守りたいと思います。
お疲れ様でした。
おおふじより
2012-11-16 00:43:50
＞＞　「あなたの出身校はどこだ？ 私はT大学大学院卒だ」
＞ここはパロディの肝となる部分ですが、これはダイレクトすぎたと思います。

このあたりをまとめようとしているのですが・・・・炎上の方の相手もあり・・・まとめきれないですね。

＞とはいえ、おおふじさんにはいい迷惑だったかも知れませんが、いろいろと議論（会話？対話？）ができて楽しかったです。
＞あとは、おおふじさんがどう終息させるのかを野次馬根性剥き出しで見守りたいと思います。

いやー私もここまで炎上するとは思っていませんでした。
今日はかなり折れたつもりですが、多分止まらないです。
このページのアクセス数ですが、日増しに増えています。

まぁ、楽しんでもらえれば幸いです。

騒動が終わったらメールで連絡致します。
（頂いたメールアドレスはOKですよね？）
CMPより
2012-11-16 14:52:17
＞（頂いたメールアドレスはOKですよね？）
ゲーム用のアカウントなので普段のアカウントよりチェックしてるはずです！（ｷﾘｯ

どんな形であれ、みながわ氏と同じ終息にしなければよいかと。
あとは「シンプル　イズ　ベスト」。これって真理かもね～。
ohfujiより
2012-11-18 09:14:26
CMPさん

少々、時間がかかってしまいましたが、本文を修正しました。


通りすがりさん

コメントありがとうございます。先にコメントしましたとおり、本題とは関係がなくかつ論争となりそうな部分については削除しました。
通りすがりより
2012-11-19 14:17:01
> 先にコメントしましたとおり、本題とは関係がなくかつ論争となりそうな部分については削除しました。

でしたら、私からの「通りすがり」名義の以下の発言も、全て削除をお願いします。
2012-11-14 15:29:58
2012-11-14 15:34:23
2012-11-15 10:41:27
通りすがりより
2012-11-20 17:20:31
一旦コメント削除をお願いしておいてアレなんですが、邪魔にならなければ残しておいて下さい。

蛇足。
ohfujiさんは『デザインパターンとともに学ぶオブジェクト指向のこころ』という書籍をご存じでしょうか。
サイトを拝見する限り、JavaもC++も使っているご様子。なのに、ビジネスロジックレイヤーではOOは使い物にならないと思っている。
『デザインパターンとともに学ぶオブジェクト指向のこころ』が変えてくれるかもしれませんよ。

本当にこれで最後です。
では、またどこかで。
おおふじより
2012-11-20 22:43:51
通りすがりさん

＞一旦コメント削除をお願いしておいてアレなんですが、邪魔にならなければ残しておいて下さい。

最初の削除依頼を受けた時に『消す必要はないのに』と思っていたので良かったです。という事で残しておきます。

さて、
＞なのに、ビジネスロジックレイヤーではOOは使い物にならないと思っている。

この話は実は深いです。私がなぜそう思うのか、概要だけ説明します。

オブジェクト指向は当初、Simulaでシミュレーション用に導入され、その後Smalltalkで導入されて、ウインドウシステムの実装で成功しました。
私自信の例ですが、自作のプログラミング言語（ADP）の処理系をC++/STLで作成していますが、バリバリオブジェクト指向（ポリモーフィズム）を使っています。のでオブジェクト指向の一連の技術は否定しません。

さて、このような成功例ですが、いずれも『人工物』だったり『自然科学』のような法則性を持ったもの（プログラミング言語の処理系もある意味、法則性を持ったものです）だったりします。

この『法則性を持ったもの』というのはオブジェクト指向技術の適用の可否の判断基準になるのでは？という考えを最近持つようになりました。

ビジネスロジックというのは、法則性がなく恣意的な面が多々有ります。
例え話をしますと『コンプガチャ』の仕組の導入に際して、従来のシステムからポリモーフィズムで対応出来たでしょうか？まぁ出来たかもしれませんが、元々そのような発想でプログラミングをしておかない限り、かなり怪しいですよね。
つまり、人間の経済活動というのは、株価の推移でみても分かります通り、事前に予測不可能なわけです。そういうものに対してプログラムを行う場合、オブジェクト指向は『実は足枷になるのではないのか？』というのが最近の私の考えです。

以上、あくまでも一個人の考えですので、聞き捨てて頂いてかまいません。

ちなみに、私自身プログラミング言語を開発していますが、このあたりの困難（予測不可能性から来る複雑性）に対してどのような言語なら良いかということを結構真面目に考えています。その答えとしてロジックプログラムを候補にあげています。


＞『デザインパターンとともに学ぶオブジェクト指向のこころ』
は読んでいません。私のプログラミング言語（ADP）もオブジェクト指向をサポートしようとしています。ので参考に読んでみようかと思います（この騒動が終わったら・・・・）。
おおふじより
2012-12-24 10:25:41
みながわさん
ばたばたしていましたので、亀レスですみません。

ただ、私の方（最近はあまり書き込んでいませんが）の書き込みに対するレスもそうですが、レベルの低い人達が集まるようになった気がします。
前はもっと技術的に意識の高い人達が集まったかと思うのですがね。

そういえば、ドさんの書き込みは間違いのようですので、しばらくしたら削除します。
επιστημηより
2012-12-28 01:00:19
みながわさん、僕にどんな印象を抱かれようがかまわんですが、
推測の域を脱していない事項を拡散されるのは迷惑なんですけど。
επιστημηより
2012-12-28 22:06:27
↑そんなわけで おおふじさん、当該の投稿[みながわけんじ/2012-12-19 20:10:38]を消去していただきたく。
お手数をおかけしますが、よろしくご配慮願います。
ohfujiより
2012-12-28 22:32:21
επιστημηさん

はじめまして、ご依頼の件ですが、みんがわさんにメールをしてみて、削除するかどうか検討します（とりあえず暫定的に非表示にします）。

επιστημηさんには関係のない話かと思いますが、επιστημηさんが例の書き込みを迷惑とお感じになられた以上に、みながわさんに対する偏見による書き込みが後を絶たないのも事実です。
この点については皆様にも今一度考えてもらえればと思います。

私はこの記事で、『相手を貶めるのではなく技術論で話ましょう』という意見でやっています。
議論を進めることと自分の考えを押し通すことの違いを皆様に考えてもらえればという思いでこの記事を書いていますので、επιστημηさんのお気持ちはなるべく尊重したいと思います。

話は変わりますが、『public static』の件を記事にしようかと思っていたところ、επιστημηさんのブログのコード例で public static が使われていました。私はC＋＋でプログラムを組む場時は、あまりpublic staticは使わないのですが（普通に関数にする）、案外使うことがあるのですね。
επιστημηより
2012-12-29 01:14:30
> 私はC＋＋でプログラムを組む場時は、あまりpublic staticは使わないのですが（普通に関数にする）、案外使うことがあるのですね。

僕もフツーに関数です。Java/C#ではクラス/インスタンスに属さない関数を定義できないためにstatic-methodで代用するので。
※ たとえば多くの数学関数は C#(.Net)だと Math.Sin(), Math.Log() のように、class Math の public static で提供されています。
ohfujiより
2012-12-29 08:11:11
ご返信ありがとうございます。

>> 私はC＋＋でプログラムを組む場時は、あまりpublic staticは使わないのですが（普通に関数にする）、案外使うことがあるのですね。
＞僕もフツーに関数です。Java/C#ではクラス/インスタンスに属さない関数を定義できないためにstatic-methodで代用するので。

http://blogs.wankuma.com/episteme/archive/2012/12/28/310396.aspx

の記事のコードはC＋＋のようですが、そのrefereeクラスのメンバ関数が public static になっていました。

＞※ たとえば多くの数学関数は C#(.Net)だと Math.Sin(), Math.Log() のように、class Math の public static で提供されています。

このあたりの話も記事にしようかと思っていたのですが（時間がなくてできないですが）、SinやLog、Absのようなメソッドを使うに際して『粗結合を阻害されるかも』とは思わないもので、粗結合の記事(http://el.jibun.atmarkit.co.jp/genmaicha/2012/12/2-7b17.html)の意図が分かりません。
もっとももう終わった話かとも思いますが。

επιστημηより
2012-12-29 09:48:22
> SinやLog、Absのようなメソッドを使うに際して『粗結合を阻害されるかも』とは思わないもので...

「ライブラリだから」かと。自分が作ったクラスのpublic static呼び放題だと話が変わりそう。
ライブラリなら依存関係がDAGになってることが確実だけどオノレの作ったものだとそうとは限らんので。
ohfujiより
2012-12-29 13:00:51
＞「ライブラリだから」かと。自分が作ったクラスのpublic static呼び放題だと話が変わりそう。

例えば、以下にありますεπιστημηさんご自身が作成されたrefereeクラス

http://blogs.wankuma.com/episteme/archive/2012/12/28/310396.aspx

は、public static なメンバ関数が3つ程ありますが、

＞ライブラリなら依存関係がDAGになってることが確実だけどオノレの作ったものだとそうとは限らんので。

つまり、このrefereeクラスのメンバ関数は疎結合とは限らないということでしょうか？


誤解のないように補足しますと、私は揚げ足をとる意図はございません。

http://blogs.wankuma.com/episteme/archive/2012/12/28/310396.aspx

のコードですが、C++らしいと思います。細かいところでコメントが無いわけではないですが、実際に仕事で見るC++のコードです（最新仕様は置いて置いて）。

例えば一緒に仕事をしているエンジニアが

「refereeクラスのメンバ関数が public staticだから疎結合になっていない！」

とか言い出しても私は相手にしないでしょうし、逆にそのエンジニアの技術力を疑います。
確かに私は、C++ではpublic staticなメンバ関数はあまり使用しません。が、だからと言ってpublic staticがダメだとも思いません。メンバ変数にアクセスしなかったりrefereeクラスのようにメンバ変数は無いが関連する手続きを集めて１つのクラスを作りpublic staticなメンバ関数とすること自体は自然なことだと思います。つまりよくやることだと思います。

理想と現実というわけではないですが、実際のプログラミングはなかなか教科書どおりにはいかないでしょう。
プログラムを綺麗に作ることは大事ではありますが、それよりも大事なのは要求仕様を満たす完全なプログラムを作成することで、品質という大きな話の中の保守性の中で、可読性、結合の話が出てくるかと思いますが、それは、『スコープ拡大の元凶であるpublic staticは、可読性の向上以外に使用用途はほぼないといっていいと思います』とかいう単純な話ではないのではと思います。

私もそうですし、επιστημηさんや、みながわさん、さらに粗結合の記事(http://el.jibun.atmarkit.co.jp/genmaicha/2012/12/2-7b17.html)の作者の玄米茶さんもそうだと思いますが、お客の為や自社の為等、現実に動くプログラムを書いたり保守したりしているかと思います。
そのような経験からくる説明があれば私も理解できるかと思います。
例えば、『public staticなメソッドを使って、コールツリーがDAGでないと、このような不都合なことが起こる』ということを具体的なコードを示して頂いて説明して頂くと私にもわかるかと思うのですが。
επιστημηより
2012-12-29 15:56:57
> 例えば、『public staticなメソッドを使って、コールツリーがDAGでないと、このような不都合なことが起こる』
> ということを具体的なコードを示して頂いて説明して頂くと私にもわかるかと思うのですが。

ModuleA が fA1(), fA2()
ModuleB が fB1(), fB2() を持ってるとしますか。
さらに
ModuleA.fA1() が ModuleB.fB2() を呼び、
ModuleB.fB1() が ModuleA.fA2() を呼んでると。
public static メソッドであれば十分あり得ることですわね。

コール・ツリー（=関数間の依存関係)は
ModuleA.fA1() --> ModuleB.fB2()
ModuleB.fB1() --> ModuleA.fA2()
実に単純なDAGです。

ところが、モジュール間の依存関係は
ModuleA ModuleB
相互依存となり、分離できません。

fA1(),fA2(),fB1(),fB2() がC++みたいにフツーの関数なら問題ないのに
ModuleA,ModuleBでまとめたことで(モジュール間の)相互依存が起こりうるってことで。

※ もちろんちゃんと設計すればDAGを保てるでしょうけどね。
ohfujiより
2012-12-30 01:04:18
επιστημηさん
ご解説ありがとうございます。

私からの返信の前に、１点確認させて下さい。

このrefereeクラスのpublic staticなメンバ関数は疎結合とは限らないということでしょうか？

こだわって申し訳ないですが、この質問に対して、επιστημηさんのご見解をお聞かせ頂ければと思います。
επιστημηより
2012-12-30 08:00:52
結合度を「修正/変更が他に及ぼす影響」の意味であれば、
そしてrefereeの"現在の"実装について問われているのならば、「結合度は低い」と答えます。
referee自身の変更は他に影響しませんから。

refereeはcontributorに依存しているので、
contributor(privateメンバ"answer")の変更がrefereeに悪さをしますね。
contributorが持つanswerをreferee以外に見せたくなかったため、friendにしちゃったので。
ohfujiより
2012-12-31 00:07:02
επιστημηさん

年末でばたばたしていますので亀レスですみません。

＞結合度を「修正/変更が他に及ぼす影響」の意味であれば、
＞そしてrefereeの"現在の"実装について問われているのならば、「結合度は低い」と答えます。
＞referee自身の変更は他に影響しませんから。

定義や実装内容によるが、pubic static なメソッドでも「結合度は低い」ということもあると言う事ですね。

ところで、なぜ、結合度を

＞結合度を「修正/変更が他に及ぼす影響」の意味であれば、

このように定義されたのでしょうか？
もともとは、

＞> SinやLog、Absのようなメソッドを使うに際して『粗結合を阻害されるかも』とは思わないもので...
＞「ライブラリだから」かと。自分が作ったクラスのpublic static呼び放題だと話が変わりそう。
＞ライブラリなら依存関係がDAGになってることが確実だけどオノレの作ったものだとそうとは限らんので。

という話だったかと思います。

ちなみにですが、依存関係で見た場合、refereeクラスは粗結合なのでしょうか？


ModuleA, ModuleBの話は、public staticだから問題というわけではなく、ご指摘のとおり設計の問題でしょう。

＞fA1(),fA2(),fB1(),fB2() がC++みたいにフツーの関数なら問題ないのに
＞ModuleA,ModuleBでまとめたことで(モジュール間の)相互依存が起こりうるってことで。

ModuleA、ModuleBを統合してModuleCとすれば、フツーの関数と同様に問題が解消されるでしょう。
επιστημηより
2012-12-31 00:55:13
＞ところで、なぜ、結合度を
＞＞結合度を「修正/変更が他に及ぼす影響」の意味であれば、
＞このように定義されたのでしょうか？

いや、結合度ってもともとそんな意味じゃなかったかしら。
依存されていると分離・修正/変更が困難に(=結合度が強く)なりますし。
# とはいえ依存関係なしにはモノが作れないので、できる限り薄く依存する(緩く結合する)ことが望まれるし、
# 循環依存(=ガチガチに結合)が嫌われるんだと考えます。

＞依存関係で見た場合、refereeクラスは粗結合なのでしょうか？

contributorなしにはrefereeが実装できないのでcontibutor-referee間の結合は強いかと。

＞ModuleA、ModuleBを統合してModuleCとすれば、フツーの関数と同様に問題が解消されるでしょう。

ですね。しかしながら MuduleA,ModuleBに分けたのは設計の意図によるものかも知れません。
そのとき安易に統合すると実装が意図に反してしまう。思ったとおりに作っていないことになります。
# さもなくば当初の"思い"に欠陥があったか。

- Hit/Blowの判定はrefereeの責務である
- 正解はcontributorが持っている/refereeのみが正解を知ることができる
という設計の意図により、refereeがcontributorに依存しちゃいました。

- Hit/Blowの判定はcontributorの責務である
もしくは
- contributorはrefereeeを兼ねる(統合する)
とすれば依存を解消することができますが、当初の設計者の意図からは外れます。

--- 余談 ---
Java/C#はどのクラスにも属さないメソッドが作れないため、
当たり障りのないクラス(たとえばMathあるいはModuleC)をでっちあげてそいつに押し込まざるを得ない。
「いかなるクラスにも属さない」という"思い"を表現できません。
僕にはそこが(C++と比べて)不自由に感じます。
επιστημηより
2012-12-31 01:08:08
お試しにHit/Blow判定をcontributorの責務とすることで結合度を小さくしてみた↓
https://skydrive.live.com/embed?cid=07C558F8E11E708F&resid=7C558F8E11E708F%21837&authkey=AGo4DfTrB09_MT8
ohfujiより
2012-12-31 16:17:42
相変わらず亀レスですみません。

コメントはあるのですが、私のコードを出していないのは、いかがなものかと思いますので、私もHitAndBlowを書いてみました。
http://www.ohfuji.name/?p=2073
ただの焼き直しだと芸がないのでちょっと工夫を入れています。

今年はこれにて終了ということで、詳しいコメントについては来年にでもさせていただければと思います。
とりあえず、良いお年を。

おっと、VS2008で動作確認しています。
ohfujiより
2013-01-03 16:50:32
あけまして、おめでとうございます。

さて、越年してしまいましたが、コメントします。


こだわってすみませんが、話の流れを明確にしたいので、細かい点についてコメントをします。

＞＞ところで、なぜ、結合度を
＞＞＞結合度を「修正/変更が他に及ぼす影響」の意味であれば、
＞＞このように定義されたのでしょうか？
＞
＞いや、結合度ってもともとそんな意味じゃなかったかしら。

元のブログ記事(http://el.jibun.atmarkit.co.jp/genmaicha/2012/12/2-7b17.html)は結合度とスコープが関係しているという話でした。つまり結合度をスコープの広さで測るという定義と読み替えられるでしょう。public staticはスコープを広げるので結合度が高くなるという話だったかと思います。その定義に従うとrefereeクラス（public staticなメンバ関数がある）は結合度が高くなりますが、しかし「修正/変更が他に及ぼす影響」の定義を用いると結合度が低いということになるという話です。聞きたいことは定義によって結合度が変わるということでしょうか？

さらに、

＞＞依存関係で見た場合、refereeクラスは粗結合なのでしょうか？

＞contributorなしにはrefereeが実装できないのでcontibutor-referee間の結合は強いかと。

contibutor-referee間の結合という話が出てきましたが、refereeクラスは見方によって結合が高くなったり低くなったりするというこでしょうか？


何が言いたいのか、繰り返しますと、
『public staticなメソッドを使って、コールツリーがDAGでないと、結合が疎でなくなり、このような不都合なことが起こる。ということを具体的なコードを示して頂いて説明して頂ければ』
ということと、
『refereeクラスは疎結合なのかそうでないのか？』
ということです。


結合度のもともとの教科書的な定義はよく知られています。残念ながら日本語のよく見かける結合度の説明（例えば、http://members3.jcom.home.ne.jp/daruma_kyo/aboutooa/module_cohesion_coupling.html）ですが、構造化プログラミングの時代の定義で例えば、

objectA.method(objectB)

の結合度はどうなるのか？
という質問には、充分に答えられないようです。
この質問に答えるには、例えば英語版のWikipediaの説明（http://en.wikipedia.org/wiki/Coupling_(computer_programming)）
のSoutionsの項目をみますと、

『One approach to decreasing coupling is functional design, which seeks to limit the responsibilities of modules along functionality, coupling increases between two classes A and B if:
・A has an attribute that refers to (is of type) B.
・A calls on services of an object B.
・A has a method that references B (via return type or parameter).
・A is a subclass of (or implements) class B.』

とありますが、objectA.method(objectB) のような呼び出しは、
『 ・A has a method that references B (via return type or parameter).』
に該当し結合度が高くなるようですね（もっとも 『This article needs additional citations for verification』というラベルが付いていますので真偽については怪しいですが、私はこの説明は納得できます）。

つまり、クラスを使うと結合度が高くなるということでしょう。
で、話としては『あまり不用意にクラスを作るとこんがらがってしまう（結合度が高くなる）ので注意しましょうね。』ということなのだと理解しています。
このような観点でみると実は、public staticそれ自体は結合度を高くするようなものではない（もちろんですが、他の要因で結合度が高くなる場合がある）ということも言えるでしょう。

長くなりますので一旦ここで区切ります。
επιστημηより
2013-01-03 21:07:11
＞『public staticなメソッドを使って、コールツリーがDAGでないと、結合が疎でなくなり、このような不都合なことが起こる。ということを具体的なコードを示して頂いて説明して頂ければ』

具体的なコードが出せずに申し訳ないけども、

「(コールツリーがDAGであり)メソッドが疎結合であっても
public staticなメソッドはどのクラスにも置くことができるため、
クラス(メソッド群)としては結合度を上げてしまう危険性を孕む」
と考えます。

＞『refereeクラスは疎結合なのかそうでないのか？』

refereeeはcontributorのprivateメンバを参照するため、
refereeはcontributorを引き連れてしまう。なので疎結合とは言い難い、かな。
とはいえ、意図した密結合と言えなくもない。contributorがfriend class refereee してるから、
その時点で切り離せなくなってるのは百も承知です。設計の意図を素直に/忠実に実現したらそうなっちゃった。
ohfujiより
2013-01-04 21:34:00
まず、先のご依頼の件についてですが、検討しましたが、今回はみながわさんに許可を取ることができましたので該当部分の消去とします（みながわさんのコメントの本文と該当する私の文章）。みながわさんご理解の程ありがとうございます。

以下、コメントに対する、返信です。

＞public staticなメソッドはどのクラスにも置くことができるため、

この性質は見方を変えれば、
　どのクラスにも置くことができる　→　クラスとpublic staticなメソッドは依存度が低い　→ 結合度が低い
と考えられないでしょうか？

前回私が出したもともとの結合性の定義（http://members3.jcom.home.ne.jp/daruma_kyo/aboutooa/module_cohesion_coupling.html）
によりますと、もっとも結合度が低い結合の種類は『データ結合』とあります。
データ結合というとすなわちグローバル変数にアクセスしない関数のことで、該当するものの例は、
LogやAbsや、
public static hb judge(const number& actual, const number& guess);
もデータ結合になっているでしょう。
hbやnumberがクラスになっていますが、ADT（Abstract Data Type 抽象データ型)として基本型と同様に使っているのでこれらは結合度を高める要因とはならないとみてよいかとおもいます。

例えば、επιστημηさんのHitAndBlowのサンプルコードを見て判定ロジックをほしいと思った人は、referee::judge(const number& actual, const number& guess);のコードを再利用することが出来るでしょう。同様のことを私が作成したコードで行おうとすれば、refereeクラスを再利用することになりますが、単純にjudgeメンバ関数を使えばよいわけではない（事前にprepareAnswerを呼び出す必要がある）のでちょっと手間です。
もっともこの点のみで私のコードが劣っているというつもりもありません。この点はまたコメントします。

つまり、グローバル変数やクラス変数にアクセスしない、public staticなメソッドは、どのクラスにも置くことが出来る為、結合度が低くなる。というのが私の見解になります。
επιστημηより
2013-01-04 23:40:42
んー...たぶん僕も同じ考えなんだと思う。

ただし。
「public staticなメソッドは、どのクラスにも置くことが出来る」は
「どのクラスに置いても結合度が低い」を意味しない。が僕の見解。

referee::judgeはpublic staticだからどのクラスにも置くことができる。
だからsolverに置いてもよかった。
ところがそうするとjudge"だけ"を使いたくても、
欲しくもないsolverのメソッド/メンバを丸ごと引き連れてくることになる。
ohfujiより
2013-01-06 10:33:48
>ところがそうするとjudge"だけ"を使いたくても、

solver::judge

という呼び出しで、judgeは、solverの非静的メンバ変数・メソッドにはアクセスしないでしょう。ですから、

> 欲しくもないsolverのメソッド/メンバを丸ごと引き連れてくることになる。

ということにはならないのでは？
επιστημηより
2013-01-06 13:44:19
ああ、「呼ばない/使わないから関係ない」ということでは仰るとおり。

使っていない他のメソッドがまた他のアチコチを読んでて、
solver::judgeを使いたくてライブラリを取り込んだ途端、
(芋づる式に依存して)実行サイズがどえらく膨れ上がる。なんてことが起こリ得る。

使いもせんものを引き連れて膨れ上がるのも余計な結合のせいかと。
その意味では僕は結合度を拡大解釈してるかもです。
ohfujiより
2013-01-08 22:02:25
>(芋づる式に依存して)実行サイズがどえらく膨れ上がる。なんてことが起こリ得る。

これは言語やコンパイラ、作成するファイル（実行ファイル・ライブラリ）によって異なるのでは？

例えば、Visual C++ 2008（おそらくその前から）、コンパイルオプション(/Gy)で関数レベルのリンクの有効を行い、リンカオプション（/OPT)で最適化を行えば、不要なコードは削除されます。

Javaだとリンクという概念がないのでそのまま引っ張られるでしょう。

>使いもせんものを引き連れて膨れ上がるのも余計な結合のせいかと。

これをpublic staticのせいにするのは如何がものかと・・・solverを使えば、巨大なライブラリを引き連れることになります。
巨大なコードが問題ならsolverをダイエットする他ないかと思いますが？
（solverクラスは使う為に作られたのでしょうから）。

＞その意味では僕は結合度を拡大解釈してるかもです。

話は少しかわるかもしれませんが、
そもそも私は結合度について意識したことがないです。
もともとの定義については、
・グローバル変数はなるべく使わない
と言い換えが可能でしょう。
結合度云々よりもグローバル変数は控えましょうの方が具体的でルールとして守りやすいです。

で、なぜ今になって結合度が問題になってきたかと言いますとやっぱり主な原因はクラスにあるかと思います。

例えば、java で、あるサイトからあるURLで示されたHTMLを取得しようとすると、
・URLクラス
・URLConnectionクラス
・InputStreamクラス
・BufferedReaderクラス
等を使うことになります。素朴な疑問として『なんでこんなにクラスを使う必要があるのか？』と思うでしょう。
特にURLクラスというのは一見するとオブジェクト指向ぽいですが、ほとんどの場合、手間を増やすことにしかならないのではと私は思います。同じように思ったのかどうか不明ですが、C#の場合はURLクラスを使わなくてもURLの指定ができるようになっています。

何れにしても、HTMLを取得したい場合、単純に
string htmltext = gethtml("http://www.example.com");
のようにURLを指定して文字列としてHTMLが読み込めれば便利でしょう。
私は実際にこういうライブラリを作成しています。

さて、URLを指定してHTMLを取得したい場合、クラスの方と一つの関数の方、どちらの方が抽象度が高いでしょうか？
私は結合度が取りざたされるようになったのは、このようにクラスを使うことでやりたいことが不明瞭になり、かえって抽象度が下がるようなケースが出て来たから、というのが背景にあるのではと思っています。
επιστημηより
2013-01-09 05:00:00
単品でひとつひとつ注文するよりセット・メニュー頼んだ方が楽ではあるけど、
だからって単品で注文できなくなるとセット・メニューでは対応できない客がいる。

セット・メニューはあらかじめ用意された決め打ち(=具象)の単品の集合ですよね。これって抽象度が高いんですか?
ohfujiより
2013-01-09 07:56:29
単品・セットメニューの考え方は否定しませんが、

＞セット・メニューはあらかじめ用意された決め打ち(=具象)の単品の集合ですよね。これって抽象度が高いんですか?

設計書を書いてみたらわかるかと思います。
ユーザがやりたいことは、あるURLからHTMLを取得することであり、URLの抽象化やストリームの抽象化ではないでしょう。
επιστημηより
2013-01-09 08:16:41
対してライブラリがなんもかんもお仕着せガチガチのセットメニュー群だったらユーザは困っちゃう。
欲しいものを好きに自由に組み合わせてセットメニューに仕立てられるよう、
ライブラリがいろんな手駒を用意してくれんと。そこで抽象化されてることが自由度を上げてくれますな。

視点あるいは目的の相違じゃないかしら。
ohfujiより
2013-01-09 23:06:37
＞対してライブラリがなんもかんもお仕着せガチガチのセットメニュー群だったらユーザは困っちゃう。

一般論としては一理あるのでしょうが、今はgethml関数の話をしています。
ご存じないようですので補足します。C#(.Net)では、WebClientというそのものズバリのクラスがあります。
例えば、C#では以下のように記述ができます。

WebClient wc = new WebClient();
wc.Encoding = Encoding.UTF8;
string html = wc.DownloadString("http://www.yahoo.co.jp/");

gethtml関数程お手軽ではないですが、WebClientクラスは、エンコード、proxyやヘッダの指定等ができ、適度な抽象化がされているかと思います。。

このように書きますとjava批判と受け取られるかと思いますので、補足しますと、この例をもってjavaは使いにくいとか言うつもりはありません。

が、やはりC#(.Net)は後発な分、このような細やかなところで使い勝手を考えたライブラリ設計を行っているので参考にすべきところはとりいれたいものです。
使う側もこのようにライブラリに対して審美眼のようなものが必要なのかもしれません。

ちなみに、明日から出張ですので、しばらく返事がないかもしれません。
mbspより
2013-01-10 00:01:51
WebClientにはDownloadString(String)とDownloadString(Uri)が用意されています。
Uri(String)のコンストラクタがあることからも、内部的には結局Uriオブジェクトが使われている可能性が高いでしょう。
なお、Uri(String)はUriFormatExceptionを投げますが、DownloadStringはどちらもWebExceptionを投げます。
こうみていくと、どちらが望ましい実装なのかということが一概に言えなくなって来ると思います。
ohfujiより
2013-01-10 00:11:06
>こうみていくと、どちらが望ましい実装なのかということが一概に言えなくなって来ると思います。

私は、WebClientクラスが適度に抽象度が高くて使い勝手がよいといっています。
私は.NETはあまり使いませんが、だれもWebClientを使わないのならおしゃるとおりです。がそんなことはないでしょう。
また、Uriのチェックが必要ならUriクラスを使うことができます。という意味で、WebClientクラスは良くできているかと思います（使う使わないの自由がある）。

そういえば、mbspさんは、
http://el.jibun.atmarkit.co.jp/pressenter/2011/02/post-6b95.html
のmbspさんでしょうか？
であれば、私からのコメントはこれにて最後とさせていただきます。

ミシーより
2013-01-10 02:38:47
確かに、Javaは、
「こんなに汎用性の高いものを用意しましたよ。
自由に使ってモジュールを作ってください。」
対して、.NETは、
「きっとこういう処理必要なんですよね。
便利なもの沢山作ったから使ってください。」
というような若干の雰囲気の差がなくはないです。

WebClientクラスは.NET Framework 2.0から追加されたクラスです。

それ以前はこのようにしていました。
http://msdn.microsoft.com/ja-jp/library/456dfw4f(v=vs.80).aspx?cs-save-lang=1&cs-lang=csharp#code-snippet-15

WebClientのDownloadStringも、内部的には
Uriクラス、WebRequestクラス、WebResponseクラス、Streamクラスなどに依存しています。

要するに、より便利なクラスが必要となったとき、
だれがいつクラスを作るかの違いだと思います。

ライブラリは(プログラムを組む)ユーザーがどこまでの
ものを必要としているのか把握できませんから、
どのくらい使われるかわからないクラス群を過度に沢山作ってしまえば
まさにεπιστημηさんのおっしゃる通り、
実行サイズが増えてしまします。要はそれとのトレードオフです。
（また、ライブラリを開発するコストもありますが。）

Httpでダウンロードするのは文字列とは限らないわけで、
実際、WebClientにはたとえばSystem.Drawing.Imageを返すメソッドなどはありません。

(また、
・ダウンロードという技術的処理をモデル化た場合、どういうクラスがよいか
・コードを組むことを中心に考えてどういうクラスがよいか
というアプローチの違いでもあるかもしれません。)

必要なものがないなら作ればいいので、
ライブラリをつくってしまえ、というアプローチは正しいと思います。
ただ、ライブラリとして使われるには、
結局は疎結合等の概念が重要になってはきますが。
επιστημηより
2013-01-10 05:03:56
> 一般論としては一理あるのでしょうが、今はgethml関数の話をしています。

あー...僕は一般論を語りたかったので、議論はここまでですねー。
いろいろと考えさせられ、愉しうございました。ありがとうございます。
Error401より
2013-01-10 17:02:44
抽象度が高いというと、例えば
html = open('http://www.example.com')
でHTMLを取得できるopen()関数のようなものを想像します。
open()はhttp://もhttps://もftp://も取得できます。違った文脈では、ローカルのファイルも読めますし、物理デバイスだって読めます。
その意味で言えば、gethtml()は具象度が高いと言えます。

さてこのopen()は、URLスキームが指定されている場合はURIクラス群を使います。URIクラス群にはHTMLクラスやFTPクラス、LDAPクラスなどが存在します。
これが何を意味しているかといえば、ユーザが新しいMyURIクラスを作れば、open()を拡張できるということです。
HTTPでHTMLを取得するのに複数のクラスを使う設計になっているのは、そういうことだからだと思います。

逆に、具象度の高い関数群gethtml(), getftp(), getldap()等しか提供されていなければ、ユーザが容易に拡張することが困難になります。もちろん、gethtml(), getftp(), getldap()のような具象度の高い関数群が、言語のビルトインクラスやライブラリに不要だと言っているわけではありません。通常は、URIクラスなどの凝集度が高く結合度の低いクラス群と、それらを使用する高機能なクラス群が並立してデフォルトで提供される言語の方が多いと思います。
ohfujiより
2013-02-11 14:02:50
だいぶ間があきましたが、年度末で忙しいのでたいした返信はできませんが、とりあえずということで。

＞あー...僕は一般論を語りたかったので、議論はここまでですねー。

ということですので、とりあえずこれで終了ということで了解しました。

もっとも、staticメソッドや関数の効用について誤解されているかたがいらっしゃるので、時間ができましたら記事にしようかと思っています。

後、この間に書籍を読んでみました。目的は英語の勉強がてらの情報収集ですが関連した話がありましたので指摘しときます。
CODE COMPLETEの第2版（英語版）には、結合について先のWikipediaの英語版の内容と同じ説明がありましたね。
つまりクラスを受け渡しすると結合度が下がると書いてあります。

また、http://el.jibun.atmarkit.co.jp/genmaicha/2012/12/2-7b17.html でみながわさんが指摘されている、The Art of Readable Code（英語版）には、public static メソッドの効用として『スコープが狭まる』とはっきりと書いていますね（読んでみました）。
理由についても、みながわさんがおしゃることで合っていました。
繰り返しますと、非静的メンバ変数は、メソッド間で共有する変数なので、それらの間では一種のグローバル変数のように振る舞います。つまり非静的メンバ変数は、ローカル変数と比べてスコープが広いということです。
従いまして、非静的メンバ変数にアクセスできないpublic staticメソッドは、ローカル変数しかアクセスしないのであれば、スコープを狭める効果があるというこで、元の記事（http://el.jibun.atmarkit.co.jp/genmaicha/2012/12/2-7b17.html）とは異なる解釈となっていますね。


以下、細かいところですが、一応指摘しておきます。

＞ミシーさん

ご指摘の点ですが話が少々発散しています。つまり、WebClientは、WebRequestクラス、WebResponseクラス、Streamクラスより抽象度が高いかつ利用価値があるという判断で追加されたということでしょう。

＞Error401さん

＞その意味で言えば、gethtml()は具象度が高いと言えます。

私が書いた関数名が、gethttp()であれば、まさにError401さんのご指摘のとおりなのですが、私が書いた関数名は、getml()です。htmlはプロトコルを指しているのではなく取得するもの（戻り値）に関係しています。
とおりすがりより
2013-03-05 01:22:20
結合度の概念は凝集度とペアで議論しないと、トレードオフがなくなって収拾がつかなくなります。つまり、単純に低い結合度がよいのではなく、低い結合度と高い凝集度をバランス良く実現できる設計が良いのです。
どのバランスを最適とするのかは設計者の判断であり、人に依存します。しかし、設計者は判断の根拠を工学的に説明できる必要があります。説明とはもちろん記法上の好き嫌いの話ではなく、モジュールの変更可能性などの客観的性質から述べられるべきです。
ohfujiより
2013-07-01 22:01:53
いろいろ忙しかったもので、すっかり返信が遅くなりましたが、
＞とおりすがりさん
＞結合度の概念は凝集度とペアで議論しないと、トレードオフがなくなって収拾がつかなくなります。

私はHTMLファイルの取得についてJavaとC#でやり方が異なる例を挙げましたが、それを結合度と凝集度でどのように議論ができるか具体的に示していただければと思います。


さて、だいぶ脱線したのですが、ちょっと元に戻しますと、件のページ

http://el.jibun.atmarkit.co.jp/pressenter/2011/02/post-6b95.html

ですが、理由は不明ですが、いつの間にかコメント欄が大幅に消されていますね。
実は、一部どうかと思うコメントについて削除依頼を出していたのですが、当のエンジニアライフさんからは拒否されていたのですが、消されたところはちょうど削除依頼を出したところがカバーされていたので私としてはよかったです。

また、他にもアクションを起こしてみたのですが、当の本人が逃げたようです。自分が正しいと思うのなら堂々とすればよいかと思うのですが、書き込みについては収まったようですので、しばらく様子を見みます（まぁ、こちらも忙しいので・・・もっともまた書き込むようでしたら対応を考えます）。

このあたりも機会があればまとめたいのですが、今は忙しいので簡単に経過報告まで。

キッズより
2013-08-20 21:33:01
はじめまして。
くだんのコラムのコメント欄大量削除というのは、どのあたりを差していらっしゃるのでしょう？
特に消えたようには見えないのですが。

それから、「当の本人」とは、どなたのことでしょうか？
ちょっと意味が分からなかったので質問してみました。
ohfujiより
2013-08-22 12:25:38
キッズさん。コメントありがとうございます。

もともと件のページですが、コメント欄が全て出力されていましたが、６月の頭頃から下記の魚拓のようになっていました。
http://megalodon.jp/2013-0702-1413-31/el.jibun.atmarkit.co.jp/pressenter/2011/02/post-6b95.html

今と比べますと『次へ』のリンクがなかったわけです。
魚拓が取られたのが７月２日ですが、１ヶ月程このようになっていたので消されと判断しました。まさか『次へ』を付け忘れていたとは思いませんでした（テストをしたでしょう）し、今の『次へ』もいかにも取って付けたようなページャで使い勝手が悪いですね。

「当の本人」の件はわざとぼかしていますので、ノーコメントということで。
ohfujiより
2016-01-31 13:51:56
久しぶりに関連記事をアップしました。

http://www.ohfuji.name/?p=2864

コメントをどうぞ


『不適切なコメントへの対応』を一読下さい。
現在コメントは承認制となっております。

Previous Page | Next Page