>オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他の言語でもローカル変数であれば隠ぺいできる話。

カブセル化は、確かに非オブジェクト指向言語でも似たような機能はありますね。
それよりも、ポリモーフィズムがオブジェクト指向の肝だと思います。
ポリモーフィズムをうまく使うと条件分岐の記述を減してすっきりしたコードが書けます。

オブジェクト指向かどうかなかはどうでもいいと思います。

クラスは一度使うとやめられませんよ。
たとえば、ユーザー定義の構造体が必要になることはよくあるでしょう、
これを独自のクラスとそのコレクションのクラスにします。
これにデータを操作するメソッドを加えて、データをオブジェクトとして扱うことで、プログラムの可読性とメンテ性が飛躍的に向上します。
お書きのようにアルゴリズムには関係なく、データ部分だけ独立できます。

別コンポーネントとして独立させれば、プロジェクトで共有が可能です。

お書きの文章だと、
いまだに二階層システムで設計されているのでしょうけど、
失礼だけれど、勉強不足だとしか思えません。

設計や実装は若い技術者に任せるべきだと思います。

>いまだに二階層システムで設計されているのでしょうけど、
>失礼だけれど、勉強不足だとしか思えません。

いんやぁ、ここ１０年くらいは　クライアント、WEBさーばー、データベースさーばーの３階層システムばっかり構築してますよ。プログラムメンテが楽なんだもん。理屈こねてるよりVisual StudioでWEBアプリ作ればそれでいいの。

日ごろ、オブジェクト指向やらアイジャルやら、
方法論が万能のような考えには違和感を持っていた。
プログラムを安定して動く事が一番重要で、まさに理屈じゃないと思っていたのだ。
タイトルから、オブジェクト指向狂信者へのアンテテーゼかと思ったら、
あまりの内容の無さにがっかりした。

方法論としてのオブジェクト指向と実装論としてのクラスや構造化とはまったく別だと思うが？

内容な無いことを書いた上に、
「笑ってしまう」等、
失礼なことを書くならば、失礼な反応は当然覚悟されていると思うが、
あなたはもうコラムを書かないほうが良いかと思う。
もちろん私はもう拝見しないが。

>理屈こねてるよりVisual StudioでWEBアプリ作ればそれでいいの。
こんな人がいるから、へんてこなプログラムばかり増える。
オブジェクト指向狂信者も増える。
私はVBの標準モジュールやC#の静的クラスを有益と考えているので、
オブジェクト指向狂信者とは考えが合わないし、
動けば良いという考えは否定はしないが、
メンテナンス性か可読性を考えてた設計や実装は理屈じゃない。

アンチオブジェクト指向も、結局狂信者ということがよくわかった。

結局あなたは、ただのかたくなで偏屈な老人なんだね。

>あなたはもうコラムを書かないほうが良いかと思う。
>もちろん私はもう拝見しないが。

わたしのコラムを掲載するかどうかはエンジニアライフの皆様の判断によるものであり、コラムを書くか書かないかは本人の自由ではないですか？

>結局あなたは、ただのかたくなで偏屈な老人なんだね。

これはevergreenさんの私見とうけとります。かたくなで偏屈な老人が　ASP.NET C# で開発業務を行えると思いますか？　

evergreenさん、あなたこそ、コメントの文体からして、非常に硬く偏屈な印象を受けます。システム開発というものはつらい面もありますが、目標を達成したときはたえがたい喜びを受けます。柔軟な考え方でやっていくのが長くエンジニアライフを楽しむコツなのです。

なんで自分で本格的なクラスを作る必要がないのか？　それは .NET FRAMEWORK にすでに有用なクラスが豊富に存在し、それを使いこなすのも　Visual Studioという開発ツールを使えば簡単にできるということなのです。

ぬ様
貴重なご意見ありがとうございました。ポリモーフィズムについては勉強したいと思っております。

はじめまして、ryoと申します。

横から失礼します。

記事およびコメントを読みましたが、大変失礼を承知で言いますと私も

>結局あなたは、ただのかたくなで偏屈な老人なんだね。

と同じようなことを感じました。

なぜ、そのように感じたかと申しますと、
先ずは、記事ですが、これはオブジェクト指向の初心者が言っている愚痴にしか読めません。
内容が無さすぎます。
反論はあるかと思いますが、オブジェクト指向に言及して記事を書きたいのなら、もう少し
勉強してから記事にしましょう。せめてポリモーフィズムは理解しておきましょう。その位、
基本的なことですよ。
ポリモーフィズムも理解せずに記事を書かれも、
「所詮素人が解ったようなことを言っているな」
と取られますよ。
充分にオブジェクト指向プログラミングについて理解していない人が

>staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。

と書くと「己の無知を知らない恥ずかしい人が他人を笑っている」としか受け取れません。
が如何でしょうか？
このように書いてしまいますと御腹立ちになられるかと思いますが、その位、元記事のレ
ベルは低いです。このエンジニアライフで他の方が書かれている記事でもオブジェクト指
向について触れているの記事はたくさんあるかと思います。
もう少し他の記事を読んだりして勉強してから投稿されることをお勧めします。

また、evergreen さんの最初のコメントは、今風のキーワードに直しますと「MVCモデル」
の話につながります。
システムエンジニアを名乗り、
『システムエンジニアとして長期に活躍した経験に基づく極意、ノウハウを教えます』
とおっしゃるのなら、相手の技術的な主張を正確に消化できるようにならなければなりま
せん。理屈をこねていると取らないできちんと自説にのっとって反論しましょうよ。

>なんで自分で本格的なクラスを作る必要がないのか？　それは .NET FRAMEWORK にすでに有用なクラスが豊富に存在し、それを使いこなすのも　Visual Studioという開発ツールを使えば簡単にできるということなのです。

ここも、視野が狭い発言になっています。優秀なライブラリがあればそれを使うだけとう
のは間違いではないですが、.NET Freameworkですべては賄えないでしょう。
経験のあるエンジニアは大なり小なり自身で独自のクラスを作っています。
それこそ、昔の人が関数を作るのと同じぐらいにクラスを作ります。

最後に質問しますが、

>実はオブジェクト指向ってしっくりこないんです！

とおっしゃていますが、何がどうしっくりこないのでしょうか？
元記事を読んでも起承転結は見えないし、主張も見えてこないし、取りとめもなく終わっ
ており、結局、何が言いたいのか解りませんでした。
@ITの人は文章の書き方についてアドバイスしてくれないのでしょうか？

確かに、その年齢で、現役で開発業務を行われるのは素晴らしいことです。
ただもう少し、ご自身の経験が生かせる記事やコメントを書かれるよう期待します。
頑張ってください。

もうそっとしておいてあげましょうよ。

ryo様

evergreen様はもう私のコラムは見ないと断言したわけだし、構造体とかVBモジュールとか静的クラスとかCのような私が四半世紀前に習得した非オブジェクト言語の手法に近いことをうんちくを込めて書いただけです。ためしにこのエンジニアコラムで、evergreen さんを検索してみてください。あまり技術論とは関係ないようなことしかコメントしていません。

＞経験のあるエンジニアは大なり小なり自身で独自のクラスを作っています。
＞それこそ、昔の人が関数を作るのと同じぐらいにクラスを作ります。

OSやデバイスドライバの開発者ならば私もクラスを作ったでしょう。システムエンジニアを生業としているものにとってはどうですかね？
ryoさんいわく「経験のあるエンジニア」といってますが、ryoさん自身が作ったクラスについて、どういうものか説明してもらいたいものです。

>元記事を読んでも起承転結は見えないし、主張も見えてこないし、取りとめもなく>終わっ
>ており、結局、何が言いたいのか解りませんでした。

タイトルどおり、私はオブジェクト指向がわかってないのです。それでもユーザーの要望にこたえるために .NET FRAMEWORK を駆使して開発を行っているのです。
オブジェクト指向がわかっていないから、主張も結論もありません。模索しながら開発し給料をもらっている身なのです。そのところを理解して欲しいです。

ryo様、今回のコラムについては、オブジェクト指向がわかっていないから書いた。だから入門者とか、わかっていない人を対象にしています。あなたがすばらしいエンジニアならば、このような場でコメントしている暇があったら仕事に専念したり、自分の技術をブログにまとめたりしたほうが世のため人のためになると思います。

経験あるエンジニアが言うことだから、なにか深い思慮があっての内容なんだろうか？
と思って、最後までジックリ読んでみたけど、あまりにも内容が浅すぎてガックリきた。

無駄に経験を重ねてきた、と言われても仕方ないですな。
.NET Frameworkがオブジェクト指向で作られてる理由を、勉強し直すべし。

願わくは、コメント欄の閉鎖をされませんように。
自分に苦言を呈してくれる人がいるうちが華です。それに耳を塞げば、停滞が待っています。
自分と異なる意見から、何を学ぶか。学べるかどうかで、人としての価値が変わると思います。学ばない人、学ぼうとしない人に、新たな価値はないでしょう。

んで。
何がわからないのでしょうね。私も、最初はわからなかったし、今も解っていると言うことはできませんが、本文に書かれているような事を言うつもりは、全くありません。ケース バイ ケースではありますが、多くの業務アプリケーションで、オブジェクト指向は有用だと思います。
ここで、何がわからないのか、あるいは、どんなところがなぜ無駄だと思っているのか、ご自分の考えを分析して下されば、皆喜んで教えてくださると思いますよ。

みながわさん、こんにちは。

私は40歳近い者で、約15年前、大学の卒業研究にてNeXT上でのObjective-C言語によるプログラミングでオブジェクト指向を自分なりに把握したものの、就職したソフト会社ではCOBOLシステムの保守に回されて８年間「クラス？何それ？」の世界。その後お守りするシステムがJava（EJB）に代わって今に至るという者です。

会社では、ベテランCOBOLer向けのJava独習用資料を作って配布したりもしました。なぜそんなことをしたかと言うと、世にあまたあるオブジェクト指向、またはJavaの入門書、入門サイトが、「しっくり来ない」からなのです。「動物クラスを拡張して犬クラスを作り・・・・」なんて、子供じゃあるまいし・・・・従来からの非オブジェクト指向言語で実績を積んできたベテランには、それなりの教え方、伝え方があるんじゃないか？
（私が作った独習用資料がどれだけ役立ったかは心許ないですが）

ポリモーフィズムについては、私は
「関数へのポインタ（Ｃ言語）のデラックス版を使って、何かをやる」
と捉えています。Ｃ言語において、関数をそのまま呼ぶのではなく、ポインタを通じて呼ぶようにすると、
「たまたまその時、どんな関数がそのポインタに指し示されていたか」
によって、結果がまちまちになりますよね。
この特性を意図的に活用すると面白いことができるかも知れない。
引数と戻り値の型は揃っているが処理内容がまちまちな関数をいくつか用意しておき、プログラム実行時、その時その時の事情に合わせて関数をチョイス（ポインタにセット)すれば、後はそのポインタを通じて呼び出された関数が、宜しく仕事をしてくれる訳です。

さらに、複数の関数をまとめてポインタで扱えればより便利かも知れない。さらにさらに、その関数群の内輪だけで共通の定数や変数を持たせられればより便利かもしれない。（デラックス版)

私のオブジェクト指向把握の元となった本の一つが
塚越 一雄 著「ゲーム&&オブジェクト指向プログラミング」
というもので、内容は圧倒的に古いのですが、
「従来からの非オブジェクト指向言語に慣れ親しんだプログラマーに対してオブジェクト指向を解説する」
という問題意識に貫かれており、軽く、とても面白く読めました。もし関心を持たれたならアマゾンで中古で手に入りますのでお勧めします。

がると申します。
そこそこ古い年代の人間で、昔は「オブジェクト指向ってなによ？」な人間でした。

えと…とりあえず思いますのが。オブジェクト指向自体は「所詮、思考のための道具の一つ」だと、今でも思っております。
また、一般的にオブジェクト指向というと「オブジェクト指向プログラミング(OOP)」を指される事が多いのですが。そもOOP自体、いくつかの「異なる種類」がありますし。
また、OOP以外でも、OOA(オブジェクト指向分析)やOOSE(オブジェクト指向ソフトウェア工学)、OOAD(オブジェクト指向分析設計)、OOD(オブジェクト指向設計)などなど、色々なオブジェクト指向があります。

また。別に、例えばJavaやC#等を使えば「オブジェクト指向的にものが作れる」わけでもありませんし、逆にC言語でも「オブジェクト指向プログラミング」は十分に可能です(実際問題。ある程度以上「古くて、基礎だけはできあがっている人」には、C言語でのOOPの実装を、学習という観点からよくお薦めしています)。

そのあたりを踏まえた上で。「しっくりこない」理由に、私はむしろとても興味を持ちました。
理解した上で、その道具を使う/使わないのジャッジは各個人の自由だと思うのですが。
「理解するまでの過程」を記事として残されるのは、後続のいろいろな方々にとってもメリットがある記事になるように、私は思いました。

以上、私見恐縮ですが。

ぬ様
すばらしいコメントです。深い感銘と共感を覚えます。単なるコメントにしておくのはもったいない、ぜひともコラムニストになって記事を掲載していただきたいほどです。

>世にあまたあるオブジェクト指向、またはJavaの入門書、入門サイトが、「しっくり来ない」からなのです。

同感です。今回のコラムに記事の内容については自分でも稚拙であり、たぶん誰も読んでくれないと思ってました。今までの記事についてもランキングに上がらないし誰もコメントしてくれなかったのです。批判的な意見でも、この稚拙な記事でコメントしていただくのは非常にありがたいことだと思っています。過去のコラムの記事および今後掲載する予定のコラムの記事、すべてにおいて言えることは、本やサイトによく書いてあることを鵜呑みにするのではなく、自分の中で消化し自分なりのコンセプトを持つことであり、その努力が創造性を刺激したり、新たな技術に対する柔軟的な対応力を持つことの原動力になるということです。これが私のテーマの根底です。

>ポリモーフィズムについては、私は
>「関数へのポインタ（Ｃ言語）のデラックス版を使って、何かをやる」
>と捉えています。

インターネットで検索すれば「ポリモーフィズム」が何かわかります。しかしそれは表面的な知識で、実践でその技術を生かすためには、ぬ様のように自分なりの解釈をし消化していくことが大切なのです。

>従来からの非オブジェクト指向言語で実績を積んできたベテランには、それなりの>教え方、伝え方があるんじゃないか？

そうなんです。なぜいきなりstaticの話をしたか？　それは非オブジェクト指向言語のプログラマーがオブジェクト指向本を買い、最初のクラスとインスタンスの章を読んだだけで、今までの関数やグローバル変数が使えないのかと思って挫折してしまうのです。

私はシステムエンジニアとして働いているのでプログラミング以外にもハードの選定と導入、ネットワーク機器の配線、ウィルス対策などプログラミング以外にもやる仕事があり、なかなか、ぬ様のような深遠なコンセプトを抱く暇がないのですが、static関数に関してはオブジェクト指向っぽくない、ロジック関数ととらえてます。オブジェクト指向の教科書では、static　というインスタンス宣言しなくてもいいものがあると書かれているだけです。業務アプリケーションの実践においてはstaticと宣言されていれば、これはロジック関数であるということが人目でわかり、プロラムの可読性がかなりよくなるのです。

非オブジェクト指向で開発を行ってたかたが、ASP.NETでも業務アプリケーションが組めるようにするにはどうしたらいいのか？　データベースにアクセスするためにADO.NETのクラスを理解し、ロジック関数はstatic関数で実現するのが私はいいのかなあ・・・と思ってます。もちろん私の経験に基づく自論でありますが・・・

ぬ様　深く敬意を表します！

> staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう

↑ここが一番愚か。オブジェクト指向を理解している人は，staticを使うべきところとそうではないところをちゃんと理解しています。

「Visual Studioで供給しているSQL関係のクラス」のソースを読むことが可能なら読めばわかると思うけど，そうなっているはず。で，あなたはそれを書いた人に対して「いちいちインスタンス宣言しているので笑ってしまう」と面と向かって言えますか？　そこで議論して，相手を説き伏せられたならばそれはすごいことなので，その議論をぜひ公開していただきたい。そうしたら「愚か」という言葉は取り下げて謝罪した上で，素直に尊敬します。

あと，大域関数を使うのがあなたのスタイルだというならばそれは自由ですが，特にWeb系のような並行アクセスの多い系でそれを使うときは，critical section にちゃんと気を配ってください。そもそも並列処理をシンプルに記述しようとしたら，大域関数だけでコーディングするなんて面倒くさくてできないと思うので，自分でコーディングするときはともかく，他の人(特に部下)がインスタンス・メソッドを使ってコーディングするのを邪魔するのはやめてください。それだけはぜひお願いしたいものです。

>自分でコーディングするときはともかく，他の人(特に部下)がインスタンス・メソ>ッドを使ってコーディングするのを邪魔するのはやめてください。

私と同年代の人にstatic関数のサンプルコードを教えたとき、
「なんでstaticを使うのですか？」
と質問が来た。
「２０代の部下が、それはインスタンス宣言する必要がないから」
と返答した次第です。

確かに*まだ*オブジェクト指向は要らないみたいだね。インスタンスが一つしかない「シングルトン」だけで組めるうちはそれでもいいんだけど、複数のインスタンスを扱わなければならなくなったらクラスの使い方がわかるはず。

ABAPのことをAPAPって書く、ABAPer・・・。

みながわけんじ様とみ様のやりとりで、ブログのエントリ書きました。

http://bit.ly/a7Ez8c

理由があってstaticを使うのではなく、
理由が無いからstaticを使う。

理由が無い場合は、素直な方法を選ぶものだが、
何が標準かというのが違う人なのですね。

そこがオブジェクト指向が身についている人と、
身についていない人との違いなのでしょう。

> staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう

> 私と同年代の人にstatic関数のサンプルコードを教えたとき、
> 「なんでstaticを使うのですか？」
> と質問が来た。
> 「２０代の部下が、それはインスタンス宣言する必要がないから」
> と返答した次第です。

　わからない。「インスタンス宣言する必要がない」ものを、インスタンスを作ってアクセスしているから「笑ってしまう」？コラムなのだから、伝えることを意識して書いていただけないでしょうか。

> 今までの記事についてもランキングに上がらないし誰もコメントしてくれなかったのです。
　ランキングについてはわかりませんが、コメントがないのは「正しい」からです。正しい記事にコメントをつける人は少数ですが、「間違った」記事にコメントをつける人は、たくさんいます。（ここで「正しい」「間違った」は、読者にとっての「正しい」「間違った」で、絶対的な正しさではありません。）

　私は、クラスメンバーを「隠す」ことができることに、有用性を感じています。今、C言語で作られた、他の人が作ったコードを保守しています。そこで感じるのは、変数がどこで宣言されており、どこで参照／変更されているかを探すのが、非常に厄介だということです。特に、どういう思想で作ったものか、.cコードの中でextern宣言を繰り返しており、本体がどこにあるのかわからない関数に手を焼いています。grepしても、見つけにくい。タグファイルつったけど。
　きっちりとC++で書かれていれば、クラスの宣言を見るだけで、「何か」がするべき仕事のすべてわかります。これは、何らかの修正をしたときの影響範囲が限られるということでもあります。（最近のC#では、partialや拡張メソッドによって、その影響範囲が広がってしまった。）このことは、テストのし易さにもつながります。
　グローバル変数が使えないことを嘆くより、グローバル変数を使わなくて良いことを喜ぶほうが、大きいです。

とりあえず「クラス名 インスタンス名」を何とかした方が良いと思います。
C# でも VisualBasic でも、こんな記法はできませんから。

なにか強烈な勘違いをなさっていませんか？
例えば C# を使っているつもりが、実は C# じゃなかったとか……。

話題になってるのでこちらのURLで検索してみたらhttp://wondsky.hp.infoseek.co.jp/memo.html
を見つけて残念な気持ちになりました。

以下抜粋
>ライフというよりは、かなり技術論的なものであるので当然、まったく受けない！！！　このコーナーって冗談のような苦労話や変人との付き合いでないとう受けませんね。私の狙いとしては今後を担う若手技術者のスキルアップに役立って欲しいのですが・・・

これはコラムニストに対しても読者に対しても失礼な発言です。

現に有意義なコラムは正しく評価されてます。貴殿のエントリーを拝見しましたが、誰もが知る内容を無難にまとめただけの文章に見受けられました。

はっきり申し上げますが、受けなかったのは多くの人達にとって価値が無いからです。読者へ転嫁する考え方が残念でなりません。

初めまして。楽しく読ませていただきました。
私もみながわさんと年齢が近く、新入社員時代から数年はシステム開発をしていましたが、現在はIT教育の講師を務めてもう20年近くになります。
オブジェクト指向は1996年にJavaが正式にリリースしたあたりから勉強しだしました。現在はJava以外に、C++などのオブジェクト指向言語や、C言語、PHPなどの非オブジェクト指向言語も教えています。最近は関数型言語にも興味を持ってSchemeやHaskellなどの言語を勉強しています。
オブジェクト指向って難しいですよね。私は頭が悪いせいか、それなりに理解して、自由自在にプログラミングできるまでに３年ぐらいかかったと思います。
それでいて、色々と書籍を読んだり、他の言語を勉強していると、最近でも新しい発見をすることがあります。
みながわさんも色々と書籍は読まれたと思いますが、もし読んでいらっしゃらなければ、
『オブジェクト指向のこころ』(ISBN4-89471-684-4)の、第1章「オブジェクト指向パラダイム」をお読みになると、ずいぶんオブジェクト指向に対する印象が変わるのではないかと思います。

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

大変御腹立ちなのなわかりますが、
やはり何が言いたいのかよくわかりませんでした。

これ以上、待っても出てこないと思いますので、
失礼ながら、みながわさんの言いたいことを想像してみました。

------------------------------------------------------------------------------
あえてオブジェクト指向を使わない

オブジェクト指向言語が流行りだして10年以上たつでしょうか、Microsoftも.NETからオ
ブジェクト指向100%になり、VB6のようなオブジェクト指向言語を避けたい人向けの言語
がなくなってしまった。

ほんの10年前までは当たり前のように非オブジェクト指向言語を使って仕事をしていたの
が、今では、
『オブジェクト指向がわからない』
と言うとまるで開発者としては欠陥品扱いを受けるが、本当にそうだろうか？

オブジェクト指向言語でないとダメな理由はなんだろうか？
業務アプリケーションを作る立場で考えたい。

確かに、GUIやライブラリの等のアプリケーションから共通で使用されるものはオブジェ
クト指向言語がもつパワーは必須かもしれない。.NET FRAMEWORKをみると、それまでVB6
で使用していたライブラリとは比べ物にならないくらい便利になった。
これは使う価値がある。

業務アプリケーション自体にはオブジェクト指向は必要だろうか？

10年前と今では、情報システム部門が受けるプレッシャーはますます大きくなっている。
システム要員に求められているスキルが単純にプログラムが組めるというだけでなく、
ネットワーク等のインフラの知識や、ファイルやDBサーバーの管理のスキル、はたまた
セキュリティ等、多岐にわたっている。これらが定期的にバージョンアップを行い、
その都度対応に追われている。
その上、度々、新しいバズワードが出てきて、そのたびに上司に説明をしなければならな
い。この間は、「クラウドって何？」という無邪気な顔をして聞いてくる上司に思わずた
め息をついてしまった。
そういった状況では、オブジェクト指向技術を身につける優先度は相対的に下がってしまう。

一方で、わが社の場合、業務ロジック自体は20年前とあまり変わっていないことに気がついた。
確かに新サービスが始まったり、ECサイトの構築とかがあったりするが、冷静に考えると
業務自体は昔とあまり変わっていない。例えば会計システムを考えると会計ソフトの導入
に始まり、販売管理システムとの連携(データの取り込み）があり、続いて分析システムと
の連携（データの送り出し）と発展してきたが、会計システム自体はあまり変わっていない。
もちろん税法その他の法律に対応する為の仕様変更、その他扱うデータ項目の追加はあった
が、基本的なことは変わっていない。
もちろんそういったシステムは、非オブジェクト指向のコードが使われている。がそれをオ
ブジェクト指向で書き換える必要があるのだろうか？
この場合、レガシーな言語の知識は必須となるがオブジェクト指向の知識は必ずしも必要と
ならない。

ECサイトは、今まで、ASPで作成してきたが、最近、サイトのリニューアルに合わせて書き換
えることになった。
継ぎ足し継ぎ足しで来たがここに来て一度整理が必要になった。ASPは今後のサポートが不安
なので、C#を使うことになったが、これはバリバリのオブジェクト指向言語になる。
残念ながらわが部署にはオブジェクト指向に詳しい人間がいない。

ここで、私は、必要最低限つまり、.NET FRAMEWORKを使う部分だけオブジェクト指向を使い、
ロジック的な部分は従来どおり非オブジェクト指向を使うようにしようと考えた。
つまり、継承やプロパティ、もちろんインスタンス化の機能等はあえて使わず、全て静的ク
ラスで作成することに決めた。
静的クラスを使うことにより、ロジック部分は従来と同様に非オブジェクト指向が使えるよ
うになる。こうすることにより最低限の教育コストで開発が行える。

多くの人から、『きちんとオブジェクト指向をマスターした方が良い』といわれたが、オブ
ジェクト指向をマスターするには1年,2年はかかりそうだし、またそうやって作ったシステム
が安定するのか疑問だ。そう、昔JAVAが流行っていた時代に、サーブレットを使ったWEBサイ
トを良く見かけたが、その中には、速度が遅かったり不安定で、結局改修に多くの費用をか
けたものもあったと聞いた。
そういった中で、うちのASPのサイトは機能的には見劣していたが、速度も安定性もそこそこ
で動作していた。
オブジェクト指向がわからないエンジニアは、無理にオブジェクト指向を使うのではなく、
あえて使わない。正確にいうと避けるというのも手ではないだろうか？

流行りに流されずに無理せず、自分の実力の範囲内で安定したサービスを提供するのもエ
ンジニアとしての務めだと考える。

------------------------------------------------------------------------------

みながわさんが言いたかったことはこういうことで、
よろしかったのでしょうか？

なるほど。Javaに対するGroovyのように、.Netにもスクリプト的な簡便なツールがあるといいなあ、という潜在的な需要ですね。
ただ、コラムの題名に合わせると、生き残るためには仕方のないことなのかもしれませんが、そのオブジェクト指向自体を否定する(オブジェクト指向をすべきところでもしない方が自分は楽だ)考え方を、未来のある若い人には伝授されない方が良いと思います。また、積極的に他の方にも広められない方がよろしいかと思います。そういう意味ではコラムの目的からは外れた記事になっていると感じます。
おそらくこういう記事に否定的なコメントに対しては、責任を特に若い読者に転嫁されるのでしょうが、そのような反応がまた巷で話題を呼ぶことでしょう。
なお、Twitterでも既に「否定的に」話題になり始めているようです。
http://twitter.com/#search?q=http%3A%2F%2Fel.jibun.atmarkit.co.jp%2Fminagawa%2F2010%2F04%2Fpost-ebc4.html

現場的には「オブジェクト指向をあえて使わない」と言う選択はあります。
とっても残念だけどよくあります。

たとえば「ぽりもふぃずむってなんですか？」「グローバル変数が使えないなんて、どうやってプログラムするんですか？」と聞いてくるような素人がメンバーの半数近く占める場合や、さらには開発リーダーがプログラミング経験十年以上の自称ベテランだけどポリモフィズムも知らなければGoFも読んだことがないような場合は、もう諦めるほかありません。

残念だけど日本ではよく見られる光景ですよね。

でもこれはオブジェクト指向とかプログラミング言語の欠陥ではなく、企業や組織の欠陥です。欠陥企業や欠陥開発チームや欠陥プロジェクトリーダーには、どれだけすぐれた言語やツールやテクニックも豚に真珠なのです。まずは豚を丸焼きにして食べる所から初めてはいかがでしょうか。

http://www.melma.com/backnumber_120830_237624/

この記事を読んで何を思うか？
これは型にはまった例題で、はたして実践でこのfor ループの処理を使えるであろうか？
配列要素数が４つしかない例題だが、配列要素数が1万個あったら、それぞれコンストラクタで1万回インスタンス生成をしなければならないのか？
forループ中に条件分岐がないが、コンパイルされたアセンブラ語レベルでは条件分岐はあり、パイプラインブレークによるパフォーマンス云々の話はありえないのではないか？

　C++が提唱されたのは１９８３年であり、そのころの若いエンジニアは私と同年齢であります。ですからオブジェクト指向わかる、わからないというのは、年齢の話ではないのです。
　おっしゃるとおり企業の組織の問題はあります。ひとりの優秀なプログラマーが転職してしまうとすべてのアプリケーションのメンテナンス保守が継続して行えなくなるというリスクがあるからです。

いろいろゴチャゴチャ書かれているけど、結局オブジェクト指向プログラミングを否定したいってことだね。

こいつ最高にあほｗｗ

みながわさん、こんにちは。
先ほどのコメントを読んで、さらに残念な気持ちになったので投稿させてもらいます。

オブジェクト指向は確かに難しいです。
VBとかなら「変数、関数/プロシージャ、文字型、数値型、配列、if文、forループ」ぐらいが分かれば何とかなりますが、オブジェクト指向は理解すべきことがもっと多いです。
そして従来のやり方に慣れていればいるほど、「別にオブジェクト指向なんていらない」と考えるのも仕方が無いと思います。

入門本にはよくイヌやネコ、クルマとタイヤのたとえでオブジェクト指向を説明してありますが、「それで何がうれしいねん！」と思われるのももっともです。
私もあの手の説明は現実のプログラムとはかけ離れすぎており、実務では使えないと思います。

私はここでみながわさんにオブジェクト指向を理解してもらおうとは思いません。
こんなところで説明してもほとんど伝わらないでしょうし、好みの問題があればなおさら理解してもらえないと思うからです。
むしろプログラミング手法はあくまで手段であり、システムが正しく動き、保守性も十分ならば、.NETやJavaであえてオブジェクト指向を使わないやり方も全然ありだと思います。

ただし、このコラムの書き方だけは「しっくり」きません。
ryoさんが書かれているような文面であれば逆に共感を得られたと思いますが、オブジェクト指向のセオリーと真逆のやり方を自信満々に語ってしまったのが致命的だったと思います。
「笑ってしまう」の一文は上から目線の極地で、本当にダメ押しですね・・・。私も「おいおいおい！」と思わずツッコんでしまいました。

しかもそれを発表したのが、@ITのエンジニアライフだったというのも失敗だったと思います。
巷にあふれる個人のブログなんかに比べれば、はるかに多くの人の目にさらされますし、それなりの品質を求められてしまうのは仕方が無いと思います。

私もこのコラムを読んで「こんな大きな誤解を真に受けてしまう人が出てきたらイヤだなあ」と感じました。
結局のところ、これはみながわさん個人の問題ではなく、@ITの担当者さんが防波堤として公開前に内容をもう少しチェックすべきだったのかもしれません。

>ひとりの優秀なプログラマーが転職してしまうとすべてのアプリケーションのメンテナンス保守が継続して行えなくなるというリスクがあるからです。

オブジェクト指向は、まさにこういうリスクを軽減させるために有効だと思いますよ。
インターフェースと実装をしっかり分離してあれば、他の人がコードを再利用するのが格段に楽だし、余分な部分を追う必要もないですよね。

蒸気機関だけOKな社会なら古典物理学で問題ないけど、PCや携帯を使いたい社会を成立させるには量子論が必須だってことです。

否定するのは自由ですが、みながわさんの論理は単に食わず嫌いか、勉強不足としか思えません。オブジェクト指向を使い倒した上で否定するなら、それなりの説得力があったのでしょうが。

>>みながわさん

> http://www.melma.com/backnumber_120830_237624/
> この記事を読んで何を思うか？

URL 貼ったのはその記事とご自身のコラムを比較して、ということでしょうか？
「こんなに低レベルな記事があるんだ、俺のはましだ」と？
確かに件のメルマガ "【C#プログラミングレッスン】 No.037" がナイスな記事だとは思いません。
が、それはわざわざその低レベルなコラムとご自分の記事を並べ、自らをより底質なモノへと貶める愚かしい行為と言えるのではないでしょうか。

下を向いてもキリがありません。
罵倒の中に有用な意見があるなら、そこだけ都合よく読んでおいて「ためになったよ指摘ありがとう」
と言えるくらいずうずうしい方がよいのだろうななどと妄想しました。

※というのを自分に言い聞かせておくつもりで投稿・・・

私のイメージ（比喩）で言うと、
自分はクロールを覚えて、クロールしか知らないけど、クロールがとても得意になって、プールでも海でも泳ぐのにはまったく困らない。最近ちょっと平泳ぎっていうのをやってみたんだけど、スピードはでないし不格好だし、クロールで十分だよな。オリンピックからも平泳ぎなんて外しちゃえば良いのに。きたじまこうすけとか、笑っちゃうよな。
という印象です。

同じような流れの処理なのに、データの種類によっていちいちifやswitchの塊だのジャンプテーブルだので分岐するのは面倒(可読性や保守性の低下)だと思いませんか?
入出力先がメモリでもディスクでもネットワークでも、全く同じインターフェースでアクセスしたいと思いませんか?
普段は素通しの入出力データを、メモリ上でちょいと加工して次の処理に流したくなることはありませんか?
ライブラリ等のある特定の処理にだけ、対象に手を加えずに独自のコードを割り込ませたくなることはありませんか?
同じデータ構造に対する操作は、一ヶ所にまとめたいと思いませんか?

どれ一つとして「無い」ということであれば、オブジェクト指向的な考え方と相容れることは永遠にないのかもしれません。

OOPは理解できないから使わない、と主張されるのは結構だと思います。オブジェクト指向的な設計をしなくともソフトウェアは作れます。現在でもそのような主張をするエンジニアを何人か知っていますし、私自身もOOP以前からソフトウェア開発を行ってきました。

しかし、自分が理解できないからといって「知ったかぶってOOPするヤツら笑っちゃう」というような論調で話を進められるのは宜しくないですね。大変失礼ですが、OOPが理解できないから僻んでいるのだな、と思ってしまいました。

ソフトウェアの設計＝フローチャート、だと思われているのではないでしょうか？もちろんOOPにおいても最もミクロなレベルにおける設計（関数・メソッドの中身）はフローチャートで表せるものです。そこは変わらず基本となります。OOPはよりマクロな設計を行うための考え方なのです。

マクロとは言っても、関数が10個程度のちょっとしたソフトでもオブジェクト指向的な設計は有用ですし、規模が大きくなればより有効なのが事実です。設計や実装が効率的、設計の文書化も容易、（良い設計であれば）設計した人でなくとも全容を把握しやすくなります。ですから皆「１度使ったらやめられない」のです。

変数が隠蔽できるか否かはOOPの本質ではないんです。そもそも言語仕様としてクラスやプロパティがあるかどうかも本質ではないのです。言語仕様はよりOOPしやすくするための道具にすぎません。純粋なC言語でも、OOPすることは十分に可能です。

極意を示すコラムなのですから、OOPを理解したうえで「俺はOOPしない！」と主張する生え抜きのロートルエンジニア（＜良い意味で言っています）が、その経験と技術でもってOOP全盛時代を生き残る方法論を論じる、くらいのレベルの高さがあって欲しいですね。

蛇足ですが、ホントはどんなロートルでも今日からOOPを導入したほうが良いと思いますよ。純粋なC言語だろうと、N88-BASICだろうと、今から何か作るならOOPすべきです。ソフトウェアの設計において、それだけ画期的なものです。賞賛やヨイショではないですよ。

う～ん、でもN88でOOPはさすがに無理かなぁ（笑）

> http://www.melma.com/backnumber_120830_237624/
> この記事を読んで何を思うか？

以下のやり取りを想像しました。

後輩：せんぱーい、virtualってなんですか？
私：↓これみて勉強しろ！
　　http://www.melma.com/backnumber_120830_237624/
後輩：ところで、オブジェクト1万個作るって大丈夫でしょうか？
私：で、virtualは解ったんか？
後輩：あ、はぃ、解りました。

ちなみに、元記事の場合、

後輩：せんぱーい、staticってなんですか？
私：↓これみて勉強しろ！
　　http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
後輩：せんぱーい、この人staticって言いたいだけで、何が言いたいのかさっぱり解りません。
私：ん？．．．．あ．．．すまん．．．．

となるでしょうか？

#すんません。不快に思う方もいらっしゃると思いますが、
#どうしてもネタにしたかったので書きました。愚かな私自身を含めて笑ってやって下さい。

どうしても技術的な話をしたいみたいなので、ちょっとのりましょう。
といっても私は、最近まで、C++を使ったプロジェクトで2カ月間程缶詰にあって、プロジェクトがひと段落したので、息抜きで書き込んでいただけで、先に、みながわさんが指摘されたとおりそろそろ仕事に戻らねばならないので、このあたりで終わりになるかもしれません。

>配列要素数が４つしかない例題だが、配列要素数が1万個あったら、それぞれコンストラクタで1万回インスタンス生成をしなければならないのか？

そうです、1万回コンストラクタを呼び出し、インスタンスを生成します。
これは、メモリ容量のことを心配されての質問でしょうか？
それとも、パフォーマンスについての心配でしょうか？
15年前ならこの質問もありかと思いますが、何れにしても今は、その質問自体が無意味です。
例題は、GUIを扱っていますが、おそらく貴方が使っているWindowsのデスクトップでも数千個のオブジェクトが生成されているかと想像されます。
また、ヘビーユーザの場合、1万個以上のオブジェクトが生成されているでしょう。
うんちくを語りますと、うちの社で、ものすごいヘビーユーザが居て常時ウィンドウを80個程開いています。
その方のマシンのデスクトップヒープは、40MB程に設定しています。ネットを検索して調べますと40MBで約20万個のコントロール（オブジェクト）の生成が可能とのことです。
WindowsXPではこんなにデスクトップヒープを確保できないので、そのユーザさんはWindows 2003 Serverを使ってもらってます。
贅沢ですが、それだけ仕事をして下さるので、問題ないです。

みながわさんは、C言語の経験がおありで、C++および機械語にも言及されたので、その範囲で、私のインスタンス化およびメソッドの理解について説明します。

先ず、C言語で、以下のようなコードがあったとします（コンパイル等のチェックはしていません。。。）。
--------------------------------------------------------------------------------
struct CustomerRecord customer;
int result;
char name[512];

/* name に値を設定するコードがある */

result = ReadCustomer( &customer, name); /* nameからcustomerに値を設定する */
if ( result != 0 ) {
　　/* customerが見つかった */
　　DisplayCustomer( &customer); /* Customerの内容を表示する */
}
--------------------------------------------------------------------------------

で、これをC++に書き換えますと（こちらもチェックはしていません。。。）
--------------------------------------------------------------------------------
CustomerRecord customer;
int result;
char name[512];

/* name に値を設定するコードがある */

result = customer.Read(name); /* nameからcustomerに値を設定する */
if ( result != 0 ) {
　　/* customerが見つかった */
　　customer.Display(); /* Customerの内容を表示する */
}
--------------------------------------------------------------------------------
になるでしょう。

この時に、ReadCustomer関数を呼び出す機械語のコードと、Readメソッドを呼び出す機械語のコードを比較しますと、違いはありません。文字通り同じになります。

インスタンス化について「わからない」とおしゃっていますが、Cの例を見てもらえばわかりますとおり、構造体というのはオブジェクト指向以前からあり、当然にその実体の定義（インスタンス化）もC言語の時からあります。
構造体のインスタンス化の定義（インスタンス化）を否定するのは構いませんが、つまり貴方は構造体を使っていなかったということでよろしかったでしょうか？
なので、そもそも論として、

インスタンス化の何に違和感があるのか私には解らないです。

C言語に精通したエンジニアにとって、C++のメソッド呼び出し（およびオブジェクト指向のもろもろの拡張）は、シンタックスシュガーにしか見えません。
classはstructの読み替えということで理解可能です。
（もっとも最近のclassは、Cのstructとは違いますので注意が必要です。そうstructとは違うのだよ。）

少なくとも私の周りになりますが、本当にC言語をマスターしたエンジニアは、C++が解らないという話はあまりしなかったです。
もちろん、カプセル化に違和感をもったり、継承を使うとかえってプログラムの流れが追っかけにくくなるとか仮想関数って自前で関数テーブル作ればいいじゃんとかいう話はありました。

>forループ中に条件分岐がないが、コンパイルされたアセンブラ語レベルでは条件分岐はあり、パイプラインブレークによるパフォーマンス云々の話はありえないのではないか？

もう、そろそろお分かりになられるかと思いますが、こういう質問は、きちんとお金を出してオブジェクト指向およびプロセッサのアーキテクチャに精通している方に師事を受けた方がよいです。
私？。。。いやご勘弁下さい。（商売っ気がなくてすみません。）

先ににも申しましたとおり、
タイトルから、オブジェクト指向へのアンチテーゼかと期待していたわけです。
しかしあまりにも意味がない。

私は、手続き型や構造化からオブジェクト指向言語に移行するためには、
スカラーデータのクラスへのマッピングが一番メリットを感じ安く、
簡単だと思ったから、「クラスを作るメリット」について書いたわけですが、
食いついてきたのが「二階層」云々で、しかも「理屈」ときたから、
これはダメだと思ったわけです。
しかもそんな自分を柔軟だと仰る。

その場しのぎのコメントを並べ連ねて付和雷同するにいっては、
「笑ってしまう」より「呆れてしまいます」ね。

あなたが生き残っていられるのは、
「企業の情シ」というクローズドな環境にいるからです。
（「企業の情シ」が楽だとかレベルが低いという意味ではありませんので、情シの皆さんは誤解しないでください）
あなたは自分の技術にかなりのプライドを持って居られるようですが、
オープンな人材市場ではあなたには、業務知識にしか値段が付かないでしょう。
（ここは多くの方に同意していただけるはずだと思います）
そこを自覚された方がよろしいかと思います。

私は、自分を優れた技術者だとは思っておりませんが、
クライアントを持つ「一般的な」業務システムの開発では、
クライアントやプロジェクトに合わせて、「柔軟」に対応しなければならないのです。
あれは嫌だ、これは出来ない、とは言っていられないのですよ。

いちまんこのインスタンスを生成するのに、時間だとかメモリだとかが心配なら、GoFのProxyやFlyweightなどのパターンを考慮すれば良いのじゃないかと思いました。でも、みながわさんは、設計まで想いを馳せることはできなくて、実装レベルで議論しているようなので、そんなことは思いつかないのか、もしくは、知らないのかも...

＞ これは型にはまった例題で、はたして実践でこのfor ループの処理を使えるであろうか？
＞ 配列要素数が４つしかない例題だが、配列要素数が1万個あったら、それぞれコンストラクタで1万回インスタンス生成をしなければならないのか？

何でそんな読み取り方ができるのですか。初期化の部分は説明の為に「あえて」簡略化してあるだけじゃないですか。

この記事はポリモーフィズムの話であってインスタンス生成や最適化やアセンブラの話とは違います。

forループ内で条件分岐していれば満足ですか？だとしたら、条件分岐のフラグはどうやって設定するのですか？ 1万回のインスタンス生成はダメで、1万個のフラグを立てるのはいいのですか？条件分岐が1万個あったらどうするのですか？

円や台形の面積を求めるときに、どうすればよいか想像できませんか？

むしろC言語の構造体はいやになるほど書いたから、逆にビジネスロジックのクラスの優位性についてピンとこないのです。
私は業務アプリで一万個のオブジェクトを扱う場合ならばデータベースを活用します。一万個の図形のIDとその形をレコードに登録して一万件登録します。一万件のインスタンス生成を一万行のコードを書くわけがないのですから、データベースから読み出して、その形により違うコンストラクタを読み出すと考えるわけです。その場合はインスタンス生成をする時に、形にしたがって、条件分岐しコンストラクタを使いわけるようになります。結局、どこで条件分岐を使うかだけの問題に帰着します。

だいぶ楽しませてもらいましたが、そろそろ仕事をしないとダメなので手短にします。

まぁ、お気持ちはわかりますが、やはり失礼ながら頭が固くなっているとしか思えないです。

データの流れが、以下の場合ならみながわさんのおしゃるとおりになるでしょう。
DB→メモリ（コンストラクタ）→画面（表示処理）

で、以下の場合を想像してみてください。
DB→メモリ（コンストラクタ）→画面（表示処理）→処理1（変更）→画面（表示処理）

処理1には適当なものを想像して下さい。
こういうとまた変に突っ込まれそうだから形を変える変更と思って下さい。

この場合、条件分岐が必要なのはコンストラクタの部分のみで、画面表示や処理１は
仮想関数呼び出し（つまり関数ポインタによるCALL）になります。つまり

最初の１回だけ場合分けを行えば、後は場合分けの必要がないというのが、ポリモーフィズムの考え方になります（場合分けを１回も行う必要がないってどんな魔法やねん）。

もうお分かりでしょう。
DBに格納するオブジェクトに対してほとんど加工の必要がない場合やそもそも格納されているオブジェクトの種類が少ない場合はたまた逆に種類がありすぎたり細かすぎる場合等、クラス分けが意味をなさない場合は、ポリモーフィズムの恩恵は受けません。

ご自身が扱うオブジェクトを、どのようにクラス分けすると上手くいくのか、という考える過程がまさにオブジェクト指向設計になります。がこの設計はかなり高度になります。正しく業務知識を把握しかつ、正しくオブジェクト指向のスキルを身につける必要があります。

ツッコまれそうなので言っておきますと、巷で言われている程、オブジェクト指向が業務アプリに浸透していない理由がここにあります。

で、ついでに仮想関数呼び出しのコストについてですが、まぁ、本当は先のブログを書いた人に説明してほしいのですが、うんちくついでに語りますと、私の理解では、仮想関数呼び出しは、必ず分岐予測のペナルティが発生します。なので結構コストが高いです。if文の場合、投機実行が行われ運がよければペナルティが発生しません。しかし、if文が10個連なった場合では、数回の分岐ペナルティが発生するでしょう。この場合は、仮想関数呼び出しの方がお得になります。もっともこのあたりの話はケースバイケースになります。

では、私はこのあたりで失礼します。
まぁ、『staticって言いたいだけでした。愚かな私に教えを！』というのならまたお邪魔するかもしれません。

>最初の１回だけ場合分けを行えば、後は場合分けの必要がないというのが、ポリモ>ーフィズムの考え方になります（場合分けを１回も行う必要がないってどんな魔法>やねん）。

ryo様　了解！！！
ryo様は文章を書いたり説明をするのがうまいですね。どのオブジェクト指向の先生方よりもポリフォーフィズムの恩恵をうまく説明したのですから・・・パチパチ

みながわさん、こんにちは。

>みながわけんじ 2010年4月28日 (水) 08:53
>
>むしろC言語の構造体はいやになるほど書いたから、逆にビジネスロジックのクラスの優位性についてピンとこないのです。

このサイトを見てはどうでしょうか？
http://kmaebashi.com/programmer/object/index.html
この方は
「インスタンスを複数作ってこそ活きるオブジェクト指向」
という考えで、異論ある人もいると思いますが、私は結構納得しました。

ところで、私は入社以来ほとんど１つの顧客の業務システム保守という経歴で、今お守りしているシステムはJavaなのですが、もちろんフレームワークはオブジェクト指向に則って作られているものの、ビジネスロジック部で、積極的にオブジェクト指向を取り入れているのを見たことがない。
（結構名のあるソフト会社が作ったのに）
これは私の経験の狭さ故であり、巷ではいろいろ使われているのだろうと思っていたのですが、

>ryo 2010年4月28日 (水) 10:58

>ツッコまれそうなので言っておきますと、巷で言われている程、オブジェクト指向が業務アプリに浸透していない理由がここにあります。

を読んで、実はどこも大差ないのかも知れないなぁと感じました。
「オブジェクト指向はこんなにすばらしい！」
などの賛美は正直「もうお腹いっぱい」なので、
「私が手掛けた○×業務では、コレコレこういう業務の性質上、コレコレをクラスとして定義し・・・・・」
といった、「生きた話」を、差し支えない範囲で聞きたいなぁと渇望しているのですが、なかなか出てこないのが残念ですね。
（Webでタダで見ようという魂胆が駄目か？）

＞ 逆にビジネスロジックのクラスの優位性についてピンとこないのです。

全面肯定しているわけでもありませんが、ビジネスロジックや企業文化に依存するので否定しません。プログラムさえ動けばいいという考え方も(残念ですが)否定しません。

＞ 私は業務アプリで一万個のオブジェクトを扱う場合ならばデータベースを活用します。

もう一度言います。リンク先の記事は、初期化の部分は説明の為に「あえて」簡略化してあるだけです。普通に考えても1万個のインスタンス生成に1万行費やすわけないでしょう。

ポリモーフィズムの説明に、データベースの説明が必要ですか？パフォーマンスを考慮する必要がありますか？デザインパターンを持ち出してきてもいいのですか？

＞ 結局、どこで条件分岐を使うかだけの問題に帰着します。

帰着しません。インスタンス生成もポリモーフィズム(だけじゃないけど)で条件分岐をなくすことができるケースはあります。

ぬさん

>（Webでタダで見ようという魂胆が駄目か？）

そのとおり、こんな厚かましい考えでは誰も返信してくれないでしょう。
もっとも、ひょっとしたら、返信できない理由が他にあるのかもしない、思いつくのをあげてみました。

１．多態性、たたいせい、て言いたいだけの、ただのいたいやつ（無理があるか・・・）。
２．ポリモーフィズム言いたいだけで使ったことがないペーパーポリモラー。
３．ここを仮想関数にすればと思いながらシステムがデカ過ぎて影響範囲が解らないので実行に移せないビビり君。
４．転職を繰り返しすぎて、業務知識が解らないので具体例が思いつかないOOオタク。
５．お遊びで書き込んで見たがマジレスされてネタに困った暇人（だからオレはヒマじゃないって）。

まぁ、結局偉そうなこと言ってもこんなもんですよ。

ryoさん、こんにちは。

なるほど、やっぱり幸せは空の上に、雲の上にしか無いのかなぁ・・・

ポリフォーフィズムという言葉が流行はじめたのは、Perfumeがポリリズムという曲をリリースしたころですか？？？　なんか言葉が似ているから若者の間で浸透したんじゃないの？？

私が１５年くらい前に読んだC++の本では多相性と書いてあったと思います。今ウィキキペディアではポリフォーニズム、多態性、多用性と書いてありますね。ぬ様がポリフォーニズムという言葉を最初のコメントで出したときには聞いたことがなかったのですが、昔そんなこと本に書いてあったなと思い出したんです。

ポリフォーニズムを使ってクラス構築するなんて、四暗刻で上がるくらいに一生に一度あるかないかのチャンスです。それでもマージャン好きな人は役満上がりの夢を見るでしょう。

私はピンフ、タンヤオの安上がりでも、とにかく仕事をこなしていかなければならない身なのです。

廃業したY証券のシステム会社に所属していたことがありますが、当時、証券業務のビジネスオブジェクトの研究？？？をしていた方がいましたが、はっきりいってうさんくさかったです。今は何をしているでしょうか？何かうさんくさいものを直感し近づかないこと、それが長期にわたってシステム業務を行なうノウハウだと思ってます。また偉そうなおやじですいません。

interface に対してロジックを記述するようなプログラミングしてたら、
ポリモルフィズムは当たり前すぎて特に意識してないと思います。
最近の流行りだと継承よりも委譲だーなんていわれてますし、重要な要素というよりは
ごく普通の概念としてみんな受け入れてる(or受け流してる)んではないでしょうかね。

設計の話ですと、小規模開発ならいわゆるアジャイルもどきっぽいこともします。
だーっと作って動かして機能追加を繰り返してリファクタリングしてるうちに
自然と構造化とかクラス化したものがしっくりくることがやや多いです。
(私が最初から気合入れて設計してコーディングしても、空回りが多い……

あと私Web系よく知らないんですが、既存フレームワーク使ったら普通にクラス使うハメになったりしないんですかね？

SQL関係のクラスを使っているのならpolymorphismの恩恵を受けてるはずなんですけどねぇ。

よく知らないライブラリをなんとなく使ってコード書いてたら不安でしかたないと思うんですが。

こんばんは。

> ポリフォーニズムを使ってクラス構築するなんて、四暗刻で上がるくらいに一生に一度あるかないかのチャンスです。それでもマージャン好きな人は役満上がりの夢を見るでしょう。

ポリモーフィズムですね。
一生に一度どころか、ごくごく普通に使ってますが何か？
使い古された言葉ですが、「クラスに向かってではなく、インターフェースに向かってプログラミングしろ」ってことです。

> interface に対してロジックを記述するようなプログラミングしてたら、ポリモルフィズムは当たり前すぎて特に意識してないと思います。

そういうことです。
ポリモーフィズムが特別なように言うのは、典型的なオブジェクト指向わかってない人ですね。

>> 何かうさんくさいものを直感し近づかないこと、それが長期にわたってシステム業務を行なうノウハウだと思ってます。また偉そうなおやじですいません。

それがノウハウですか？
自分が理解できないものは間違ってる、ということでしょうか？

＞ Perfumeがポリリズムという曲をリリースしたころですか？？？　なんか言葉が似ているから若者の間で浸透したんじゃないの？？

100%違うと断言します。ギャグなら面白いことを言ってください。

＞ 私はピンフ、タンヤオの安上がりでも、とにかく仕事をこなしていかなければならない身なのです。

ポリモーフィズムはピンフ、タンヤオでさえなくエンジニアとして一般常識の範囲です。SQLがわからないとか正規表現がわからないのと同じに聞こえます。麻雀で遊ぶヒマはあってもポリモーフィズムを覚えるヒマはないのでしょうか？

＞ 証券業務のビジネスオブジェクトの研究？？？をしていた方がいましたが、はっきりいってうさんくさかったです。今は何をしているでしょうか？何かうさんくさいものを直感し近づかないこと、それが長期にわたってシステム業務を行なうノウハウだと思ってます。また偉そうなおやじですいません。

胡散臭さに具体性がなくてよくわかりません。オブジェクト指向が胡散臭い？人が胡散臭い？

その態度だけは全面的に否定します。オブジェクト指向が理解できないのはいい。業務でクラスを使わなくてもいい。プログラムをメシの種と割り切ってもいい。誰かに頭を下げて教えを乞うのなら素晴らしいとさえ思う。謙虚な気持ちでさえいてくれれば。

だけど、ベテラン面で単なる勉強不足を目立つ場所で勘違いの自慢と勘違いの推奨をされるのは迷惑です。どうみても初心者レベルを理解されていないじゃないですか。

flatlineさん

>ポリモーフィズムですね。
>一生に一度どころか、ごくごく普通に使ってますが何か？
>使い古された言葉ですが、「クラスに向かってではなく、インターフェースに向かってプログラミングしろ」ってことです。

ですよね。まったくもってそのとおりですよ。
この愚かな人たちに、
業務アプリケーションのビジネスロジックを、インタフェースとそれを継承する複数のクラスで構成するの例
を示してやってください。

DBに登録するなら、条件分岐もなにも、SQLで計算させて答えも登録すりゃいいだけじゃん。
ムチャクチャだよこの人。

なによりも、不真面目なコメントは社会人としての常識を疑います。

ご退場を願いたいです。

>DBに登録するなら、条件分岐もなにも、SQLで計算させて答えも登録すりゃいいだけじゃん。

だから、オブジェクト指向プログラミングは実践では使えない。データベースを活用したほうが何万件の処理を高速に実行できるという意味でスケーラビリティが全然違うのです。

俺のコラムだから@ITから勧告がこない限り、退場しないよ。

ryo様、ぬ様

ケーブルTVの契約をしているもんで、毎晩アニマックスで「ヒカルの碁」を見ています。囲碁のルールはわたしは知りませんが、藤原差偽と塔谷名人のネット碁対決は「神の一手」が見たいがために、世界中の囲碁ファンがインターネットに釘付けになりました。タダで「神の一手」を見るのは甘いというのが御両人の結論でしたが・・・

だからわかってないんだ。スケーラビリティや実行速度が気になるなら分散オブジェクトとか他にも選択枝がいっぱいあるじゃないか。だから、例文は例文のためにシンプルにしているだけだって。その例文をきちんと読み取れないから応用が想像できずに、自分の手持ちの技術に逃げてる。別に、技術から逃げることはそんなに悪いことではないと思いますが、逃げてることに自覚しない、向き合わないで否定していることがどうかと思います。

タダで見るとかいう以前に囲碁のルールを知らないと「神の一手」って理解できないでしょう？

問題です笑

AさんはユーザデータをDBからcsv形式で各課へ出力するページをASPで作らなければいけません。
このとき、DBからの取得データはどの課も一緒ですが、csvの出力を加工してほしいという要求がどの課もバラバラになるようです。

XX課はダブルクォーテーションはつけないでくれと言っています。
YY課はパスワードの項目は先頭３文字だけみせて後ろは見えないようにしてくれと言っています。
ZZ課は生年月日の項目はいらないと言っています。
この手の要求は今後も一万件ほどくるようです。

Aさんは追加要望にもソースの改修は最小で、同じような要求にはソースの改修は発生しないような設計にしたいと考えています。

ぬさん

色々振ってみたのですが、出てこないですね。え？オレに言えって？そんなずうずうしいこと・・・。

みながわさん

ネタの提供ありがとうございます。

レイト・バインディングの成功させると、三暗トイトイを上がるぐらいには、身近に出来るように努力精進してます。
ちょうどこの間も既存のクラスに、仮想関数を差し込んで、どや顔してました。

私ですが、『転職を繰り返しすぎて、業務知識が解らないので具体例が思いつかないOOオタクが、お遊びで書き込んだ』だけですので、これ以上は勘弁してほしいのですが、これだと中途半端感がありますので、コメントします。

まず、一般的な業務アプリには、DBがありそのデータを使うプログラムがあるでしょう。
これは、見方を変えると、
業務システム→1個のオブジェクト
DB→データメンバ
個々の業務アプリ→メソッド
と取れます。
なので、みながわさんの『DBを使えばOOPは要らない』とか、ぬさんの『業務ロジックにはOOPが使われていなかった』とかはあながち外れたことではないと思われます。
OOPは、データと処理が融合して初めて意味がありますので、データをDBに取られたらOOPの出番は少なくなります。

あと、繰り返しになりますが、オブジェクト指向と業務知識両方を理解している人が少ないことです。ここでは、OOPについて語る人はいても、業務知識でうんちくを語れる人が少ないですね。業務システムといば、どこでも
・販売管理システム
・在庫管理システム
・購買（資産管理）システム
・給与（人事）システム
・経理システム
・経営分析システム
ぐらいはあるでしょう。なくても言われれば想像はできるでしょう。
オブジェクト指向設計を行うなら、これらのシステムにあるオブジェクトを抽出して、それらをクラス分けして・・・となるでしょうか？
このような手順で作られたシステムが使い勝手のよいシステムとなるでしょうか？
残念ながら、工数やその他色々な理由で、販売管理システムや在庫管理システムは独自で開発してもその他のシステムはパッケージとなるのではないでしょうか？もちろんケースバイケースでしょうが、そうなるとオブジェクト指向のメリットが半減するでしょう。

繰り返になりますが、例えば@ITでも、複式帳簿についての記事が出ますが、複式帳簿とオブジェクト指向両方を理解している人はどのくらいいらっしゃるでしょうか？
給与計算ってどうするの？って質問に即答できる人はどのくらいいらっしゃるでしょうか？（まぁそんなに難しくはないのですが・・・）
そのような訳でERPのようなパッケージが流行ったりするのでしょう。

ネガティブなことばかり言ってもユメがないし面白くないので、業務アプリの範囲で、私の経験でクラスについて思い出しますと、ECサイトになりますが、買い物かごのクラスは作ったことがあります。
買い物ってテンポラリな情報なので、当時、DBに入れるには気が引けたので、オブジェクトにしてセッション変数で保持させました。ECサイトは色々な場所で、料金計算を行わなければなりませんが、料金計算って一歩間違うと方々にコードが散在し、計算が合わないということになりかねませんが、それを防ぐためにきちんとクラスにして再利用を図るようにしました。
業務アプリって一度作るとあまり変更しないので、私も最近はあまり経験がないです。ので具体例については、私もそうそう出てこないですね。（今回は、神になれなかったか・・・まぁヒカルの碁はいまだに続きを待っているということで）

>だから、オブジェクト指向プログラミングは実践では使えない。データベースを活用したほうが何万件の処理を高速に実行できるという意味でスケーラビリティが全然違うのです。

真面目に言ってるんでしょうか？
いや、たぶん真面目に言ってるんでしょうけど。

実践では使えないって、何を根拠に？私の周囲や関係のあるエンジニアの間では、普通に使ってますが。あえて「オブジェクト指向」を意識することもなく、普通に使ってますが？
念のためですが、永続化にはデータベースを使ってますよ、もちろん。
業務ロジックを表現する上で、オブジェクト指向は普通に使ってますよ。

みながわさんがオブジェクト指向を使わないのは別に誰の迷惑になるわけでもないですが、@ITのような技術サイトで、「経験者」として「使えない」と公言されてしまうと、ちょうど新人がこの世界に入って右往左往する時期ということもあって、間違った情報を刷り込まれてしまう人がいるのではないかと心配です。

みながわさんはたぶんシステムの一部分しか作ったことが無いんじゃないですかね？
たとえば、関数の中だとかそういうフレームワークから呼ばれる部分。
フレームワーク自体は作ったことが無い。
　
フレームワーク自体を作らなくても、フレームワークにそってシステムを作れば
自然とオブジェクト指向を使うことになります。

みながわさんが作っているのは、そのシステムから呼び出される関数の部分だけ。
だからもし一人でシステム全体を作ろうとしたら作れないはずです。
全体に必要なのは、動作スピードではなく柔軟性や拡張性ですから
しっくりこないのは当たり前ですね。staticを使うことにより
柔軟性や拡張性が下がるということも認識して無いのでしょう。

みながわさんに言いたいのは、あなたが知らないところで
オブジェクト指向は広く使われているということです。
あなたが使っているDB等のライブラリの向こう側は
オブジェクト指向で構成されているのです。
その人の助けがあるから、あなたはまだ生きてられるのです。

DBとオブジェクト指向はそもそも別領域のものです
比較すること自体がナンセンス

ryoさん、こんにちは。

一銭の得にもならないにもかかわらず、「業務ロジックでのOOPの使用例が聞きたい！」という我が儘にも丁寧に付き合っていただき、ありがとうございます。
とても面白く拝読いたしました。
なるほど、DBとオブジェクト指向とはあまり繋がりが無さそうですが、しかしDBという補助線を一本引くことで、オブジェクト指向のイメージがぐっと掴みやすくなりますね。

>OOPは、データと処理が融合して初めて意味がありますので、データをDBに取られたらOOPの出番は少なくなります。

あえてここに私見を付け加えさせて頂くなら、
「データと処理が融合したモノを複数同時に作ればオブジェクト指向の特徴がより生きる」
という気がします。
データと処理をひとまとめにするだけなら、Ｃ言語で、ファイル内部で変数をstatic宣言して、そのファイル内だけに使用を限定するというのはよく行われます。しかし、それでは、データと処理が融合したモノをたった一つしか作れない。
一方、DBは型が揃ったデータを沢山扱えるが、あくまでデータだけであり、処理は処理で別の所に記述しなければならない。
OOPは、データと処理が融合したモノを必要に応じてたくさん作り出すことが出来る。やっぱり、インスタンスは沢山作ってこそ血湧き肉躍るというものです。(私だけか)

>ECサイトになりますが、買い物かごのクラスは作ったことがあります。

なるほど買い物かごですか。いろんな人がECサイト上で買い物をしている時、そのユーザ数分の買い物かごインスタンスが裏で働いており、品物を出したり入れたり、金額を計算して保持したりしているであろうというのは非常に分かりやすいイメージです。
ユーザが購入を決定した（あるいは決済が完了した）瞬間に、買い物かごインスタンスは、自らが保持している各種データをDBに引き渡して、それでお役御免となるのでしょうね。

なるほど。（こればっかりですみません）

ぬさん、こんにちは

私は最初、この記事を読んだ時に周りの皆様と同じく不快感をもったので、なぜぬさんが不快感を示されないのか良く分からなかったのですが、この記事はCOBOLの文化といいましょうか、昔から業務システム開発を経験された方たちにとってはきちんとした笑いになるのですね。

ちょっと1本取られた感があるので悔しいので返信しますと、

>データと処理をひとまとめにするだけなら、Ｃ言語で、ファイル内部で変数をstatic宣言して、そのファイル内だけに使用を限定するというのはよく行われます。

この考え方ですが、私はこれをモジュールと理解しています。wikiにも説明がありますね。
ちなみにですが、ファイルレベルのstatic変数は20年程前にバイト先で見たきりで、以降、私の周りでは使う人がいませんでした。最初に見た時は「上手い！」とおもって真似したのですが、その後マイノリティになったので、いつしかやめてました。
ただ、昔から業務システムを開発されている方は、当たり前のように使っていたのでしょうね。

単純にコードのまとまりを小さいものから大きなものへ見ていくと、

モジュールの考え方
コード→手続き（関数）→モジュール→プログラム

オブジェクト指向の考え方
コード→メソッド→オブジェクト→プログラム

と、なるのでモジュールを理解している方は、「オブジェクト指向ってなに？」ってなるのでしょう、だから

>>OOPは、データと処理が融合して初めて意味がありますので、データをDBに取られたらOOPの出番は少なくなります。

と書いてしまうと、『それってモジュールやん!』というツッコミが入るのですね。

>「データと処理が融合したモノを複数同時に作ればオブジェクト指向の特徴がより生きる」

と言わないと、昔堅気の開発者には伝わらないのでしょう。
（そう言いながら自分の年齢を言いますと今年で40になるのですが・・・）

という訳で元記事の『笑ってしまう』というのは、
『インスタンスを１つしか作らないのにオブジェクトとか言って悦に入ってる開発者をみると、笑ってしまう』というふうになるのかな？

逆に『今、私が書いているコードは、オブジェクトなのか？、モジュールなのか？』という確認は、開発者にとって必要なのかもしれませんね。

私ですが、時々無性に理屈をこねたくなるので、たまにお邪魔するのですが、いかんせん根が気ままなやつなのでいきなりこなくなることもあります。まぁまたどこかで見かけたらお声掛けくださいな。では、マジで、この辺で。

オブジェクト指向が世に出てたのが我々が若いころです。当時、研究所や米国の開発センターではC言語が主流でしたから、今後C言語にオブジェクト指向を取り入れたC++が新しい時代を築くと思いました。そして我々は年をとり、後輩や部下に自分は実践で使いこなせないくせにオブジェクト指向を勉強せよ！と皆で刷り込んできたわけです。

本コラムについては、若い世代だけでなく、私の世代からも多くの批判をいただきました。特に同世代の人のほうが数十年間信じてきたことを否定されるような印象をもたれるので不快な思いをさせると思います。

オブジェクト指向技術が今後応用されるひとつの道はWEBサービスによる分散オブジェクトを使った企業間取引だと思います。ポリフォーフィズムが理解できるかできないとかで人の知能レベルを試すようなことをして喜んでいる人は今後を担うエンジニアとしては失格です。

あと同世代の人にいえることは、古い開発環境では、何十個ものファイルにプログラムを書きMakefileでコンパイルしていましたが、Visual Studio は一元管理できるし、変数名や関数名の検索も簡単にできます。

私はイントラネットによるWEBアプリが予想もせず、こんなに受けるとは予想しませんでしたが、とにかくWEBはユーザーから好まれます。私のWEBアプリケーションの作り方の信条は、極力ページごとで独立したつくりにすることで、セッション変数は極力使わないです。その意味でpublic はなるべく使いません。WEBアプリこそページこそオブジェクト指向言語以上にの隠蔽性を重視するべきです。

以下のサイトはC#を勉強する上で大変お世話になったサイトです。static の意味はC言語の時代のstaticとは違います。クラス内で使うのです。ここが同年代の人が私の開発手法を誤解するところだと思います。

http://homepage3.nifty.com/midori_no_bike/CS/

// C# では、グローバル変数を、サポートしていない！
// 代替策として、static による「擬似」グローバル変数宣言を使う

// C# では、グローバル関数を、サポートしていない！
// 代替策として、static による「擬似」グローバル関数宣言を使う

ぬさん、ryoさん
(ryoさんはもう見てないかな？）

ryoさんがこれだけ煽っても、ryoさん以外に業務ロジックの具体例が出てこないということは、
やはり、説明できる人は少ないのでしょうね。

他でちょと疑問を呈してみても「使ってますよ」「やってますよ」の一言で終わったりするので、
結構胸がすく思いでした。

「オブジェクト指向を分かったリーダーのプロジェクトに参加してパラダイムシフトが体験できた」
などという経験談を見ると、「詳細を書いてくれよ」と思います。
多分こういう人は、オブジェクトを使って楽に開発できたけど、業務は分かってないか、
GUIやクライアント周りがオブジェクトだったのではないかなと思ったりします。
だから具体的な説明が出来ない。意外とこういう人が多いのではないでしょうか。

実際に業務ロジックを設計できる人は、
秘伝よろしく、口外できないのでしょう、自分の価値でもありますしね。

私はというと、JAVAは使わないからオブジェクト指向の技術者とは言えないけど、
フルにオブジェクト指向で構築された業務システムは参加した事がありません。
アプリケーションやビュー層ではオブジェクトだけど、
ロジックはストアドや生SQLの関数群だったりします。

パッケージはオブジェクト化された物が普通にありますが、
そのパッケージをカスタマイズする時などは、
ユーザーからパフォーマンスの問題を言われるたびに「SQLでやらせてくれよ」と思います。
（実際にパッケージを外れてストアドでカスタマイズする事もよくありますが。）

ですが、これこそがオブジェクト指向の肝なのでしょうか、
「実装」の隠蔽ですね。
ロジックを隠蔽してしまうことで、誰でもそこそこのレベルでプログラムが出来るということですね。
ですから、パッケージで普及して機能単位で切り分けて開発する事がまだ多い受注開発で普及しないのは自然かなと思います。

「オブジェクト指向で作っています」と思い込んでいるけど、
肝心の業務ロジックを書いているのは一部の人で、
実はオブジェクト(業務ロジックの)を使っているだけになってないか？と思います。
多分それでも、若い技術者は違和感はないでしょう。
GUIやフレームワークを作っても「オブジェクト指向で作っています」と思えるのでしょう。
でもロートルな私は、ビジネスロジックを作らないと、システムを作った気になれないのですよ。

最近は下流にいても、開発規模が小さくなって実装の自由が利くので、
VB6だろうとWSHだろうと、.NETだろうと、隠蔽できる実装はクラスで隠蔽します。
フレームワークも作りますし、VB6のインターフェイス継承も良く使いますね。
ただそれは、業務ロジックというよりは、IO周りとかGUI周りですね。
業務ロジックはパッケージ化されているか、ストアドか、生SQLが多いです。

以前、VB6の開発で、クラスを分かる技術者がいないからクラスは使わないでくれと言われた事はあるな。
もちろんそのときはクラスは使いませんよ、生きるためにね(笑

この人もこんなコラムを書いていたのですね。発見！

http://el.jibun.atmarkit.co.jp/hidemi/2009/12/sql-4274.html

＞AさんはユーザデータをDBからcsv形式で各課へ出力するページをASPで作らなければいけません。
＞このとき、DBからの取得データはどの課も一緒ですが、csvの出力を加工してほしいという要求がどの課もバラバラになるようです。
＞
＞XX課はダブルクォーテーションはつけないでくれと言っています。
＞YY課はパスワードの項目は先頭３文字だけみせて後ろは見えないようにしてくれと言っています。
＞ZZ課は生年月日の項目はいらないと言っています。
＞この手の要求は今後も一万件ほどくるようです。
＞
＞Aさんは追加要望にもソースの改修は最小で、同じような要求にはソースの改修は発生しないような設計にしたいと考えています。

なんか悲しいけど自分で考える。。
と、考えてみたらpublic staticでもよさそうな。問題失敗。。（ちょっとでも考えてくれた方すみません。）
加工に順番が出てくるとif文だらけになって耐えられないかもしれないけど。
結果失敗しましたが笑、何が言いたかったかというと

保守性は確実に高くなるってことです。
業務アプリならばログインはあるかと思います。
ログイン後にユーザの役職で処理を分けることを考えると・・・
みながわさんの考え方でいくと、至る所で「もしこの役職なら」という処理が入り込んでくるかと思います。
これをログイン直後に「役職」オブジェクトを作成したとすると、
役職ごとにその後実行するべき処理をログインの直後に決定することができます。
これならば役職ごとの処理は増やし放題です笑。

いままで「ここは影響が大きいからできない」「そういう作りになっていない」など誤魔化してきたことはないですか？
そういうのは実はきちんと設計していれば簡単なことだったかもしれないですよ？

これは好みかもしれませんが、１画面に詰め込むUIは新規ユーザにとって難度が高いかと思います。
新規ユーザの視点でのものづくりも大切かと思います。
１画面にすることで値の管理が開発者として楽なだけです。

あと、セッションは確かにpublicですがその中をクラスにすればIOはどちらかに傾けれますよ。

＞WEBアプリこそページこそオブジェクト指向言語以上にの隠蔽性を重視するべきです。
※なんかCookieの中の値を盗まれるからダメみたいな言い方だけど気のせい？

＞WEBアプリこそページこそオブジェクト指向言語以上にの隠蔽性を重視するべきです。

隠蔽性というよりは独立性といった方が適切ですね。ASP.NETでは　

　partial class　クラス名　：System.Web.UI.Page

というクラスの中にページの処理を記述することになります。「役職」については権限管理ということですね。それを私がどう簡単にやっているかご想像にお任せします。

>いままで「ここは影響が大きいからできない」「そういう作りになっていない」な>ど誤魔化してきたことはないですか？
>そういうのは実はきちんと設計していれば簡単なことだったかもしれないですよ？

あります。転職してしまった人が作った、継承も使っていないクラスで、やたらにインスタンス生成しているプログラム（しかもインスタンス名はすべて同じ）を引き継いだとき。.NET FRAME WORK1.1しかもサードパーティコンポーネントを使っているものだから、簡単にバージョンアップできなくて困ってます。自分が最初から設計していれば、これよりはるかにエレガントなプログラムになっていたはず。

私が何言っても説得性がないので、またリンク張ります。
http://mag.autumn.org/Content.modf?id=20041027180339

横槍失礼
>ポリフォーフィズムが理解できるかできないとかで人の知能レベルを試すような
>ことをして喜んでいる人は今後を担うエンジニアとしては失格です。

ポリモーフィズム(Polymorphism)です。
1回指摘されているので、ただの打ち間違いだと思いますが、念のため。

＞「役職」については権限管理ということですね。それを私がどう簡単にやっているかご想像にお任せします。
ASP.NETのロール設定ですか？
だとしたらちょっと言いたいことと違います。

太郎様　

　ご指摘ありがとうございます。仕事上のことでプログラミング以外にもいろいろ問題があるもので、つい打ち間違えしてしまいました。
　他の読書にも謝罪します m(_ _)

misa様

　権限管理をどうしたらいいのか？それは多くの企業のIS部門の課題ですのでマル秘事項です。一切公開できないので、それをご理解ください。

＞AさんはユーザデータをDBからcsv形式で各課へ出力するページをASPで作らなければいけません。
＞このとき、DBからの取得データはどの課も一緒ですが、csvの出力を加工してほしいという要求がどの課もバラバラになるようです。
＞
＞XX課はダブルクォーテーションはつけないでくれと言っています。
＞YY課はパスワードの項目は先頭３文字だけみせて後ろは見えないようにしてくれと言っています。
＞ZZ課は生年月日の項目はいらないと言っています。
＞この手の要求は今後も一万件ほどくるようです。
＞
＞Aさんは追加要望にもソースの改修は最小で、同じような要求にはソースの改修は発生しないような設計にしたいと考えています。

これこそ「神の一手」だと思いました。とても具体的な業務ロジックに見えますが、具体例を出せとか言う前に誰もまともに答えていないじゃないですか。

みながわさん、他みなさまおじゃまします。
さんざんコメントがついてますが、思うところありますのでコメントします。

みながわさんには、失礼とは思いますが、オブジェクト指向の理解が足りなさすぎます。私が一番感じるのは、クラスとインスタンスを混同されていないかと言うことです。

＞継承も使っていないクラスで、やたらにインスタンス生成しているプログラム（しかもインスタンス名はすべて同じ）

インスタンス名がすべて同じとはどういう意味かさっぱりわかりません。

本当はトラックバックとしたかったのですが、トラックバック用URLを探しきれませんでいたので、コメント+リンクとさせていただきます。トラックバックということもあり、若干あおり気味の文章となっていますが、あえてそのままにさせてもらいます。

すでに書いたことですが、オブジェクト指向を十分に使い倒した上で、少なくとも十分に理解した上で、それでもなお利点を見出せないというのであれば、その意見は傾聴に値すると思います。

しかし、他の方も指摘されているように、みながわさんはオブジェクト指向についての理解がかなり不足しているのではないでしょうか。はっきりいえば、オブジェクト指向を論評する資格がないのではと思います。

いっそ、具体的に簡単なソースを提示してみて、「ここはこう記述することによって、オブジェクト指向なんか使うよりずっと簡潔に記述できて、変更にも柔軟になっているんだ」と証明してみてはいかがでしょう？

evergreenさん、ぬさん、ryoさん、こんにちは。
業務システム（会計・税務パッケージ）の、主にビジネスロジック部分の設計・実装を担当している者としてコメントいたします。

作成した機能は多岐に渡るので、今回は税金計算処理に絞ってコメントいたします。
税金計算処理はビジネスロジックの塊であるので、例としては適切ではないかと。

税金計算処理の特徴は、次の通り。
・帳票は複数枚で構成され、互いに連携している（帳票Bの合計値を、帳票Aに転記するなどのケースが多発）
・項目の計算順序は、法令で規定されている

おおまかなクラス分けは、次の通り。
・DB操作クラス(DAO)
・設定値、計算値保存クラス(DTO)
・計算処理クラス
・UI層との窓口クラス

おおまかな処理の流れは、次の通り（初期化に絞ります）。
1.UI層によって、「UI層との窓口クラス」のインスタンスが生成される。
2.「UI層との窓口クラス」によって、「DB操作クラス」「設定値、計算値保存クラス」「計算処理クラス」のインスタンスが生成される。
3.「UI層との窓口クラス」が、「DB操作クラス」に対してDBから設定値の読み取りを依頼し、「設定値、計算値保存クラス」に保存される。
4.「UI層との窓口クラス」が、「計算処理クラス」に対して計算を依頼する。パラメータとして「設定値、計算値保存クラス」を与えると、税金計算された結果が保存される。
5.UI層に設定値、計算値を返却する。

設計上のポイントは、次の通り。
・「計算処理クラス」は、自動テスト実現のため、一時変数以外のインスタンスを持たせない
・「計算処理クラス」は、フレームワーク部分（1つ）と各項目ごとの計算処理（多数）で構成する
・各項目ごとの計算処理のハンドリングにはFactoryMethodパターン、Commandパターンを適用する
・「設定値、計算値保存クラス」は、単なる値の入れ物として機能させる

ざっと挙げると、このようになります。

基本的に「データ中心アプローチ」を取っており、オブジェクト指向技術は実現手段として用いている感じですね。
å
オブジェクト指向技術を使っていて便利だなと感じることは、
・カプセル化によるデータとロジックの分割統治
・カプセル化によるリソース解放の簡便化
・ポリモフィズムによるフレームワークの簡便化
・ポリモフィズムによる自動テストの試験性向上（モック）
これらに魅力を感じていますし、実際、生産性も向上しています。
今更C言語だけの世界には戻りたくはないのが正直なところです。

ここのコラムばっかりにコメントしないで、誰か他のコラムで

「継承をうまくつかったり、オーバーライドを使ったり、ポリモーフィズムを使ったりするとバグのないプログラムが書けるんです」

なんて言ってくれないのかなあ・・・

ふざけているわけではなくオブジェクト指向言語はデバックという面で優位性があるかという問題です。

とりすけさん。
大変分かりやすい解説をありがとうございます。

ただ、私もパッケージでは業務ロジックをOOPで実装している例は存じております。
おそらくryoさんもぬさんも同様かと思います。
受注開発の業務ロジック部分の実例をあまり見る事ができないという事だと思っております。
残念ながら自分に経験がないので、他の方のご経験を伺いたいと常から思っております。

ぴぐもんさん
これは業務というよりは、IOにあたるのかと思いました。
ぴぐもんさんに、会計や販売管理や在庫管理や生産管理や、
そういった業務の「コア」をOOPで実装された経験があれば、
ぜひご教授いただきたいです。

蛇足ながら付け加えさせていただきます。
パッケージ開発はいわば「先行投資」ですよね。
仕様は自社で決められ、カスタマイズその他の後から発生する条件や、
開発スタッフがある程度予測できる事など、OOPを導入する環境があると思います。

しかし受注開発は、
要件定義はまだしも、詳細設計・開発はそのフェーズにならないと、
要員のアサインも確定していない事もあると思います。
開発フェーズでの仕様変更も頻繁に(?)発生すると思います。
また機能単位での開発の分割もよくあることだと思います。
ですから、UIやフレームワークはOOPで実装されていても、
コアなロジックは生SQLやストアドで実装されてしますのかなと思っています。

TDaさん　こんばんは

明日から連休ですか？
インスタンス名は何でもいいんじゃないですか？　

だからインスタンス名はみんな同じということはありえる。そんな場合はインスタンス名はなくたっていい。

だから私の最初のコラムのとおりstatic関数にしたほうが、いちいちインスタンス生成しなくてもいい、ってことです。おわかりになりましたでしょうか？もう飲んでますか？

どうも、あすから連休なので、夜更かしモードです。

ちょっと、長文のものになりましたので以下に書かせてもらいました。
http://d.hatena.ne.jp/Einherjar/20100430/p1

一言で言えば「インスタンスに自身の手続きと状態を持たせることができることが、オブジェクト指向の利点です。」

>だからインスタンス名はみんな同じということはありえる。そんな場合はインスタンス名はなくたっていい。

→みながわさんのインスタンス名とは何を指しているかさっぱりわかりません。インスタンスに名前など無いです。「名前付きメモリ領域」という意味ならば、識別子はユニークで無ければならないですから、同じ名にはなりません。インスタンスを指すポインタという意味ならば、1つのポインタが複数のインスタンスを指すことはあり得ないですから、、？

たぶん同じ言葉を違う意味、違うレイヤーで表現してすれ違っていると思います。

>static関数にしたほうが、いちいちインスタンス生成しなくてもいい
→ステートレスの処理ならば、sクラスメソッドにすればよいと思います。
あるいはクラス自身が持つ状態ならば、クラスフィールドにすればよいでしょう。

長くなってしまいました。ポインタだけ張って、エントリ起こせばよかった。

私の中では今回は、4/27 16：34の冒頭のネタでもうこのトピックスに対する興味は無くなったのですが・・・みなさんまだ騒ぎ足りないみたいですね。
元々、staticを覚えたてのおじちゃんがうれしがって書いた冗談みたいな記事だったので私も適当に、ただ罵倒するのではなく、押さえるところは押さえながら理屈をこねただけなので、もう引き出しが無いのですが、呼ばれましたので返信します。

とりすけさん

大変貴重な情報ありがとうございます。本当に参考になりました。もっと詳しく聞きたい面もあるのですが、ここではOOPの業務アプリの適用実績の例が聞けただけでOKです。
私の振りで想像がつくかと思いますが、私は多少ではありますが経理や法人税の知識があります。ので、ネットではありますが、とりすけさんの話には真実味を感じています。

私が業務アプリ（先のECサイト）を作ったのが8年前です。そこ頃は、ぬさんや、evergreenさんと同様に、ビジネスロジックは非OOP（というかSQL）で作っていました。それでも、一部ではOOPを適用していたので、今だともう少し進んでいるのではと思った次第です。ちなみにパッケージの使用経験はありますが、純粋に一ユーザとして使用しているだけですので、経理系のソフトがOOPで作られている実例は知りませんでした。

evergreenさん

ついついつられて出てきました。ちなみに4/29 7:52のコメントは私に対するものだと思ってましたが、みながわさんが返信したのでそのままスルーしました。

どうやら私とそんなに歳が離れていなさそうですが、なかなかの過激な発言ですね。結構楽しませてもらっていたのですが、ただ、4/30のみながわさんのコメントを読む限りこれ以上の進展は期待できなさそうです。私としてはとりすけさんのコメントで充分だと思います。なぜならとりすけさんのような方が企業に入って業務システムを作るようになると自然とそこにはOOPで作られた基幹システムが出来るでしょう。先のことは解りませんが、OOPの基幹システムというのも、もうユメ物語ではないのではと思われます。もちろん現時点ではエセOO論者もいますが、少なくともここに集まって来ている方たちは純粋に技術に素直な人だと思いますよ。（まぁもっともオレのネタにもっと反応してほしい面もあるのだが・・・）。

ついでに

ぴぐもんさん

散々無視されながらお疲れ様です。misaさんの問題ですが『この手の要求は今後も一万件ほどくるようです。』に引っかかって現実味がなかったので、面白くなかったのでスルーしました。業務システムの実例というのは元々ぬさんの要望でしたが、私はこの問題をOOPで解いても面白いと思います。せっかくなのでぴぐもんさんが解いてみては如何でしょうか？
もっとも、ここではこれ以上話を膨らませるのはもうやめた方がよさそうですね。なによりみながわさん自体ももう疲れてきてますので、

みながわさん

あらためて、ご自身の発言を検証されては如何でしょうか？、元記事と私への初回の返信（4/23 16：54）ですが、今でも意見は変わりませんか？
コラムのタイトルにある『システムエンジニアとして長期に活躍した経験に基づく極意、ノウハウを教えます』にのとっているかどうか確認してみてください。
若い人や経験者からも批判を受けているという事実には真摯に受け止める必要があります。腹が立つかもしれませんが、ここまで批判されるというのはやはり誤解を与えるような記事だったと気づくべきでしょう。
初期の発言と今では大分意見も変わっているでしょう。ただ、4/30のコメント全体的に言えることですが、残念ながら何が言いたいのかやはり私には解りません。行間を読むのは、もう面倒なのであえて個々の発言には触れません。私を釣っているのでしょうが、もうのりません。

もちろん今回のこのやり取りで私にも発見がありました（この元記事の笑いのセンスは解りました）。
みながわさんも私の文章を読んで、文章の書き方ややり取りの仕方について参考になったところがあるでしょう。
それらを加味してこれからもコラムの執筆活動に励んで下さい。

では、再三言っておりますが、私はこの辺で

＞ これは業務というよりは、IOにあたるのかと思いました。

出力を請求金額の計算に置き換えてみたらどうでしょうか？

＞ 会計や販売管理や在庫管理や生産管理や、そういった業務の「コア」をOOPで実装された経験があれば、

言える範囲で、

ユーザ管理でもシステムに対する権限ではなくて、一般会員と有料会員の違い
鮮度や状態がシビアで商品価値に直結する
営業担当者や取引先ごとに独自の値引率や取引手続きを持っている

>ryoさん

大人ですね。

ちなみにご指摘の発言は、みながわさんの「2010年4月28日 (水) 08:53」に対してです。
ryoさんに対してではありません。

当初の私の発言に対するみながわさんの返答に呆れるあまり、ここまで来てしまいましたが、
他の方の発言にはあまり興味がありませんでした。
もうそろそろ引き上げようかと思っていたところ、
あらためて「ぬ」さんとryoさんのコメント拝見して、
我が意を得たりというところがありましたので、
ぬさんとryoさん向けてコメントさせていただきました。

あらためて、貴重なご経験をご披露いただきありがとうございました。

>とりすけさん
先ほどの私のコメントですと、ご不快に思われるかもしれませんね。
ryoさんコメントを拝見して反省した次第です。
貴重な経験をご披露いただきありがとうございます。
コメントは保存させていただておりますので、
自分でも消化できるよう参考にさせていただきます。

>ぴぐもんさん
請求額の計算が一万通りあるいうのはあまり考えられないような・・・
それに、上記も例としてあげていただいたような事も、
なんらかの「しきいち値」を持つ事でOOP以外で実現してきておりますから、
OOPでの実装がさっとは思いつきませんね。
まあ、守秘義務がありますからね、実装やクラスは書けないでしょうね。
自分で考える事にします。

なんだか私も軽い気持ちが深入りしてしまいました。
私も失礼しようかと思います。

最後にみながわさん。
どうも始めから行き違ってしまいましたが、
私も最後まで言いたい事が分かりませんでした。

一つ一つは挙げませんが、コメントで言っていることも、
随分揺れているように感じます。

ただ言いたいことを言えばいいという事ならそれでもいいですが、
誰かに何かを伝えたいということであれば、もう少しお考えになった方がよろしいようです。

それでは失礼します。

あまり恥ずかしい記事をwebに書くと後々まで残りますからね。
注意しましょう。あはは。

当初のコラム通り、今現在、Visual Studio を使い　ASP.NET　C#　の開発を行なっている。多くのコメントをいろいろな方から頂いたが、C#やWEBアプリの開発を行なっている方はほとんどいない。C#をやっていると断言している方はいらっしゃらない。むしろわたしがC言語でプログラムを書いていたことにつっこみを入れるかたばかりだ。若いかたからの批判ではなくベテランの方からの批判のように思える。

２０代の若いかたのC#によるWEBアプリケーションの例は以下のようである。

ページ１でクラスAによりインスタンスXの生成を行なう。
　　　　　クラスAのメンバー関数F1を実行する。
ページ１の終了時にインスタンスXのメモリ開放をDisposeによって行なう。

ページ２でクラスAによりインスタンスXの生成を行なう。
　　　　　クラスAのメンバー関数F2を実行する。
ページ２の終了時にインスタンスXのメモリ開放をDisposeによって行なう。

インスタンス生成がメモリ領域の確保だとすると、この方式ならば当然同じインスタンスを何回も生成することになる。別にこのようなプログラムを書いたかたを軽蔑するわけではない。.NETが世に出始めのころに、実際の業務開発において何十ページのWEBアプリケーションを開発するために、そのような技法を自分で考えたのだろう。

C#では文字列を以下のメンバー関数的な記法で整数型に変換することができる。
int i = int.Parse("123");
さらにint は　Int32 という .NET FRAMEWORK のクラスと同じものなのです。

ですから最初の私のコラムのニュアンスはASP.NET　C#　を知っているかたはなんとなく伝わってくるはずなのです。C、C++、C#　はベテランの型は似たようなものだと思っている発言が多いようですが微妙に違うのですよ。

evergreenさん
「もうおまえのコラムには来ない」と言ったのに結局何回も来ることになりましたね。私とevergreenさんはデータベース指向という点で、経験したことや考えかたは近いと感じます。

1万件は最初のほうのコメントからきているのだと思います。1万件を30件ぐらいにすれば。正直、それはどうでもいい部分だと思っていました。

OOP以外でも実装はできるのはわかります。そう言われるだろうと思っていましたので。実際、企業文化とか政治もあるし。OOPと非OOPの変なミゾがわかるかと思って期待してつい深入りしてしまいました。いろいろと無礼な言い方をしてきたことはお詫びいたします。

＞みながわさん
私も最後まで主張されていることが理解できませんでした。やはり、こういう場所で書かれている以上、文章も含めてそれなりのものを期待したいです。

それでは私も失礼しようかと思います。
よい連休を。

一言だけ追加。C#でWebアプリやってます。

evergreenさん、ryoさん、コメントありがとうございます。

私自身はパッケージベンダーに所属しており、受託開発の経験はありません。
その観点でのコメントはできませんので、ご容赦ください。

ryoさんは法人税の知識があるそうなので認識を合わせやすいのですが、税金関連の処理は長大で複雑な計算ロジックの塊なので、SQLだけで何とかするのは、ほぼ不可能です。
余談ですが、不定型なデータの構造上、RDBよりXMLDBの方がフィットするかと思います。

計算ロジックはコードで実装することになります。
分岐だけで構成するような造りにすると、見通しが悪い上に、恐ろしく保守性が悪いです。
むしろ、作っている途中で破綻してしまい、方針変換を迫られることになりそうです。

そこで、項目単位にコマンドを定義して、計算順番テーブルに従って順番にコマンド実行→項目ごとの計算を行うシステムを作成しました。
先の私のコメントは、このシステムのことを指します。

私自身は開発環境をWindowsに移行したときからOOPを使い始めましたが（処理系はC++）、空気のように自然に使えるようになるまで、それなりの時間と経験を要しました。
その過程で学んだことは、読みやすく、保守しやすく、テストしやすい設計・実装にするために、OOPなどの技法を適用するアプローチの方が、品質向上を図れました。

最後にみやがわさんに一言。
貴方の現状は「勉強不足」に尽きます。もっと勉強してからコラムやコメントを書いてください。

一晩明けてふたたびおじゃまします。

>インスタンス生成がメモリ領域の確保だとすると、この方式ならば当然同じインスタンスを何回も生成することになる。

まさかと思ってましたが、やはりそういうことですか。
1,2ページのインスタンスXは当然「別物」です。たまたま同じ領域を指すことがあるかもしれませんが、概念として「別物」です。非OOPで同様の話をします。

-------------------------------------------------------------
関数funcは内部で自動変数int x;を使用します。ページ1、ページ2でそれぞれ関数funcを呼び出します。それぞれのページでfuncを呼び出す度に、xの領域が確保されますが、これは「別物」です。

今xを自動変数としましたが、例えばintではなく非常に大きなサイズのバッファだった場合、静的変数とする場合はあり得るでしょう。その場合、関数がリエントラントになりません。ページ1、2が同時に呼ばれない、そして将来にわたって、funcが同時に実行されることはないのであれば、それでもよいでしょう。それぞれにメリットデメリットがあるので、それを考慮して設計するはずです。しかし、他の要素が無ければ普通は自動変数にするでしょう。
-------------------------------------------------------------

newはそれなりにコストがかかるので、使い回しが可能なら静的にしてしまう、という考え方は間違いではないです。しかし静的にしてしまうと、「本当に同じインスタンス」になりますから、状態管理に非常に神経を使うことになります。

OOPはヒープにドカドカと、インスタンスを生成していくので、パフォーマンスが悪くなるのは否めません。また、データと処理、インターフェイスを分離するために、層がいくつも重なることになり、それもパフォーマンス低下につながります。
その代わりに柔軟な設計と再利用のしやすさを得ています。

私は言葉遊びをするつもりもないです。しかし用語の混同が、理解の妨げになっている気がしてなりません。
ついでに言いますと、私はC,C#,JAVA,VB,perl,php,Ruby,Pasal(Delphi)などをかじっています。業務経験に絞れば、C,C#,PHP,perlということになります。(業務外で身につけた物のほうが多いのですが、こだわる人もいますから念のため宣言しておきます)

>ふざけているわけではなくオブジェクト指向言語はデバックという面で優位性があるかという問題です。

本気で言っているのだとしたら相当に無知ですねぇ。

ちなみに私は10年ほどJavaでWebアプリを開発してきました。C#でのWebアプリはやっていないですがぼちぼち仕事でも使い初めています。

そんな経験とみながわさんの発言から想像するに、みながわさんが作成されたWebアプリはセキュリティホールが大量にありそうだなぁ、と感じています。イントラネット用でよかったですね。

>>あ
多分、セキュリティーホールはあまりないと思いますよ。なぜなら、作業内容的にはbatch系だと思うから。

>>みながわさん
この本の購入をお勧めします。
「Head Firstオブジェクト指向分析設計――頭とからだで覚えるオブジェクト指向の基本」
オブジェクト指向は変更が多い分野で力を発揮します。システム開発での天敵は変更です(仕様や用件定義を含む)。データと実装を分けていれば、変更は楽です。特にWebは変更が多い分野です。如何に楽をするかが仕事内容です(苦労する方法を考える奴はただの馬鹿)。一分一秒でも楽をすることを考えないと死にたくなります。

多分、みながわさんの疑問点は上記の本に書いてありますよ。

ひまひま様　わざわざ休日にコメントありがとうございます。

ほんとに楽になりたいですよね。

私はデータベースを活用してます。コメントをいただいた何名のかたはC#を使っているそうですが、DataSet DataTable テーブルオブジェクトとかDataTableからGridView（表）へのバインドなどのテクニックを使っているのでしょうか？どのようなSQL文を書くか決まれば、もう内部設計が終わったようなものです。

このテクニックを知ってしまえば、楽～～～になれます。またGridView（表）にはテンプレート列というものを定義できるので、特殊な表示にして欲しいなどの、仕様変更が簡単にできるのですよ！

新規登録画面と変更画面などはほとんど同じようなレイアウトなので、コピペ使っちゃいます。テキストボックスのIDが変更画面と新規登録画面で統一できるのでバグが少なくなりますよ！

とっても不思議なんだけどさ、みながわさん、staticドカドカ使ってWebシステム作ってるらしいけど、今まで問題起きなかったんかね？
たとえば、ログイン情報をstaticにしちゃったらまずいことは、普通の技術者ならわかることだよね？
100人がログインしたら100個のインスタンスができるじゃん。みながわさんに言わせると、それも「笑ってしまう」ことなのかねえ？

もうひとつ「Visual Studioで供給しているSQL関係のクラスを使えばできてしまう」ってマジメにいってる？自分でクラス定義とかしたことないわけ？だとするとサンデープログラマに毛が生えたようなレベルでしかないよね。

まあみながわさんがオブジェクト指向を全く理解せずに吹いてるのは、コラム読めばわかるんだけどさ。自分に都合の悪いコメントは丸無視して、データベース指向だとかどうでもいい話でごまかしてるのはどうよ？

少なくとも自分がオブジェクト指向に無知だってことは認めたらどうかな？
楽になるよ。

みながわさん

お返事ありがとうございます。
なるほど、上流工程の方なんですね。ある程度分かっているんですね。
では、仕様上SQLを使えないケースで変更が多かったらどうでしょうか。
以下実際に関わった案件です。

案件でBatch系があります。ちなみに新規開発です。
.datファイルで所定の場所に数値や文字列などのDBの中身が出力されます。
そしてそれらをPDFファイルに出力します。SQLは使えず、新規なので変更が多いです。このケースだと、レイアウト部とデータ部とファイル系を分けないとテストできません。
全部一緒の箇所に記述されると、明らかにテストケースが少なくなり、納品の不備を指摘されてしまいます(最近は第三者チェックは銀行だけでなく一般システム(会計や安いWebシステム)でもあります)。

上記は一例ではありますが、実際にありました。他にもWebなら配備記述子(web.xml)やXml系(AJAXを含む)やExcel系等の別ファイルを読み込んで編集し、出力することは良くあります。その場合、実装とデータ部を分けてないと、仕様変更に対応できません。ですから、オブジェクト指向を覚えておくと便利ですよ。

みながわさん

もうちょっと、テクニカルなケースを書きます。
何でもStaticにするのは止めたほうが良いです。static変数はインスタンス変数を初期化するケースのみでお願いします。
static変数はクラス自体の変数です。共有変数と言う事は、マルチスレッドだと同時アクセスされる箇所です。同時にマルチスレッドからアクセスされるとstatic変数では動きません。
以下はNTT関係者の記事ですが、分かっているのでしたら、わざわざ止めろと言われている事をやる必要はないですから。

http://www.atmarkit.co.jp/fjava/rensai2/webopt04/webopt04.html

ひまひまさん　こんばんは

実際にWEBアプリでは、グローバル変数でページ間のデータの受け渡しは禁則なので、ページ間の受け渡しは推奨された方法で行ないます。何通りか方法がありますが、どれを使っているのかご想像におまかせします。WEBアプリを作ったことのあるかたはご存知の方法です。ですから必然的にstatic public で定義された変数はサーバー名とかデータベース名とか初期化パラメータとしてしか意味がないものになります。一度レガシーASPでsession変数で定義すべきところをapplication変数で定義し痛い目にあってます。

　static変数ではなくstatic関数はよく使います。引数のみから単純な論理でリターン値を返すものなので、他のセッションの影響は論理的に考えてないはずです。

（要するにWeｂアプリは複数のユーザーが同時に使うので、WEBサーバー上ではマルチスレッドの動作と同じになります。WEBアプリのセッションの意味はスレッドと同じ、だから常にそのようなセッション間の干渉がないような作りにする必要があります）

ASP.NETではXMLやEXCELにも対応したクラスがあるはずです。それ以外のいろいろなデータタイプに対応するためにはもちろんクラスを作らなければならないこともあるでしょう。それでも参照はDataTableオブジェクトにデータを入れればGridViewで見ることができると思います。

バッチの例題の例はコメント読んだだけでは仕様がはっきりイメージできないので今回答できないです。

AC/DCさん

ログイン情報ってDBが使えたらDBに追加すればいいだけじゃん。なんでインスタンスの話がでるの？？？何の言語使ってるの？意味不明

とりすけさん、こんにちは。

私は税金といえば年末調整の紙を見ただけで頭が痛くなるというサラリーマンなのですが、そんなことはどうでも良くて、とりすけさんの２回にわたるコメントから想像するに、

・帳票B計算用コマンドオブジェクト群を、所定の順序に従って実行する。
（その過程で、帳票Bの○○額や××額が順を追って決定していく)

・次に、帳票A計算用コマンドオブジェクト群を、所定の順序に従って実行する。
その過程で、帳票Bの××額を転記する必要があれば、さっきのB用オブジェクト群のうちの1つ（××額担当）が、その値を覚えているので、それを使う。

多分、こういうイメージですよね。なるほど・・・・
（違っていたら笑ってやって下さい)

>計算ロジックはコードで実装することになります。
>分岐だけで構成するような造りにすると、見通しが悪い上に、恐ろしく保守性が悪いです。
>むしろ、作っている途中で破綻してしまい、方針変換を迫られることになりそうです。

例えば所得税の計算でも、給与総額がどの範囲にあるか、控除はどれとどれとどれが当てはまるか、etc. など、if文の入れ子要塞が出来上がりそうですね。

>ログイン情報ってDBが使えたらDBに追加すればいいだけじゃん。なんでインスタンスの話がでるの？？？

なんか話が通じてないような気がするんだけど、わざとはぐらかしてるわけじゃないよね？

たとえば、minagawaというユーザがログインしたとするよね。
もちろん minagawaに関連付けられるユーザの氏名とかパスワードとかメルアドとかの属性はDBに永続化されてるよね、普通は。それはいいのよ。
訊きたいのは、minagawaというユーザがログインしたという情報を、どうやって持ってるの？ってこと。staticな変数？インスタンスな変数？

なんでこういう基本的なことを訊くかというと、みながわさんが他のコメントにあるstatic関係の質問をきれいにスルーしてるから、ひょっとしてstaticの意味をわかってないんじゃないかな、と思ったから。

これも無視されちゃうかなあ。だとしても驚かんけどね。

みながわさん

回答ありがとうございます。
まぁ、大抵はSessionかApplicationスコープもしくは、URLのパラメータにするかのどれかになると思います。
その使い方なら問題ないと思います。
駄文失礼しました。

>>AC/DC

俺もお前が言っていること分かんない。
例えば、ログインしたらトップページに行くかんじか。
それは、Session等で扱うことであってstatic変数は関係ない。

いいかい、Webはマルチスレッド(平行して複数の処理を行うこと)と呼ばれる状態が基本だ。そしてシステムが止まらない様にスレッドセーフ(並行処理を何千何万回短期間でアクセスしても落ちないこと)であることが基本。

ここでの問題は、Static変数を使うと値をなかなか破棄してくれないこと。.netやjavaは開発者が破棄を指定できないから、何時まで保存することになる。
当然、保存しているところから再利用するから処理は重くなる(なぜなら言語の内部で優先度を後ろに持って行くから(これは開発者が制御できない))。
単純なイメージなら、動画サイトを立ち上げて、他のWebサイトを見たとする。
再び立ち上げた動画サイトをクリックするとPCがフリーズする感じ。
だから、何にでもstaticを使うの辞めたほうが良いですよってこと。

ちゃんと理解せずに横槍なのですが
AC/DC さんの言ってるシステムは、例えばオンラインゲームのようにプロセス上に複数のユーザが同時に存在しサーバ側が一喝管理する類のものを想定してるのでは？
みながわさんの言うウェブアプリケーションとは根本的に別物だと思います。
ASP.net 使ったことないのですが、JSP みたいなものですかね？
そうすると static な変数にログイン情報を格納、という発想自体がありえないのではないかと。
AC/DC さんの 2010年5月 2日 (日) 00:57 の書き込みは、みながわさんの 2010年5月 2日 (日) 00:07 の発言を読まずに反応してるようにも見えます

>>みながわさん
開発の過程でデータ定義変更とかは起こりえないのですか？
最初からテーブル設計済みの DB を構築して、開発もテストもすべてその DB 上で通す感じでしょうか
設定ファイルで接続先 DB の入れ替え等はできるでしょうが、テストとかメンテナンスとか考えるとちょっとめんどそうだなあと思います。

なんとなく考え方が分かった気がします。

みながわさんのGridViewで楽になれる。という発言からちょっと調べてみました。
私はC#は使ってもVSでプログラムする機会はなかったので勉強になりました。
※いつもcscしてコンパイルしてます。

こんな感じかな？という連載をみつけました。
http://www.atmarkit.co.jp/fdotnet/vs2005db/index/index.html

上から見ていくうちにページ遷移はWizardコントロールを使えばセッションを意識しなくて良いだとか（意識的に取り出すものも当然あるでしょう）
完全に内部に隠蔽されたコントローラ群が揃っているようです。
しかし、このコントローラを自前のクラスに引数として渡すなどすると逆に面倒になるような気もします。

ということは、みながわさんはオブジェクト指向を知らず知らずのうちに使い倒してるということにならないでしょうか？
そして、ASP.NETとしては良い作法のようにも思えます。（staticばっかりとかストアド最強とかは置いておいて）

私の結論としては、MSは便利であるがゆえ危険も伴なうということですね。

AdobeのColdFusionに似てるのかも

ぬさん、コメントありがとうございます。

> ・帳票B計算用コマンドオブジェクト群を、所定の順序に従って実行する。
> （その過程で、帳票Bの○○額や××額が順を追って決定していく)
>
> ・次に、帳票A計算用コマンドオブジェクト群を、所定の順序に従って実行する。
> その過程で、帳票Bの××額を転記する必要があれば、さっきのB用オブジェクト群のうち
> の1つ（××額担当）が、その値を覚えているので、それを使う。

税金計算の場合、ある程度の帳票をグループとしてまとめて計算することが多いです。
従って、ぬさんのコメントを「帳票→グループ」と読み替えていただければOKです。

そして、計算用コマンドオブジェクトに、敢えて計算後の値を覚えさせない方針をとっています。
コマンドオブジェクトへのInput/Outputは「設定値、計算値保存クラス」にしてあり、値の転記はこのクラス（コンテナ）を使用します。
その目的は「自動テストを容易にする」ためです。項目ごとにUnitTestで、参照先の値を差し替えてテストすることが簡単だからです。

なお、私の考えの優先順序は、テストしやすいか？→データはどうなる？→オブジェクトはどうなる？、となっています。
純粋なOOPとは違う使い方をしているかもしれませんが、私が担当する会計・税務パッケージでは、このアプローチの方が品質を上げやすいと感じています。

>ということは、みながわさんはオブジェクト指向を知らず知らずのうちに使い倒してるということにならないでしょうか？
>私の結論としては、MSは便利であるがゆえ危険も伴なうということですね。

そのとおりだと思います。つまりこのコラムは生き残りの極意じゃなく、生き残っちゃった人の経験談、という感じですかね。

さらに問題なのは、OOPでがっちり設計されているクラスライブラリを使い倒しておきながら、それを作る側を否定している部分が反感を買っているのでしょう。人の力で生かされているのにそこに敬意が無いあたりとか。

みなさん、まだやってますね。

>AC/DC
>>ログイン情報ってDBが使えたらDBに追加すればいいだけじゃん。なんでインスタンスの話がでるの？？？
>なんか話が通じてないような気がするんだけど、わざとはぐらかしてるわけじゃないよね？

AC/DCさん、こんにちは。私も何回かやりとりしましたが、話が通じていないとしか思えないです。インスタンスって言葉をどういう意味で使っているのかさっぱりわかりません。

その前のみながわさんの発言で
>私は業務アプリで一万個のオブジェクトを扱う場合ならばデータベースを活用します。

これって、普通に読むといちいちオブジェクトをシリアライズしてDBにつっこむって読めます。意味がわかりません。DBにつっこんだ上で、ストアドで処理するならまだわからなくも無いですけど、そう読めません。

>misaさん
>みながわさんのGridViewで楽になれる。という発言からちょっと調べてみました。

あなたは此処の議論に参加しないほうがイイです。何が正しくて、何が間違っているか判断できていないようですから。みながわさんのスキルは、オブジェクト指向を理解していない程度ではありません。100歩譲って非オブジェクト指向プログラミングができているとしても(本人はそう思っているようです)、それを「普通の」エンジニアが使っている言葉で説明できない人です。

はっきりいってみながわさんが「GridViewで楽になれる」なんて言うのは、ちゃんちゃらおかしくて、まじめに取り合う気になりません。例えると、素人のおっさんが、イチロー本人に「いまのバッティングなかなかイイよ。その調子」とか言っちゃってる感じ。

reppivさん

本番用DBと開発用DBは別にしています。それはひまひまさんへの回答で、WEBアプリの開発では、実際には　static public 変数やコンスタントは　サーバー名、データベース名ぐらいしかないと書きました。開発中はVisual Studioを開いて、サーバー名、データベース名を変えることで対応しています。設定ファイルを作る方法もありますが、あまりデータベースの接続パスワードをテキストファイルで安易にみられるようなことが心配なんです。

misa 様

C#やるならばVSはぜひともお勧めです。「インスタンス.」と打っただけで右側に使えるメソッド関数がプルダウンメニューで自動的に現れます。

スクリプト言語のレガシーASPは予想外に便利なもので多くのユーザーの支持を受けました。include が使えるので接続サーバー、データベース、よく使う関数はincludeして業務アプリケーションを使ってました。レガシーASPを使い倒すとWEBアプリにおけるページ間の値の受け渡し方法なんかはよく知っているはずなんです。

逆にレガシーASPを知らないで、ASP.NETでWEBアプリを使うと、なんかWindowsアプリを強引にブラウザに表示しているようなものが出来上がってしまいます。

あと引用されているサイトではウィザードを使っていますが、私はたとえIS部門でさえもウィザードを使わずにコードで実装することを強くお勧めします。SqlDataAdaptor DataSet DataTable GridView　の使い方をパターンをマスターすれば、マウスクリックして選択するなんていう設定作業はめんどうに感じます。突然ユーザーからの改善要望に応じることができるのですよ。

ぬ様

おはようございます。パッケージベンダーの方がこのようなところで製品仕様に関する情報を公開していいの？？？特許は申請済みというとでしょうか？そのうち特許公報で詳しいことは見られるのでは？

reppivさん

JAVA系は詳しくないのですが、レガシーASPがJSPに似ていると思います。
レガシーASPはVBスクリプトとHTMLタグを組み合わせて動的HTMLを生成しています。
ASP.NETはコードビハインドという手法で、画面レイアウトとプログラムを分離して開発するのが基本です。最近のASP.NET MVC は違うという印象ですが、勉強不足のためわかりませんm(_ _)m

とりすけさん、こんにちは。

>そして、計算用コマンドオブジェクトに、敢えて計算後の値を覚えさせない方針をとっています。

ああ、良く見たらこれは最初のコメント

>とりすけ 2010年4月30日 (金) 21:57
>設計上のポイントは、次の通り。
>・「計算処理クラス」は、自動テスト実現のため、一時変数以外のインスタンスを持たせない

で、既に書かれていましたね。何度も説明させてしまい申し訳ありません。

>純粋なOOPとは違う使い方をしているかもしれませんが、私が担当する会計・税務パッケージでは、このアプローチの方が品質を上げやすいと感じています。

純粋なOOPとは違う使い方をしているかもしれませんが、純粋OOP的アプローチ（？）も含め様々な方式を検討し、メリット・デメリットについて熟慮を重ねた結果、紹介していただいたような方式に至ったというのは、文面から伝わってきます。一銭の得にもならないのに（なんかこんなことばかり言っているな）、ありがとうございます。

みながわさん、こんにちは。

>おはようございます。パッケージベンダーの方がこのようなところで製品仕様に関する情報を公開していいの？？？

どの程度まで公開して良いかについては、正直、私にはよく分からないので、取り敢えず何も考えずに質問してみて、この程度までなら話せる（または話せない）という判断はとりすけさんに委ねようと思いました。

その結果、いろいろ細かく説明して頂いて、とても面白かったのですが、とりすけさんの立場が何か悪くなったりしないか、微妙に心配にならないでもないですね（多分問題ないとは思うのですが・・・・）

TDaさん
私は結論として、オブジェクト指向がしっくりこないのは何故か？といことを論点としていました。
なので、あんなまとめです。
極論かもしれないけど、みながわさんみたいなSEに求められるのは、動作保証とか速度とか要求に対して柔軟か、あとはやっぱりお金ですよね。（でもMS製品で揃えるのはライセンス料がひどいことに。。。）
それを実現できているなら、最悪いいのかなと。

私ははじめにコメントした時、要求に対して誤魔化して自分の領域まで誘ってから実装を検討するような感じの印象だったので、これは良くないと思ってました。
私だけ論点と視点がずれていたのかもしれません。流れを崩してしまいすみません。

すみませんと言ったばかりですが、最後に、
みながわさんのコメント全てに言えることですが、ASP.NETとVSで開発していること限定で語られている気がします。なので抽象的な話がなかったり、実装方法に関してもこうすれば出来る。というような話だったりするのではないかと思います。

みながわさん
VSでの開発もどこまで出来るか。これをやると破錠するなど興味がでてきました。

これまで全て含めてですが、限定的な理解でなくてもっと広範囲をカバーするような理解があればここまでコメントが長くなることはなかったと思います。
今の環境が安定してきたのであれば、他のことにも関心を示して欲しいです。

なんかもう面倒くさくなってきたねえ。
そもそも、元のコラムのレベルが低すぎるのが問題なんだと思うけど。

みながわさんが「楽～～～になれます」とか「バグが少なくなりますよ」とか得意げに披露しているものは、ノウハウでも極意でもなんでもないよね。
知らないかもしれないけど、今どきのIDEなら(Eclipseとかね)、コードの自動補完機能なんか普通に備えてるんだけどね。それを自分が発見したかのように誇らしげに言われても失笑するしかないんだけど。
TDaさんのイチローの比喩がぴったり。

まあそれはともかく。

とりあえず、みながわさんにお願いしてもいいかな。

みながわさんが考えるところの「インスタンス」と「static」って何？
まず、そこから答えてもらえると、きっと多くの人の疑問が解消されるんじゃないかと思うんだよね。どうかな？

TDaさん

あなたが非常にコンピュータ言語に関して知識があるのはわかります。このコラムでコメントをカキコしている暇があったら原稿を執筆し、出版社にコンピュータ言語の本を出版していただくことをお勧めします。

非常に失礼なのですが、あなたは九州大学農学部卒という経歴で、何か私に対しひがみを感じているのではないのすか？　私は学部は東北大学で大学院が東工大です。東北大学の教授先生たちは、東大の教授が書いた本は売れるけど、東北大学の教授が書いた本は売れないといってました。でも内容が優れているならば大学の教科書どまりの本ではないですから売れると思います。

misaさん

ここのコメントだけではなく、私のHPにアドレスがありますから、本当にVS　C#　ASP.NETのことが知りたかったらお便りください。

AC/DCさん

私の考えるところのクラスとインスタンスについては、当初コメントいただいたRyoさんやぬさんはわかっていると思います。ぬさん曰く「インスタンスをたくさん生成してことオブジェクト指向」「データについてはデータベースが優れていますが、関数がないのでオブジェクト指向と感じない」ぬさんと私は対極の意見なのです。しかしぬさんは本当にオブジェクト指向を活用したビジネスロジックがあるのか？　これはヒカルの碁の神の一手を見るようなものだというのが私の意見です。クラスを使っていても実際にはインスタンスを生成しない関数もあるので、それはオブジェクト指向とはいえないでしょ！　インスタンスを生成し、継承をつかってこそオブジェクト指向と言える。　私、RYOさま、ぬさま、共通した意見です。

せっかく回答してもらって悪いんだけどさ、ちょっと訊きたいこととずれてるんだよね。
もう一度、書くね。

みながわさんが考えるところの「インスタンス」と「static」って何？

別の言葉ではぐらかすのはやめて、シンプルに答えてくれるとうれしいな。
みんなの共通した疑問だと思うよ。

TDaさん

一万件のオブジェクトの面積の計算について、この問題は従業員の給与計算の問題に適用できないか？と考えたわけです。そこがソフトウェアエンジニアとシステムエンジニアの違いです。実際の業務運用を想定するわけです。

まずデータベースに役職や勤続年数などの社員情報を入力するのが当然だと思います。

>この問題は従業員の給与計算の問題に適用できないか？と考えたわけです。
「適用できないか？と考えた」。それで？だからどうした？考えた結論は？
分からないからって、議論をはぐらかすのは止めようよ。見苦しいだけだよ。

＞そこがソフトウェアエンジニアとシステムエンジニアの違いです。
＞実際の業務運用を想定するわけです。
ウソをつけ。

「ソフトウエアエンジニアは机上の空論を唱えるだけ。
　俺様はシステムエンジニアだから実践的だぜ(キリッ)。」
と思わせたいのかもしれないけど、ぜんぜん実践的具体的な答えをしてないよね。

こうなったらとことん付き合います。

>みながわさん
はじめに、わざわざみながわさんの庭で、中傷ビラ蒔くような真似をして申し訳ないと思っています。ですが、内容がどうにも黙っていられない物でしたのですみません。
それから、私があなたをひがんでいるなんてとんでもない自意識過剰です。技術的な観点から、おかしいと思う点を、議論しているだけです。

みながわさんに、今求められていることは、みながわさん自身の観点を普通のエンジニアがわかる言葉で述べることです。私の経歴にアラをさがすことではないと思います。SE生き残りの極意が、ケチを付けてきた人をおとしめるやりかたにあるというのであれば、私は退散します。

オブジェクト指向は難しいのです。しかし非OOPがちゃんとわかっている人には、OOP特有の言葉や方法を、非OOPに対応するものに置き換えれば、ちゃんとわかると思ってます。みながわさんの「しっくりこなさ」を知りたいのです。それはきっと、私のソフトウェアに対する視野を、広げることになると思います。

その上でリクエストしますが、みながわさんのいう「インスタンス」とは何のことですか。たぶん此処を出発点にしないと何も始まらないと思います。

>misaさん
あなたは何もわかってないです。SEに求められるのは、「確かな技術に裏打ちされた上での」動作保証とか速度とか要求に対して柔軟か、あとはやっぱりお金ですよね、ということになります。
みながわさんの元エントリ、コメント読んでおかしいと思わないようでは、現時点あなたのスキルレベルは相当まずいです。

>要求に対して誤魔化して自分の領域まで誘ってから実装を検討するような感じの印象だったので、これは良くないと思ってました。

みながわさんも同じように感じてたようですね。これは議論のレベルが全然違うからです。OOP的アプローチ、非OOP的アプローチ、どちらもあります。OOPは万能ではありません。柔軟性とパフォーマンスとの、トレードオフになっていることがほとんどです。
みながわさんのエントリ、コメントで？と思うのはそれ以前のことです。

またたとえ話で言いますと、こんな感じではないかと。
(かなりきつい例えですが、みながわさん自身がわかっていないようなので、敢えて此処で書きます。)

みながわ「俺分数よくわかんないけど、別に生きていく上で困らないよ。ところでさ、2次方程式の解の公式つかったら、どんな2次方程式でも余裕で解が求められるよ。」
みんな「いや、解の公式の中に分数あるんだけど、、。本当にちゃんと使えてる？」
みながわ「みんなよくわかんないこと言ってごまかすなよ。ところでいつもどんな問題を2次方程式で解いているの？」
みんな「いや、2次方程式以前の問題だし」

全く日記読んで無いけど、

＞非常に失礼なのですが、あなたは九州大学農学部卒という経歴で、何か私に対しひがみを感じているのではないのすか？　私は学部は東北大学で大学院が東工大です。

ってセリフが晒されてるので来ますた＾ｑ＾

正直50歩100歩すぎる

ブログの写真に著名人と映ってるわけでもない講義とかしてるわけでもないなんか駅かどっかでただ突っ立ってるだけの写真使ってるってあたりからもなんか人間の質が疑えるな

>非常に失礼なのですが、あなたは九州大学農学部卒という経歴で、何か私に対しひ>がみを感じているのではないのすか？　私は学部は東北大学で大学院が東工大です。

うわ、関係ねーw
この文に、こいつの人間性の全てが凝縮されてるなw
取り合う価値無し。解散解散！

>非常に失礼なのですが、あなたは九州大学農学部卒という経歴で、何か私に対しひがみを感じているのではないのすか？　私は学部は東北大学で大学院が東工大です。

あまりにも低レベルな発言だって自分でわかってるかい？

この人にメンテされるシステムも、そのシステムを使わされるエンドユーザも気の毒でならないね。この人と同一視される東工大卒業生も気の毒。
一番気の毒なのは、この人の下で働かなければいけないエンジニアさんだが。

非常に失礼なのですが、あなたはオブジェクト指向無知という経歴で、何かオブジェクト指向を使っている普通のエンジニアに対しひがみを感じているのではないのすか？

まあいいや。
とりあえずもう一回訊きたいこと書いておくね。

みながわさんが考えるところの「インスタンス」と「static」って何？

わからないなら素直にわからないって言って、楽になろうよ。

TDaさん
＞あなたは何もわかってないです。SEに求められるのは、「確かな技術に裏打ちされた上での」動作保証とか速度とか要求に対して柔軟か、あとはやっぱりお金ですよね、ということになります。
それはその通りです。そうでないといけないと思います。（確かな技術とは少なくとも自分の行っていることを説明できて使えるレベルと読みました）
ですが、それほど技術が優れていなくてもやっていける場所があることも確かです。

特に提案もすることなく、はいはいと言って仕様変更に応じたりする人。「これできますか？」と聞かれて「これは難しいなぁ」と渋る人。
こういうのはイヤなのですが、ちょうどみながわさんと重なってしまい「そういう人かな？」と勝手に想像してしまいました。
＞要求に対して誤魔化して自分の領域まで誘ってから実装を検討するような感じの印象
がそういうことです。
もちろん私に被害がないからですが、この時点で私としては上記のようなことをしてない人なら良しとしていました。
ここが前のコメントでも謝りました、みなさんと論点がずれていたところです。
（みながわさんは実際に今を不便には思っていないし、本当のトコロはわからないですが、ユーザからの不満もなく満足しているのでしょう）

みながわさんへ

私もTDa様の意見へ賛成します。
なぜなら、このコラムは「エンジニアの生き残りの極意=エンジニアを長く続ける方法」だからです。
この記事の内容はコラム名に相応しくないと思います。
返事で頂いたC#やSQL等の言語を理解することとオブジェクト指向を理解することを比較したら、オブジェクト指向を理解している人の方が長くエンジニアをやれると思うからです。
特に力説されたSQLはクラウド技術の登場で今後減るかもしれません。
それに、私は過去に業務でSQL仕様禁止のシステムを担当したことがあるます。
必ずしも、言語を知っていれば安泰と言う事ではないのは先輩の方がご存知だと思います(先輩と言うのは私が大学の後輩だからです(意外と世の中は狭い))。
なので、記事のタイトルや内容にオブジェクト指向を知らなくても問題なしと考えられる記述は問題だと思います。

最後に、学歴差別は止めた方がいいです。日本で一番perlを知っている子飼さんなんて中卒です。この業界は目安としては学歴は参考になりますが、基本役に立ちません。参考程度だと自社の判断では学歴は陸の上のクロールとしか判断してません。

みながわさんへ

やっぱり、HeadFirstの本を購入することを勧めます。
絶対に視野は広がります(エンジニアで視野を広めることは重要です)。
特に記事の内容の疑問点に対する回答は本の中に記述されてます。
本は厚いですが内容が分かりやすい為、一日で読める量です。
多分、ここでTDaさんや私と議論するより有意義です。

最後にもう一度書籍名を書いておきます。
「Head Firstオブジェクト指向分析設計――頭とからだで覚えるオブジェクト指向の基本」

みながわさんの学歴に関するコメントを読んで、下の記事を思い出しました。

「負け組御用達スナック」の恐るべき魔力！過去の栄光話から抜け出せない常連客たち
http://diamond.jp/articles/-/1206

この歳になったら学歴なんて関係ないです。むしろ工学部出身者が中心のこの世界でTDaさんは、よく勉強して極めているなあ・・・なんて関心します。努力されたのでしょうね。

今の時代、学歴にあぐらをかいているような人は生き残れません。

少なくとも私が退職するまで、RDBMS、SQL文はなくなくなるわけがないです。
SAP R/3 のような企業全体の基幹システムとなるものが、RRBMSとSQL文を駆使したABAP言語で出来ており、R/3は多くの企業で導入されているのです。この現実を変えるにはあと数十年はかかると思います。

マイクロソフトは１９９０年代にサイベース社を買収しSQL Server というものを手に入れました。それからのマイクロソフトはプログラミングとDBというものを融合させる開発手法を採用しています。SQL文のよさを認めていますが、逆にDataSetというオブジェクトによるプログラミング技法を取り入れています。実際わたしはリアルタイム更新処理でINSERT文を書かないです。

ここまでの議論でなんとなくわかったのはオブジェクト指向を好む人とデータベースを好む人とで何か違和感があるということです。

インターネットを利用したクラウドが最近話題になってますが、わたしがオブジェクト指向の応用先としては、分散オブジェクト技術をつかったWEBサービスが考えられると書きましたが、「WEBサービス」です。これはWEBブラウザの商取引ではないです。インターネットを使ったオブジェクト指向技術です。ですからオブジェクト指向を排除するつもりなんて全然ございません。

>この歳になったら学歴なんて関係ないです。
そんなことは皆わかってます。そもそも何もないところから学歴云々を持ちだしたのはあんたでしょう。何を得意になって言いきってるんだ。

いい加減にすり替え発言は止めて、さっさとAC/DCさんの質問に答えてくださいよ。数百人の読者が答えられないことを判ってますがね。

プロフィールにある自分撮りのような神妙な面持ちでお願いしますよ。

SQL文の仕様禁止のプロジェクト、おそらくSQL文の使用禁止のプロジェクトのことか？　この意味？　たぶんRDBMSは使っているのだろうSQL文は使用できるはずなのに、使用してはいけない。驚きました。

よくよく考えてみると、これって企業の体制によるもので、SQL文の読み書きをするクラスを作るチームが別に存在してたってことじゃない？　そんで、このプロジェクトはそれらのクラスを使ってDBアクセスするってことかも。

ヘッダーテーブル、明細テーブルのように複数のテーブルのつじつまが合わなくすることを防止するためにSAPではADONプログラムでは更新処理でINSERT　UPDATEで直接テーブルを更新すること禁止しています。ただし、テーブルの参照についてはSELECT文の使用を認めています。

複数のテーブルの更新による不整合の防止のためのクラス、でもこれって、ぬさまが思うような神の一手とは違うんじゃない？

ひょっとして、オブジェクト指向を使えばデータベースを使わなくてもいい、とかそんなことを誰かが言ってると思ってる？

誰もそんなこといってないよ。
オブジェクト指向をバリバリ使ってる人は、SQLだってバリバリ使ってるって。
相反するものじゃないんだからさ。
もしも、もしもだよ、それすらわかってないなら、みながわさんが「極意」だとか「ノウハウ」だとか言ってるものは、この業界の９９％の人にとっては役に立たないものだよね。

なんで、そうやっていつまでも質問をはぐらかし続けるかな。
もう一度書くね。

みながわさんが考えるところの「インスタンス」と「static」って何？

AC/DCさん

＠ITのC#入門を読んだら・・・なんて冷たいことは言いませんが、わたしは＠ITでC#を勉強しました。＠IT御中には大変お世話になっております。

技術的なことを言っても面白くないので私の「インスタンス」と「static」に関するイメージなのですが、

インスタンスはどらえもんの「どこでもドア」です！！！

インスタンスを宣言することのより、そのプログラムのクラスを使えるだけではなく、データベース、ファイル、最近ではWEBサービスなどのインターネットを越えての分散オブジェクトが使えるのです。

インスタンスを生成する瞬間、まさにそれは「どこでもドア」を開く瞬間です。

WEBサービスってオブジェクト指向流にどこでも開くデファクスタンダードです。

static については、ぬ　さま曰くそれは、オブジェクト指向とはいえない。非オブジェクト指向の変数や関数です。

真に.NET FRAMEWORK のよさを理解してもらうには、プレゼンテーション部とデータベースアクセス部のチームがわかれていてはダメなのです。データベースアクセス部の開発チームはSQL文やクラスを書くことになります。しかしプレゼンテーション部からデータベースアクセス部まで効率的に一貫的に設計してこそ本当にユーザーフレンドリーなスパイラル開発ができるのです。

その点で、データベース部とプレゼンテーション部の分離という一般で信じられていた開発手法を否定しているわけですから多くの方の反発をかってしかたがないと思います。

しかし、現状の日本の経済的状況からして、私の意見は反発をかっても、多くのIS部門から受け入れられるでしょう。なぜってアクセスやエクセルで除法処理をやるよりましなんですから。

私はIS部門の人間なんです。SIerの客なんですよ。私に嫌われたらどうなりますか？

皆さん生きていけないですよ！

学歴持ち出してきて得意げになって、とうとう自分の立場を誇示して恫喝するなんて、
せっかく楽しくコメントを読んできたのに興ざめだなぁ。
どこの会社の人かは知らないけれど、東工大のイメージを下げたことは間違いないですね。

ずっとコメントの推移を興味深く見させていただいておりましたが、
学歴に関する記述と、
>私はIS部門の人間なんです。SIerの客なんですよ。私に嫌われたらどうなりますか？

>皆さん生きていけないですよ！

上記の発言は技術者としてという話以前に、人としてどうでしょうか？

エンジニアとして生き抜く極意というより、
人として言ってはいけない事を反面教師で教えます、というコラム宣伝文にされたほうが現状に則していると思います。

多くの東工大出身者、社内SEの方々のイメージを悪化させる発言をされていることを、認識された方がよろしいかと思います。

後、名前もおそらく本名で、しかも御自身の写真も出されていますよね。
あなたと一緒に仕事をされているSIerの方が、偶然このコラムを読んだら、あなたが書いているとすぐわかるのではないですか？
その時どう思うか、そこまで考えて書かれていますか？

みながわ様

お返事ありがとうございます。
もう少し、正確に書くべきでした。思慮が足りなかった所は反省いたします。
SQLが使えなかったのは最近のプロジェクトになりますが、Javaを使用してGoogleAppsのクラウド技術を使用したの開発になります。GoogleAppsはRDBSを使用しません。使うのはBigTableと言う独自のDBになります(これはRDBSとまったくの別物)。
ですから、GoogleAppsのシステムではSQL言語を中心に考えることはないです。
具体的に説明しますと、BigTableはSQL言語ではなく、Google独自の言語でDBとやりとりします。そのため、joinやwhere句でorの使用するといった物は使用できません。
その代わり、独自のクラスやパッケージがあるのでそれらを使用してシステムを構築していきます。
プロジェクトの問題は、GoogleAppsの独自パッケージを使用してSQL文を利用して作成されるようなデータアクセス部を自作し、利用する箇所になります。
その際に、DTO(Data Trancefer Object)と言ったオブジェクト指向(正確にはOCPやOOP)やO/Rマッピングと言った技法の詳細を知っていないと、システムを作れないからです。

みながわさん

元のエントリーに噛み付くようなことをします。申し訳ございません。
みながわさんの言っている隠蔽姓とはなんでしょうか。

>>オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他の言語でもローカル変数であれば隠ぺいできる話。クラスでもパブリック宣言しちゃえば、隠蔽性なんてなくなる。

クラスをpublicしたらファイル名と一緒になります。隠蔽性とは関係ありません。

>>それから、プロパティに隠ぺい性はない。逆に隠ぺいされていると困る。

これは意味不明です。なぜならプロパティという物は隠蔽(カプセル化)のことを指しているからです。
隠蔽はアクセサ(ここではForm)を指します。Form文の中に実装(Action)を書くことはないはずです。
必ず、ActionメソッドでFormの中身を取り出して利用していると思います。
データの隠蔽(データが外部から見れなくする)と隠蔽性(カプセル化)は違うものです。
データの隠蔽はカプセル化の例題の一部なだけです。それこそ車のはなしみたいな物です。

別にみながわさんに嫌われたって、生きていけるよ。
なんでか知りたい？
そういう下劣なこと言う人が大企業のシステム部門で力をふるってるなら、その会社は遠からず自滅するだろうからさ。

あとさあ、いままでのコラムの中で、「データベース部とプレゼンテーション部の分離の否定」なんて話出てきた？
その程度のことを、誇らしげに得意げに披露されても、誰も感心しないよ。
みながわさんの書いたコード、マジメに読みたくなってきたわ。反面教師として、宴会のネタとして大いに役立つだろうから。

それから、技術的に言えないからといって、「どこでもドア」なんて比喩にもなってないような子供だましでごまかすのはやめようよ。みながわさんのはぐらかしには、もうみんなうんざりしてるんだからさ。

できたらもう一度、答えてくれるとうれしいね。

みながわさんが考えるところの「インスタンス」と「static」って何？
技術的な言葉で答えてくれるとうれしいね。
それはこのつまらないコラムを読んでコメントしてくれた人たちに対する、最低限の礼儀だよ。

ビガーと申します。

私もいちおうコラムを書かせてもらっているのですが、注目の集め方がうまいですね。年配の方は違いますね。

私がstaticメソッドを使用する際は、主にユーティリティを実装するときで、
static変数は使わず、constを使用します。

変数はすべてインスタンスです。用途によりライフサイクル(prototype,singleton,request,session,applicationなど)をコントロールします。
具体的には、各層間のDTOであればprototype、サービスインスタンスであればsingleton、ウィザードページ間のDTOであればrequest、ログイン情報であればsession、アプリケーションメッセージリソースなどであればapplicationみたいな感じです。

ご参考になれば、幸いです。

観念論だと発散しそうなので基本的かつ技術的な指摘を：

本文中からの引用：
> クラスが持つ隠ぺい性が強調されているが、
> これは他の言語でもローカル変数であれば隠ぺいできる話。

取り敢えず、
ローカル変数とオブジェクトのフィールド（インスタンス変数）では「寿命が違います。」
また、staticなフィールド（クラス変数）とインスタンス変数では「インスタンスの数が違います。」

ローカル変数は関数（メソッド）が呼ばれている間だけしか存在しませんが、インスタンス変数は明示的にオブジェクトを作成してから明示的に捨てるまで（GCのあるシステムでは参照されなくなるまで）存在し続けます。

クラス変数はシステムに一つしか実体（それは参照かもしれないが）がありませんが、インスタンス変数は作ったオブジェクトの数だけ実体が存在します。

それぞれ使い分けるものであって代用はききません。

オブジェクト指向プログラミング以前、ダイクストラの構造化プログラミングの時代から

プログラム＝アルゴリズム＋データ構造
（↑N.ヴィルト…PASCALの開発者の著書のタイトル）

であるわけですが、おそらくみながわ氏にはこの「データ構造」という観点がないのではないかと想像します。
というのは、プログラミングを制御構造、制御の流れからしか捉えられていないように見えるからです。

・「アルゴリズム」を連呼されるあたり
・仮想関数を「関数ポインタのデラックス版」と書かれているあたり
・別の記事「この業界の基盤技術の核心！ CPUってどんなもの？」[ http://el.jibun.atmarkit.co.jp/minagawa/2010/04/cpu-aefb.html ]で話がレジスタとALU、命令で終わってしまっているあたり

確かに制御構造だけに注目するならstaticメソッドで「アルゴリズム」は書けることでしょう。（マシン語であらゆるプログラムは記述できるというのと同じ意味合いで。）

しかし、データ構造の設計を考えるならばローカル変数とインスタンス変数、またクラス変数とインスタンス変数の混同はあり得ないことです。寿命やインスタンスの数が違えばデータ構造としては別物だからです。

そして隠蔽性についてもデータ構造の変更がコードに与える影響を考えなければ、それほど重要と思えなくなってしまうのは当然でしょう。「データ構造」の観念がない人が「データ構造の改訂」の開発コストへの影響というソフトウェア工学的な問題に思いが至るとは思えませんからね。

お互いロジックやソースを議論するより、具体的な実装例を見ながらコメントしてみては？
この人がどんなコードを書いてるか、大体想像できるよ。

http://wondsky.hp.infoseek.co.jp/vs2005.htm

public class clsDb
{
public static string DbName = "DatabaseName";
public static string Id = "ID";
public static string Pass = "PASSWORD";
}

みながわ氏のいうところのpublic staticの使い方がこれだけなんだったらあまり害はないかも。
でもこういう情報ってWeb.Configとかに格納するのがセオリーじゃね？

ちなみに元記事の卵みたいなコメントも近況っていうページで読めるよ。

2009年11月16日
http://wondsky.hp.infoseek.co.jp/memo.html

「業務アプリケーションではクラスは使えればいい。へたにクラスを作るな。」なんていう格言も飛び出してるけどね。

大体、悪口や暴言は自分の一番気になることを言ってしまうものです。
そういう意味で、筆者の方は学歴コンプレックスが強く、自分の組織の存在意義に危機感を持っていらっしゃるのだと推察します。

さきに投稿されてる方のがうまくみれなかったので。

この記事にたいする言及の一覧。
http://search.twitter.com/search?q=http%3A%2F%2Fel.jibun.atmarkit.co.jp%2Fminagawa%2F2010%2F04%2Fpost-ebc4.html

いまさらですが
『Head Firstオブジェクト指向分析設計』って
『Head First Java』と『Head First デザインパターン』の続編という位置づけではないんでしたっけ？
今手元にないので確認できませんが

>>reppiv
その通りです。
でも内容的に、ほぼ独立してますよ。
個人的にはデザインパターンの方が好きですが。
両方とも中・上級者で不安がある人には最適な一冊です。

オブジェクト指向的だろうと、構造化チックだろうと、取りあえずは品質が担保出来ればいいとは思いつつも・・・、この書きっぷりからして多分単体テストもろくに通してないにおいがぷんぷんします。
(メソッド全部がstaticだとハードリソースに絡む部分のロジックからの切り離しが困難ですし。まさかC#なのに紙ベースでテストしてるとか・・・?)

それ以前に、学歴で相手けなしたり、自分の地位で恫喝する時点で、語るに落ちましたね。逆に所属会社の上長がこれ見たらなんて思うでしょうか?逆にご自分の地位危なくなること考えたことあります?
今更遅いかもしれませんが無礼な発言の撤回と、きちんとしたお勉強をし直すべきですね。そこまで頭が回るのでしたら、こんなエントリ書かないのかもしれませんが:p)

>>ひまひまさん

>内容的に、ほぼ独立
そうだったんですか。
デザパタだけ持ってて、分析設計は本屋でちらっと見たのですが
前書の知識を前提としているものだと勝手に認識してました。

１つ訂正。

一番気の毒なのは、みながわさん本人だったね。

今日になってこのエントリを知ったのですが、これは…。
「従来通りの設計でVS IDEの自動補完機能を活用するためのテクニック C#編」というタイトルなら特に違和感もない話だったのですが、よく理解してないクセにOOPについて言及しちゃったもんだから大炎上を招いちゃった、という構図でしょうか。

私からも2つほど。
1)みながわさん設計のアプリケーションでは、状態管理はすべてDBで行っていると推察しました。その前提を踏まえてですが、セッションが増えるとwebサーバ-DB間のトラフィックも馬鹿にならなくなるかと想像されるのですが、「エンジニアとして」そのデザインはどうお考えですか? webサーバのみで完結する状態管理は考えられませんか?
2)「標準Cライブラリ関数qsort()の使用方法を、初学者が理念も含めて理解できるように説明せよ」という課題にぜひ挑んでみてください。ポリモーフィズムの話が何度か出てきましたが、その基となるコールバックの概念はCの時代から既に存在しているものです。失礼ながら現在お使いのC#でも、delegate句などご使用になられたことは皆無なのでは、と推察します。

以下は引用元では別の意図で書かれた文ですが、非OOPな人がOOPに対する「胡散臭さ」の正体として的を射ているのでは、と思います。
http://www.geocities.jp/objectbrain/donotneedobjectbrain.html
そもそもヒープや関数ポインタをを知らないやつに，オブジェクト指向などわかるわけがない.

言語に用意されていないデータ構造、たとえば木構造やグラフ構造を実装するのに、オブジェクト指向がとても便利。
さらに、「コンテナ」と呼ばれるものはオブジェクトと親和性が高い。
最近の業務で言うと、ワークフローをWebアプリとして実装したが、様々な種類のものをWFに投入したり、それを検索したり参照したり、さまざまなルールで承認したりするんだが、オブジェクト指向じゃないとやってられなかったよ。
まぁ、本来の意味でのアルゴリズムの実装にはあまり役に立たないかもしれないが、それを利用する場面ではすごく役に立ったりする。FFTのWindow関数をどう扱うかとかね。
上記とは全く関係ないが、俺も『オブジェクト指向のこころ』を劇押ししておく。

なんとコメントにてライターから誹謗発言が出ているから、削除して頂いて永久追放にして頂くのがよろしいかと思います。
そうそう、学歴より現在の所属を公開されてはいかがですか？

>セッションが増えるとwebサーバ-DB間のトラフィックも馬鹿にならなくなるかと
>想像されるのですが、「エンジニアとして」そのデザインはどうお考えですか?
>webサーバのみで完結する状態管理は考えられませんか?

企業システムとしては、たとえWEBサーバーがハングって再起動をかけても、直近の状態は保存されるべき。１セッション内でのフラグのような状態変数についてすむ場合は、DBアクセスは不要。

通りすがりさん

>最近の業務で言うと、ワークフローをWebアプリとして実装したが、様々な種類の>ものをWFに投入したり、それを検索したり参照したり、さまざまなルールで承認し>たりするんだが、オブジェクト指向じゃないとやってられなかったよ。

どのようなコードか見せて欲しいです！　読者はみんな期待していますよ。通りすがりさん　って名前なんで、もう来てくれないんですか？

みながわけんじ さん

>どのようなコードか見せて欲しいです！　読者はみんな期待していますよ。通りすがりさん　って名前なんで、もう来てくれないんですか？

まさにみながわさんにみんなが期待していますよ!
コード見せてほしいです

むしろ通りすがりさんのほうはわりと公開されているかと。自分で検索してみるといいですよ。

/.から来ましたがよく燃えていますね・・

この記事を今日知りました。

メールマガジン『C#プログラミングレッスン』を発行しているものです。
まずは、『C#プログラミングレッスン』を読んでくださりありがとうございます。

どうして私の記事を引き合いに出されたのか分かりかねますが、
引き合いに出された No.037 の記事だけではなく、是非、「オブジェクト指向編」
を通して読んでいただければと思います。バックナンバーは、
http://gushwell.ifdef.jp/magArchive.html
からテキストファイルとしてダウンロードできます。
ポリモーフィズムはオブジェクト指向の肝ではありますが、まずはクラスとインス
タンスについて理解していただきたいと思います。

確かに、reppiv さんが言うようにナイスな記事では無いかもしれません。
今読み返すと、つたない文章ですが、C#の文法からの視点でクラスやインスタン
ス、メソッドなどを、順を追って出来るだけ分かりやすく書いたつもりです。

みながわさんは、C言語をお使いになったこともあると言うことですので、構造体
とポインターは理解されていると思います。
ですので、心をニュートラルな状態にして読んでいただければ、それほど違和
感なく、クラスやインスタンスについても、そしてその利点についてもご理解で
きるのではと推測します。
もし、既に理解されているのであったとしても、もしかしたら何か新しい発見が
あるかもしれませんし...

No.037だけで判断されずに、一連の記事を通して読んでから判断していただきたい
というのが僕からのお願いです。

で、疑問への回答ですが、既に、ryoさん、ぴぐもん さんがコメントされていま
すので、繰り返しになりますが、1万個のデータがあれば、1万回インスタンスを
生成します。（もちろん、１万行書くということではありません。）

というか、C#においては、1個のデータだろうが、１万個のデータだろうが、
（それがどんな型であるにせよ）インスタンスを生成することになります。

驚かれるかもしれませんが、C#では、
int a = 0;
は、
int a = new int();
と同じことです。
この２つは、コンパイルすると、まったく同一のILに変換されます。

とこんなことを書くとますます訳分からなくなってしまうかもしれませんので、
このコードの件はは忘れていただいてもかまいません。

蛇足ですが、僕もみながわさんと同様、COBOLやBASICでのシステム開発を経験し
ている老プログラマーですが、今では、手続き型のみででプログラムを組むなん
てとても考えられません。

今来てコメ欄も（長すぎて）禄に読んでいませんが、
オブジェクト指向なんか使わなくても大丈夫！
と言った意見で切り捨ててしまうにはあまりにも惜しい物です。（と私は思っています）

http://www.oreilly.co.jp/books/4873112494/
http://www.oreilly.co.jp/books/9784873113494/
よろしければ、この二冊に是非目を通して頂きたいと思います。

まあ確かに日本の環境では、オブジェクト指向を学んでも使えないことが多いのは否めませんが…。
（オブジェクト指向は一種の決まりのような存在なので、
　常識というLvで普及している会社、環境でしか役に立たないです）

実例をってことなので、C#っぽいコードをベースにして、業務(?)でOOPを利用する例をあげてみます。
かなり単純な例なので、「これで業務でOOPを使えるって事にならないよ！」って反論はある気がしますが、せっかく書いたので投稿することにします。

例えば、こんなテーブルがRDBにあるとします。
create table 社員 (
ID number primary key,
苗字 varchar,
名前 varchar,
誕生日 date
)

んで、このテーブルに
ID=1、苗字=田中、名前=太郎、誕生日=2000/1/1
ってデータがセットされている時に、
「田中 太郎」、「10」(年齢ね)
って結果が欲しいとします。
これを手続き型で解決すると、例えばこんな感じでしょうか。

public static string フルネーム取得(string 苗字, string 名前) {
return 苗字 + " " + 名前;
}
public static int 年齢取得(DateTime 誕生日) {
//なんかごちょごちょして…
return age;
}
public struct 社員 {
int ID;
string 苗字;
string 名前;
DateTime 誕生日;
}
public static void Main(string[] args) {
//データ取得
社員 data = getdata(); //データとってくるところは省略
Console.Write("{0}は{1}歳です", フルネーム取得(data.苗字, data.名前), 年齢取得(data.誕生日));
}

OOPにするとこんな感じでしょうか。

class 社員 {
private int ID;
private string 苗字;
private string 名前;
private DateTime 誕生日;

//単純なアクセサプロパティは省略

public string フルネーム取得() {
return 苗字 + " " + 名前;
}
public int 年齢取得() {
//なんかごちょごちょして…
return age;
}
//こういったメソッドはプロパティで定義した方がいいかもだけど、
//そこは本質じゃないので…。
}
public static void Main(string[] args) {
//データ取得
社員 data = getdata(); //データとってくるところは省略
Console.Write("{0}は{1}歳です", data.フルネーム取得(), data.年齢取得());
}

まぁ、教科書に載っているようなレベルの例ですが、
あるデータ内容を一定のルールで変換して出力するってのは業務でもよくあります。
そういったときに、OOPを利用してデータと振る舞いをくっつけてあげると保守性が高くなりますね。

例えば、外人さんを登録するようになったので、フルネームが「名前 + " " + 苗字」になるパターンが発生した場合とか、ミドルネームの項目が増えたとか。
いずれもclassを変更するだけで、呼び出し元には手を入れずにすみますよね。
これが手続き型だと、引数が変わってしまうので、呼び出し元に影響を与えてしまいます。

じゃあ、ってことで手続き型の場合の引数を変え、構造体をまるまる引数にとる例があります。
（実際、結構こういう例は見かけます）

public static string フルネーム取得(社員 data) {
return data.苗字 + " " + data.名前;
}

これってOOPっぽいことを無理やり手続き型で解決してるってことになりませんか。
関連するデータと手続きをそれぞれ別に定義しているだけなので。

今は、OOPっていう考え方とともに、言語仕様によってデータと手続きをひとつに纏める機構があるので、素直にそれを使ってあげるのが良策だと思うのです。

↑の例に対する反論として思いつくものに予め回答を。

１）データとってくるところも社員クラスに含めた方がいいんじゃね？
個人的意見ですが、データアクセスはそれ専用のクラスを用意するDAOパターンを使う方がよいと思ってるのでここでは別にしておきました。

２）こういう処理って普通テンプレートエンジンに任せるんじゃね？
まぁ、アウトプット方法が一つならそれでもいいのですが、例えば、HTMLで出力、メール本文として送信、CSVとしてファイル出力…など、アウトプット方法が複数ある場合は、こういった形でデータに近いところに処理を持ってきた方がいいこともあります。

３）このソース動かなくね？
ごめんなさい。机上で書いただけなので、コンパイル通してません。
イメージをつかんで頂ければ、と思います。

>どのようなコードか見せて欲しいです！　読者はみんな期待していますよ。

読者が、じゃないよね。
みながわさんが、だよね。
ここを読んでるほとんどの人はみながわさんが知りたがっているようなことは、とっくに知ってるんだよ。
みながわさんが、オブジェクト指向に関しては（その他のシステム開発スキルについてもそうかもしれないが）、素人に毛が生えた程度だってことは、もう明白なんだよ。
誰もみながわさんから、今更何か学ぼうとか期待してないから。
みんな親切な人ばかりだから、少しでもみながわさんのエンジニアライフの実になればと、書籍やサイトを勧めてくれているんだよ。

だから素直に自分の無知を認めて、教えを乞うてはどうかな？
プライドが許さないかなあ。

あ、それから、前の質問はまだ有効だからね。
もうほとんどまともな回答は期待していないけど、いいかげんなコラムを垂れ流した責任を毛ほどでも感じているなら答えてね。

Gushwellさん

ポリモーフィズム、C#というキーワードでサンプルコードを探していて貴殿の記事が見つかりました。ちょうど　ぬ様が言うようにfor ループがあったので、本コラムで引用させていただいたしだいです。Ryo様より一度インスタンスを生成してしまえば条件分岐なしでいけるということで、なるほどと納得しました。結構感動ものでした。いい例題だと思います。感謝を込めてありがとうございます。

int の例は私も最初にC#入門の本でintが実はクラスだと書いてあったのでショックでした。このコラムの最後で意味不明のことを言っていますが、そのショックで頭が混乱している状況を表現したかったのです。

神戸さん

確かに私はへたなハード知識があるためにデータ構造という考えかたが欠けているのだと思います。このコラムではソフトウェア工学を研究なさっている方、オブジェクト指向の先生方、すごい方々が親切にコラムを書いてくださっています。

もともとのコラムで扱いたかったことはIS部門向けにVisual Studioを使ったRAD開発です。

いろいろな方の意見を聞き、私が思うに、

インスタンスを生成する必要があるものが静的であるとすると、インスタンスを生成するものは動的ということではないか？

動的という意味はインスタンス生成時に、TLBを参照し空いているメモリ領域を確保し、そのメモリ領域の先頭アドレスをインスタンスのアドレスとするのではないか？

動的にインスタンスのアドレスが決まるならば、コンパイラはクラスごとにメンバー変数とメンバー関数を相対アドレッシングでアセンブラコードにする必要があるのではないか？

それにより、同じクラスでインスタンスを生成するごとに、メモリ上にデータとプログラムが生成されるのではないか？

などと想像してしまうのです。インスタンス生成、メモリアロケートやアドレッシングが動的ということでしょうか？

ももたろうさん

サンプルコードわざわざ書いてくださってありがとうございます。今日はもう遅いので頭がもっとさえているときに呼んでみます。

たろ～さん

やっぱりデザインパターンがキーワードでしたか。本コラムを書くまで知らなかった言葉なので確かに皆さんに言われるように私は勉強不足ですね。

> やっぱりデザインパターンがキーワードでしたか。
ポリモーフィズムを知らないでオブジェクト指向を批判してることにも驚きましたが、これで更に驚愕して呆れ果てました。

念を押しますが、貴方が先生方と言った方々ですら今日び常識レベルの知識しかコメントされておりません。貴方にとっては世の中の認識と逸脱しているかを知ることになったのでしょうが「生き残りの極意」と称するには大袈裟な内容であることは否めません。

あなたは世間を知らな過ぎたのです。年齢に不相応な言動と知識、アットマークIT全体の名誉失墜、数々の非礼について明確に謝罪するべきです。

あと貴方がコメントに対して取捨選択する基準は何なのでしょうか。図星を指されてぐうの音も出ないコメントはスル―されているように見受けられます。50歳目前の社会人の行動とは思えません。

プライドを捨ててAC/DCさんの質問に答えてください。くだらないコラムを晒してしまった貴方の今後を大きく左右するでしょう。

> 企業システムとしては、たとえWEBサーバーがハングって再起動をかけても、
> 直近の状態は保存されるべき。１セッション内でのフラグのような
> 状態変数についてすむ場合は、DBアクセスは不要。
はて? 1セッション内の状態変数は、直近の状態に含めなくてもよいのですか?
「どこまで状態を保存すべきなのか」が示されない以上、論理矛盾としか受け取れませんが。
この文脈での「1セッション」とは、どこからどこまでを指していますか?
トラフィックの観点からの見解を期待していたのですが、このような回答が
来るということは、察するに「ダム端感覚」ということなのでしょうかね。

ところでqsort()の話はどうですか?…と思ってたらその後のコメントを見る限り、やはり「理念」についてはこれまでご理解なさってなかったようですね。

> 動的にインスタンスのアドレスが決まるならば、
> コンパイラはクラスごとにメンバー変数とメンバー関数を
> 相対アドレッシングでアセンブラコードにする必要があるのではないか？
メンバー変数はさておき、メンバー関数を相対アドレッシングで
アセンブリコードにしなければならない「必然」は何でしょうか?
コンパイラはそこまで馬鹿ではありません。

> もともとのコラムで扱いたかったことはIS部門向けにVisual Studioを使ったRAD開発です。

あはは、それはちょっと無理があるよ。
Visual Studio なんて２回言及されてるだけだよ。
書いてることは見事に的を外してるし。
何とか自分の得意な領域に話をつなげようとして、アセンブラの話なんか持ち出しても、誰も感心しないよ。

「老醜」という言葉を思い浮かべた人、きっと１人だけじゃないはず。

/.JPでも話題になってますよ。ご参考まで。

http://slashdot.jp/developers/article.pl?sid=10/05/06/0923253&threshold=-1

> 非常に失礼なのですが、あなたは九州大学農学部卒という経歴で、何か私に対しひがみを感じているのではないのすか？　私は学部は東北大学で大学院が東工大です。東北大学の教授先生たちは、東大の教授が書いた本は売れるけど、東北大学の教授が書いた本は売れないといってました。でも内容が優れているならば大学の教科書どまりの本ではないですから売れると思います。

この発言に関して釈明も謝罪も追記も訂正もありませんが、その理由を以下の中から選択してお答えください。

(A) 何も間違ったことは言っていないし、失礼とも思わないので、謝罪の必要を感じない。
(B) 上記の発言をした記憶はない。
(C) 不適切な発言であったと自覚しているが、どう収拾すべきか判断がつかない。
(D) その他

はじめまして。タイトルに釣られて来て、議論の噛み合わなさっぷりを楽しんでいたのですが

>非常に失礼なのですが、あなたは九州大学農学部卒という経歴で、何か私に対しひがみを感じているのではないのすか？　私は学部は東北大学で大学院が東工大です。

このコメントを読んだ瞬間からそれまでの議論がどうでもよくなりました。
こういう社会人にだけは絶対なってはいけないなと再確認させて頂いただけで、このコラムとコメントを読ませて頂いた価値があると感じています。ありがとうございました。

★

目的は「そのシステムにもっとも適した設計」なのでしょう？

本文およびコメントで書いている(色々な設計に関する)ことは
おおむね間違っちゃいないと思う(長すぎて全部は読んでないけど...)。

ただ、「想定しているシステム」がそれぞれ違っているから話がかみ合わない。

もし、お互いちゃんとオブジェクト指向について議論を進めたいのなら、
想定するシステムを厳密に既定し、さらに将来の仕様・設計変更は
どこまで追随するのか、といったことまで決め、話した方がよいのでは。
＞まず、みながわさんが決めたほうがよさそうです。

はじめまして。スラッシュドットで話題になっていたので、議論を拝読しまいりました。

>非常に失礼なのですが、あなたは九州大学農学部卒という経歴で

はもちろん論外と解釈しますが、それ以前に本文において、

pubulic static宣言

と記述されている時点で、そんなに目くじらたてて議論する内容ではないであろうと考えました。

肯定的な見方をすれば、そのご年齢(と言っても私より2つ下ですが)でいまだ一線というのは大したものだと思います。二極化という表現は適当ではないのですが、多数の企業の情報システム部門ではオブジェクト指向なんて必要ないのでしょうね。であれば、著者のご見解を否定するわけでもなく、システムエンジニアとして長期に活躍した経験に基づく極意として優れたコラムではないかと感動いたしました。

static変数をわかっている人が static変数を使うのと、
static変数をわかっていない人が static変数を使わないのは問題ないのですが、
static変数をわかっていない人が static変数を使うのは危険です。

例えば ASP.NET で static変数Xを使っていて、同時に web server に 二つのHTTP リクエスト(A,B)があった場合に、処理Aがstatic変数Xの値を1 を設定し、処理Aが終了する前に処理Bがstatic変数X の値を 2 に更新した場合、処理A が static変数X の値を再度参照した場合に元と値が違うようになります。
static変数をわかっていて、意図してそうしている場合ならいいのですが、わかってない人が使うと判明しにくいバグを仕込むことになります。

上記の例では ASP.NET ですが、フレームワークの対応などでマルチスレッドのプログラミンも増えてくるので、みながわさんは分かっていて使っている方だと思われますが、一般向けには「うかつに static変数は使うな」と言った方がいいとおもいます。

現在のVBは、良く知りませんが、
昔のVB(VB5あたりかな？)では、
情報、隠蔽機能だけ実装していて、
堂々とオブジェクト指向を名乗っていた時代がありましたね。
多分、みながわさんは、
この当たりの情報で不完全な勉強された犠牲者かな？
ソフトウェア工学やソフトウェア科学、計算モデルの基礎を知らない人や
構造化プログラミング→抽象データ型→オブジェクト指向のような
歴史の流れを見てない人に将来を見ることは難しいのでしょう。
刹那的に生き残るサラリーマン・プログラマやコード・ジェネレータな人は
それで良いかもしれませんが、
少なくとも真っ当な技術者としては、生き残れるのでしょうか？

以上

「地図ってしっくりこないんです。
地図を見ないでもタクシー運転手として生き残れます！
もう新しい地図を覚えなくても平気！」

というタイトルを見て、「おお、そんなノウハウが！」
と期待して記事を読んだら、
みながわ「音声合成のナビを使え！」
とか書いてあってズコー。
という印象でした。

まぁ本人が評判落とすのは構わないんですが、
学歴差別や、職権を楯にした恫喝まがいのコメントを訂正もせずに
垂れ流すことについて、@ITの編集者はどうお考えなんでしょうか？
というのが目下一番の興味です。

○○大卒どころか大卒じゃなくて申し訳ありません・・・・（爆笑）

議論はさておき・・・
>Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから
とか・・・
>結局、何をしたいのかによって、クラス名やメンバー関数、プロパティが
>それぞれ違ってくるわけで、典型的なプログラミングTipsをメモって
>使うしかないんだよね。Visual Studioは「インスタンス名.」と打てば
>プロパティやメンバー関数の候補が出てくるから楽になった。
って結局この「オブジェクト指向ってしっくりこない」にどうつながるんだろう。
オブジェクト指向だろうがそうでなかろうがこれ・・・関係なくない？
ツールについてとオブジェクト指向NGを混ぜて書いてあるのがいただけません。
理解度の有無関係なくこの文章では持論が分かりません。
とりあえず、このコラムからは「Visual Studio」便利しか伝わりません。
ってことで私からは
「Eclipseのほうが好きです」

あと、本人がどうおもっていたのかは別として、○○大卒だからと
先に持ち出しておきながら、あとから「この年になると学歴なんて・・・」
と発言されたことについて謝罪すべきです。
学歴関係ないなら学歴批判を議論に持ち出すべきではありません。
相手がどう思っていようとそれを発言していないのですから、勝手に代弁して
自分は学歴関係ない発言なんて正直理解できません。
学歴を考えているから「相手は学歴意識しているのだろう」などと考え
しかも発言してしまうのです。
しかも代弁することで自分から相手の学歴を批判しているのです。

『学歴発言のコメント消しちゃ駄目だぞぉ』

いままでの流れ読んでる限り、みながわ氏はたぶんC言語でも無節操にグローバル変数を使ってそうな・・・。
オブジェクト指向使えないにしても、それ以前にCでのまっとうなプログラムすら出来ないんじゃなぁ・・・。

それ以前に人格的に問題ありますけどね。
彼の下だと確実に理不尽な下請けいじめありそうですし。
立ち位置近いとは言え、よく生島氏Twitterで擁護したよなぁ・・・。

よく燃えていますねここは。
コメントを全て楽しく読ませていただきました。
みながわさんのもの知らずっぷりがビンビンに伝わってきます。
いじりたくなってきました。

>タイトルどおり、私はオブジェクト指向がわかってないのです。それでもユーザーの要望にこたえるために .NET FRAMEWORK を駆使して開発を行っているのです。
>オブジェクト指向がわかっていないから、主張も結論もありません。模索しながら開発し給料をもらっている身なのです。そのところを理解して欲しいです。

とか言ってますが、それだったら記事中の

>staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。

これは何なんでしょうね。
分かってない人が、分かってる人の作ってるものをみて笑うんですか。
どんだけ傲慢なんでしょう。
あいうえおを書けるようになった幼児が、書道家の作品を見て字が下手だと笑ってるようなもんです。
自分のレベルをわきまえて発言してください。

>確かに私はへたなハード知識があるためにデータ構造という考えかたが欠けているのだと思います。このコラムではソフトウェア工学を研究なさっている方、オブジェクト指向の先生方、すごい方々が親切にコラムを書いてくださっています。

貴方の言う「ハード知識」って何ですかね。
直前のエントリでCPUについて書いた稚拙な文章も読みましたけど、あれでCPUを理解してるとか片腹痛いです。
というか、なんかOSというか自分で呼び出す層以下で起きてることを、全部ごっちゃにして考えてませんか。
CPUのやることとOSのやることも混同している様子ですし。

そんなわけで、はっきり言ってハードのことが分かっているとも思えません。
単にデータ構造のことを全然考えてない、ただの無能ですよってカミングアウトしてるだけじゃないですか。
ハード方面もソフト方面もまるで理解してない、ただの半端者かと。

>インスタンスを生成する必要があるものが静的であるとすると、インスタンスを生成するものは動的ということではないか？
>動的という意味はインスタンス生成時に、TLBを参照し空いているメモリ領域を確保し、そのメモリ領域の先頭アドレスをインスタンスのアドレスとするのではないか？
>動的にインスタンスのアドレスが決まるならば、コンパイラはクラスごとにメンバー変数とメンバー関数を相対アドレッシングでアセンブラコードにする必要があるのではないか？
>それにより、同じクラスでインスタンスを生成するごとに、メモリ上にデータとプログラムが生成されるのではないか？

メンバー関数が相対アドレッシングで、とかのくだりは既におかしいと突っ込まれているので放置しとくとして。
まあインスタンスというのは動的なものだという部分だけは別に間違ってません。
これでやっと一歩だけ前に進めますね！おめでとう！
入園したての園児が、年長組に進級したあたりでしょうか。

ただね。
なんでそこでTLBがどうのとか言い出すのか意味わかりません。
そんなもんOSの領域です。
TLBがどうのこうの言い出して自分に酔う前に、まず貴方はヒープとスタックを理解すべき。
そのほうがよほどインスタンスについて理解が進みます。

全編にわたってツッコミどころが満載で、書いてるときりがないのでひとまずこのあたりで中断します。
あとはみながわさんの反応しだいで。

そうそう、俺は仕事で書くプログラムでも趣味で書くプログラムでもクラスは普通に使いますよ。
静的メンバも動的メンバも当然使い分けます。
まあ、業務系SEじゃなくてどちらかというと制御系SEなんですが。

たぶん、みながわさんは、このまま何にも答えることなく釈明も開き直りもすることなく、フェードアウトしていくとみた。
で、1年ぐらいオブジェクト指向を必死で勉強して、「昔からオブジェクト指向バリバリ使ってました」みたいな顔でコラムを書くと。

みながわさん
結構、定評がある@ITのコラムだったから炎上してしまいましたね onz
オブジェクト指向と言うより抽象化や仮想化と言う
コンピュータやソフトウェア、
科学や技術の根本的で最重要な事項を
全く理解せずにマイコンのアセンブラ経験から
MS開発環境の職業的ソフト開発な井の中で過ごされていた感がアリアリでした。
しかし、私の周りでも、
抽象化の分からない自称エンジニアと言う人が多くてヘキヘキしていますが…
日本人のモノ作りって、即物的な匠の世界に直結しちゃって、
そのあとは、精神論が多いのは、
大学で最先端の教育が生かせなく（あるいは、全くなく）、
企業内の再教育に頼っているIT業界の問題なのかな？
これも、文系重視で理系搾取の日本の現状の現れとかと思う今日この頃。
みながわさんの論理は、
学歴で言えば、中卒どまり（というと努力している中卒の方にわるいか？）
まぁぁ〜〜、
自称、最高学府卒でもトンデモナイ人は沢山見てきましたから
あまり、驚きはしませんが…
以上

みながわさんの文章って稚拙すぎて
真意が伝わらないのですね。

原文のみから、深読みする次の事を主張したかったのかな？

・オブジェクト指向入門書を鵜呑みで仕事のプログラムを書いてはだめ
　→　現在のWebサービスのフレームワークで、
　　　インスタンスを乱造するのはメモリリークの元
　→　単なるリテラル宣言やステート・レス処理（アルゴリズム）の記述は
　　　staticで書いた方が良い
　→　車輪の再発明をするより、既存のライブラリやフレームワークを
　　　充分勉強しましょう

最近、メモリリークの悪夢に魘されたのかな？
それにしても、コラム本文も議論も稚拙すぎかな？
当分、文章は書かない方が良いかも。

そういえば、形式処理に精通した
関数型言語の大好きの友人が、
Javaでメソッドを全てクロージャを意識したstatic宣言で書けば、
classなど殆ど作らずに１行で処理が掛けるけど、
その場合のメトリクスは、どう計測すれば良いか分からないと
言っていたのが笑ってしまいましたが、
みながわさんも
このレベルに成れば、議論もかみ合うかも。
しかし、友人の１行プログラムコードを是非見てみたい。

＞　そういえば、形式処理に精通した
形式処理→形式手法(FormalMethods)のことです。
失敬

おはようございます。
コメントはほとんど読まずにコラムしか読んでいませんが、コメントを。

まず、「オブジェクト指向」と「オブジェクト指向言語」がごっちゃになっていませんか？
「オブジェクト指向」とはシステムや概念・事象・モノゴトをオブジェクト単位に分けて、オブジェクトに「振る舞い」と「状態」を持たせてその関連性を捉える、という『考え方』です。そこにポリモーフィズムも継承もカプセル化も出てきません。
オブジェクト指向を使って分析・設計されたものを実装に落とし込むときに、はじめて「オブジェクト指向言語」というものを使うだけです。それが.NETだろうがjavaだろうが、同じです。

言葉の概念がズレてるので、まずもって何を主張されても理屈が通らない気がしますが、いかがでしょうか。

また、文脈から察するに、具体化は御得意なようですが抽象化が苦手でいらっしゃるように思います。抽象化が苦手な方がオブジェクト指向で考えるというのはそれなりに難しいと思います。まずは抽象化とは、を考えられるのがよろしいのではないでしょうか。

オブジェクト指向、オブジェクト指向言語、オブジェクト指向言語の実装方法がすべてゴチャマゼになっているのを一度整理された方がよろしいかと思います。

余談ですが、ポリモーフィズムは「分岐を書きやすくするため」ではなく「APIを利用する側がその内部実装を意識しなくて良いようにするため」に使う方が、メンテナンスしやすいコードになると思います。一人で実装するのでしたら考える必要はありませんが。

この人に何を言っても無駄じゃないかな？
発する言葉の全てから、年だけ重ねて（技術屋としても人間的にも）成長してこなかった感がありありとするもの。他人の忠告・アドバイスを自分の否定と捉えちゃう、典型的な老害なんだろうね。「システムエンジニア 生き残りの極意」とはいうが、こういう人は生き残ってほしくないものだな。

俺も言うだけ無駄だと思ってますけどね。

>私はIS部門の人間なんです。SIerの客なんですよ。私に嫌われたらどうなりますか？
>皆さん生きていけないですよ！

コメント欄でのこの発言なんか、この人の真骨頂でしょう。
結局、技術で生き残ってきた人じゃないです。
こんなのが上司だったら、学ぶものなんかひとつもないからとっとと転職します。

なんか既視感があると思ったら、パソコン大魔神に似てるんですよ。
ろくにものも知らないくせに偉そうに嘘を垂れ流すあたりとか、用語を理解せずに使ってるあたりがそっくりです。
どっちも典型的な老害というか老醜を晒しているというか。
早く引退してほしいものですね。

SEを目指す私としては、ここのコメント欄でかなり勉強になります。

こんばんわ。

『インスタンスはどらえもんの「どこでもドア」です！！！』
名言を期待したけど、残念。

内容はさておき「どらえもん」じゃなくて「ドラえもん」です。
小さな事ですが、用語を正確に使用できない時点でSE失格です。

オブジェクト指向以前に、文章力を磨きましょう。

内容はさておき「こんばんわ」じゃなくて「こんばんは」です。
小さな事ですが（以降省略）

ＯＯ原理主義者は視野が狭くて遺憾の～。自分と違う考えがそんなに許せないの？

考えが違うと言うより、自分の誤りや非を決して認めない態度だとか、議論に学歴や立場を持ち出す低劣な人間性が顰蹙を買っているのだと理解していますが。
そりゃあ、みながわけんじが無知で愚かなのは確かですが、それだけではこれほどの非難を浴びませんよ。

今回のコメントのように親身になってくれた人を拒絶しつづけても生きてこれた事実に驚愕します。
みながわさんが（精神的にも技術的にも）成長しないまま年を重ねることを許してしまう土壌が常にあったのでしょうか。
だんだん憐れに思えてきました。。。

みんなあきれて突っ込んでないのでしょうが、突っ込んでおきます。

＞いんやぁ、ここ１０年くらいは　クライアント、WEBさーばー、データベースさーばーの３階層システムばっかり構築してますよ。

それ、2階層です。
Webサーバ＋アプリケーションサーバ＋データベースサーバ が3階層。

無駄と知りつつ。
http://www.nom.ne.jp/genkuken/chigaukangae.htm

＞龍馬さん

ええ、確実に無駄です。
だって、別に「自分と違う考えがそんなに許せない」とかそんなんじゃないですからね。

↓みながわさんのコメント
>オブジェクト指向がわかっていないから、主張も結論もありません。模索しながら開発し給料をもらっている身なのです。そのところを理解して欲しいです。

とか言ってますが、そのレベルで

↓元記事
>staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。

こんなことを書いてるわけです。

「お前そんなこと言う資格も知識も技術も経験もねーだろ」
ってのが、コメントで突っ込んでる人たちの気持ちだと思います。
少なくとも俺はそうです。
レベルが低すぎてみんなに突っ込まれてるだけです。

みながわ氏の壮大な釣りですよね？みんな釣られすぎですよ。

釣りじゃないなら、みながわ氏は普段一緒に働いておられる
同僚や部下、上司、お客様にこの記事のやりとりを見られて
本当に問題がないのか、今一度冷静に考えたほうがよろしいかと・・・
余計なお世話ながら、こっちが心配になります（＾＾；

> static関数のサンプルコード
がどのように機械語にコンパイルされるのか。
「この業界の基盤技術の核心！ CPUってどんなもの？」
の著者の君なら答えられるだろ。

この記事とコメントを読んで、一つ確実に言えることは、もうみながわ氏はWeb上のライター稼業の生命線を断たれた、ということですね。

もう何を書いても、この記事へのリンクを張られて笑いものにされるだけですので、、、おそらく@ITからも連載の中止をやんわりと要請されるでしょう。
あとは、ペンネームを変えて、ばれないように振舞えるか、それだけです。

＠IT自分戦略研究所 編集部の岑です。

本コラムについて、たくさんのご意見、誠にありがとうございます。
コラム内容のチェックについて、編集部では最低限は行いつつも、
なるべく書き手様の公開意思にお任せしております。
「＠ITとしてこのような内容を載せるべきではない」というご意見に付きましては、
真摯に受け止め、今後の運営体制に反映させていただきます。

また、みながわ様には一部コメントでの攻撃的な発言に関して、
お控えいただけるよう、お願いをしております。

何卒よろしくお願いいたします。

＞みながわけんじ
おまえ向きのコラムが出てるぞ。
無知なんだから、動物クラスみたいな例は～とか言ってる場合じゃないだろ？
http://el.jibun.atmarkit.co.jp/freeskill/2010/05/1-8556.html

そのネタ実は古いと思いますが・・・・

http://mimizun.com/log/2ch/tech/pc8.2ch.net/tech/kako/1085/10852/1085211351.dat

けんじ君、
「新しい」か「古い」かはどうでもいいだろ。
「間違っている」ことに比べればな。

顔と名前曝して「生き残りの極意ノウハウを教えます」とか調子に乗ってみたもののフルボッコにされてやんの。お宅もう終わりじゃね？

このコラムでも何でもない駄文だが、＠IT自分戦略研究所からも駄文だったと烙印を押されているわけだ。何かコメントは無いのかね？「そのネタ実は古いと思いますが・・・・」レベルの発言しかできんのか？

つーか反省文は無いのかい。pubulic static宣言していまうぞ？

良質なコメントが散見されるので、「炎上」と切って捨てるのが惜しいかも。
元コラムやみながわ氏のコメントはノイズとして除去して、
　「オブジェクト指向の教え方」
という観点で再構築したい所。

教え方というか、そもそも他の人はどうやってオブジェクト指向を理解したかというのが気になるといえば気になります。

俺は、クラスとインスタンスの関係についてはよく言われる
「クラスは結局のところ関数のくっついた構造体」
というのが、突破口になった口です。
正しくは違うものの、イメージを掴むのに一番分かりやすかったですね。

ポリモーフィズムは、自分でちまちまクラスをこさえてるうちに何となくという感じで、なんかきっかけになった考え方というのがありませんでした。
結局、自分でクラスを作って使ってみるのが一番手っ取り早いような。
そう考えると、実装しづらい動物クラスってのはいい例題には思えませんね。

QtやVCL等の良質なフレームワークを使って画面まわりを作ったら自分はポリモーフィズムとかの使い方を覚えた。
DB周りだとあまり必要ないから覚えないんじゃないかな。
VCLでいうと、独自の見た目のコントロールを表示するために既存のコントロールのPaint()処理だけをオーバーライドして既存の機能＋独自の見た目を実現させられるけど、この辺りをやってみると具体的な使い方が覚えられるんじゃないかな？

GoFだって神の一手を極めんとする者の１だと思います。しかし、GoFは「制御の抽象化」に傾いていて、確かに四暗刻（下手すると、連続嶺上開花や、連続海底撈月）に当たると思います。それよりも、「データの抽象化」にとどめる事をおすすめします。こちら程度だと、誤りが少なく、何かしらの利がでます。

話は変わりますが、自分は（拡販員に押し切られて）新聞を３紙取っていて、くやしいので極力読んでいますが、うよださよだと言いながら、どの新聞も「事実8割（こちらはほぼ一線）、意見2割」の様です。報道のプロの新聞屋でもそうなのですから、素人が意見10割でやっていける筈が無いと思います。

それから考えると、「原則として事実を基にするスレタイに対し、好きなタイミングで意見を述べられる」様な形式の掲示板というのは、それなりに上手く出来ていて、ブログというのは長く続けるのは、茨の道かも知れないです。

それはそれとしましても、
自分もみながわさんと同年代みたいで（ただし学士止まりですが）親近感がわきます。今後の記事も期待しております。

> staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。
　ああ、これの意味を、理解していませんでした。これ、「static な変数にアクセスするのに、いちいちインスタンスを生成してからアクセスしている」と思っていたのですが（そして、コンパイラが警告出すよね、と思っていたのですが）、違うのですね！「static を知らないから、いちいちインスタンスを生成して使用しており、笑ってしまう」だったのですね！！

　これは、ひどすぎるわ。

　ASP.NET でこれをやると、複数のユーザーが同時にアクセスしたときに、ほぼ確実に障害が出るはずだけどなぁ。まぁ、メソッド ローカルな変数しか使っておらず、グローバル変数としての認識の元にクラス変数を使っていたら、障害は防げるけど。

　全体的に、「俺、オブジェクト指向なんて覚えないもんね。それでもやっていけるから」って感じの文章なんですよね。で、それって、物を作る人として、どうなん？

> この人もこんなコラムを書いていたのですね。発見！
> http://el.jibun.atmarkit.co.jp/hidemi/2009/12/sql-4274.html
　う～ん。。。知らなかった物に対して、ひでみさんのは、肯定的。みながわさんのは、否定的。全然違うと思います。

> 私が何言っても説得性がないので、またリンク張ります。
> http://mag.autumn.org/Content.modf?id=20041027180339
　う～ん。。。川俣さんて、@ITで、VB.NET解説の連載をされていたような方ですよ。そのような、「オブジェクト指向を理解した人」と、あなたのような「オブジェクト指向を片鱗も理解していない人」が、同じような事を言ったからといって、言葉の深みが違うのですよ。また、そのページの最初には、このように書かれています。
> 　これは思いつきのメモなので正しいという保証はありません。むしろ正しくないと思う方が正しい態度でしょう。
　「正しくないと思う方が正しい」、つまり、そのページに書いてあることが「正しい」と思ったあなたは、間違っているでしょう。

　どこかでも書いたことですが、コラムって、「新聞・雑誌などで、短い評論などを載せる囲みの欄。」って意味なんですよ。で、評論って、「物事の善悪・優劣・価値などについて批評して論じること。」なんですね。で、何処で、優劣、価値などを批評（物事の長短・優劣などを指摘して評価を述べること。）しているのでしょう？本文は、ただの「感想」ですよね。

> http://wondsky.hp.infoseek.co.jp/vs2005.htm
　出来れば、「真似する前に考えよう」と、入れておいて欲しい。何でコードをセンタリングするんだろう？

> リモートマシンにも保存できるが、アクセス権がeveryone 書き込みになってないと難しい。
　こんな、脆弱にすることを勧めるような書き方は、やめて欲しい。

> sqlStr = sqlStr + " WHERE 情報 LIKE '%" + TextBox1.Text + "%'";
　こんな、SQL Injection 脆弱性丸出しのコードは、やめて欲しい。

> 以下のようなパーシャルクラスを作成する
　違います。パーシャル宣言によって、他のところでもクラスの宣言がされていることを示します。

> //sqlda = new SqlDataAdapter("SELECT * FROM books WHERE publish=@state", this.Connection);
> sqlda = new SqlDataAdapter("SELECT * FROM books WHERE publish LIKE '%' + @state + '%'", this.Connection);
> sqlda.SelectCommand.Parameters.AddWithValue("@state", state);
> //sqlda.SelectCommand.Parameters.Add("@state");
　コメントにされている組が、なんかおかしい、様な気がする。

> ＠パラメータを使ったLIKE　SQL文は書き方に注意したほうがいいです。
　「注意した方がいい」ではなく、その書き方を使ってください。

> 1行ずつのファイルの読み書き
> //内容をすべて読み込む
　1行ずつになってないやん！！

> EXCELを開く
　ASP.NET で Office アプリケーションを使用する事は、ライセンスの問題も含めて、推奨されていません。ここに掲載されているコードでは、オブジェクトが解放されずに残ってしまいます。

> sqlStr = sqlStr + " WHERE 番号 = '" + ban + "'";
　またこんな脆弱性。あと、せめて、String.Format を使ってください。

> string MdbLocation = Server.MapPath("DATA") + "\\" + "地名.mdb";
　これでもいけますが、System.IO.Path.Combine を使いましょう。

> Label.Text = "リンクyahoo";
　これも、脆弱性に繋がるので、要注意。（あ、@ITは蹴った）

> テーブルの大きさを変える方法
　その前に、モードの設定が必要でしょ？

>　ASP.NET でこれをやると、複数のユーザーが同時にアクセスしたときに、
>ほぼ確実に障害が出るはずだけどなぁ。
>まぁ、メソッド ローカルな変数しか使っておらず、
>グローバル変数としての認識の元にクラス変数を使っていたら、障害は防げるけど。

「メソッド ローカルな変数しか使っておらず」これが自然なことだと思ってました。メソッド関数なんですから、関数的な使い方するのが自然ですよね。それはint.Parseを使うと同じようなものです。

SQLインジェクション防止のために、MSはMSDNユーザーに＠のパラメータの使用の推奨をアナウンスをしていますから、Jitta様のご指摘はごもっともです。

みながわさんさあ、もう痛々しくて見てられないよ。
何書いても同意を得たり尊敬したりしてもらうのは無理だと思うよ。

なんかWikiPediaから引用しちゃったりして、結局何もわかっていない方が自分より無知な方に何かを教授しようとして、やっちゃった感丸出しの結果になってしまったということでしょうか。

ざっと見て思ったのですが・・・

1.オブジェクト指向プログラミング言語において、オブジェクト指向プログラミングの基本を学習せずに来てしまった。
2.そして、自分の間違った知識を、あたかも正しいかのように多くの人が見る場所に書いてしまった。
3.更に、コメントでのやり取りでは、いくつかの問題のある発言をしてしまった。

みながわさんは、この 3 点について、きちんとした決着を着けた方が良いと思います。

1.については、どちらでも良いです。
このまま、オブジェクト指向プログラミングについて学習せずに、生き残れると判断するのであれば、そうすれば良いでしょう。

2.については、記事の中で、自分が不勉強で間違った見解を持っていたことを明記した上で謝罪すべきだと思います。

3.については、コメント中の問題発言の部分を明らかにした上で、きちんと謝罪すべきだと思います。

確かに、コメントのなかには非礼で子供じみたものも多く見受けられます。
そのような人に、礼を尽くすことに抵抗を感じる気持ちもあるでしょう。
しかし、それは、ほんの一部にすぎません。
多くの人は、黙ってこの場を見ています。
そういう多くの人たちに対しても、ご自身のコメントによって嫌な気持ちにさせてしまったことを認識すべきでしょう。

それと、みながわさんが終わりとか、読む価値～、などと言っている人もいますが、これは人それぞれが評価することだと思います。

みながわさんが、この年齢までシステムエンジニアを続けてきたことについては、素晴らしいことだと思います。
また、そういった経験を語ることによって、多くのエンジニアが、この業界で長く仕事をするためのヒントを得ることもあるでしょう。

コメントを読むと、同じ業界の先輩に対する礼儀を欠いている幼稚なコメントも少なくありません。
みながわさんは、一部の人を除けば、おそらく皆さんよりも多くのソフトウェアを開発してきているはずです。
そういった人が間違ったことを言ったとき、その点について攻めるのは良いでしょう。
しかし、人格批判などをはじめとした必要以上の責めはいかがなものでしょうか？

人を攻める前に、まずは自分が人として大人として正しい言動ができているのかを振り返ってみると良いでしょう。

結局オブジェクト指向は使えないってことでいいんですよね？

みながわ氏が、オブジェクト指向や、オブジェクト指向プログラミングに関して無知に等しいことは、本文を読めば誰でもわかります。

また、みながわ氏ご本人も、そのことはコメントの中で認めていらっしゃいます。

したがって、オブジェクト指向やオブジェクト指向プログラミングに関する知識が無い人が記述したことを明記していただく必要があります。
そうしなければ、本文を読んだプログラミングの初学者が「インスタンスを生成することが馬鹿げていて、すべてスタティックなクラスを宣言すべきだ」という誤った認識を持ってしまうことになるでしょう。

結局、開発ルールという企業文化の問題でしょうね。
すべてクラスについてはインスタンスを生成することを前提としてstatic を禁止している企業もあれば、static で関数が使えるところは積極的に使うという企業もあるということじゃないんですか？
誰もこんなコラムでプログラミングの初心者が勉強しませんよ（こんなコラム読んでるなんて仕事してないか勉強さぼってるとしか思われませんよ）。

@IT担当者殿へ
はやく、本コラムおよび、みながわ氏のブログは全て削除して下さい。上記の方が書いているように、初学者がこのようなコラムをよんで、勘違いしてしまったらどうするのですか？？

@IT全般の記載内容のレベル低下を感じる今日この頃ですが、特にエンジニアライフはひどいです。みながわ氏に限らず、客観性に乏しい記事が乱発され(例えばSQL関連の方とか)、少しでも批判があると、批判者を罵倒するといった行為がまかり通っています。

@IT的には、自分達ではなく外部の人間が勝手に書いていると言いたいのでしょうが、主催されているのは@ITですので、そのような言い訳は通用しません。
内容の良否を判断できない初学者からすれば、このような内容を無批判に受け入れてしまう危険性もあります。
私も、以前は周囲に@ITを推薦していましたが、最近はもう止めました。

これ以上信用を失う前に、早急に改善されるほうがよろしいかと思います。

こんにちは。
初学者がこのコラムを読むと悪影響を被る、だから削除すべし、という意見があります。
仮に悪影響説が正しいとして、こんなWebでタダで読めるコラムからいちいち深刻な悪影響を被るような、メディアリテラシーに欠ける者は、本コラムを削除したとしても、遅かれ早かれ間違った方向に育ってしまうのは確実なので、削除措置に意味は無いと思います。

@ITもこれを連載化して、日経の「動かないコンピュータ」みたいなシリーズにすればいいのに

はじめまして。

個人的には、ここは技術情報のサイトではないので悪影響は少ないと思います。
しかし、「エンジニアライフ」なので、悪影響の有無に関わらず、技術論を展開
するようなコラムは不要ではないかな、と。

おそらく編集者さんは、編集のプロであってエンジニアとプロではない（と思う）ので、
有益であるか否かを判断するのは無理でしょう。
また、コラムにあるコメントの流れから、いったん掲載したコラムを削除するのも、
コラムニスト、掲載した@ITのそれぞれが傷つくことになるのではないでしょうか。

なので、主張の正否を問わず、技術的なコラムは最初からはじいてしまうのが良いのではないかなと思います。

ぬ氏
> 仮に悪影響説が正しいとして、こんなWebでタダで読めるコラムからいちいち深刻な悪影響を被るような、

タダで読めるものだから劣る、有料だから優れているというものでは
無いでしょう。
現に、@ITでも、そこそこ役に立つ読み物はありますよ。

> メディアリテラシーに欠ける者は、本コラムを削除したとしても、遅かれ早かれ
> 間違った方向に育ってしまうのは確実なので、削除措置に意味は無いと思います。

うーん、そこまでできる人間だったら、既に初学者では無い気がするな(笑)。メディアリテラシーも育てるものでは？
人間なんて簡単に洗脳される生き物です。ここ(@IT)が無名のサイトならいざ知らず、幸か不幸かそこそこ名が知れている状況で、変なことが書いてあると、それを信じる奴も出てくるわけで。

ということで、次はメディアリテラシーの講座をお願いします。＞@IT担当者殿
あっ、間違っても「エンジニアライフ」はサンプルにしないようにね！

みんな、「みながわ」のたぬきおやじに釣られすぎてるなあ。

このおやじの経験からすれば、当然、staticを使えるケースと使えないケースなんて会社のコーディング規約になっているに決まってるじゃん。

たぬきおやじ、コラムでもコメントでもとぼけたこと言ってるけど、会社のコーディング規約なんてマル秘情報だから、こんなとこで書くわけないじゃん。逆に、IS部門のサラリーマンなんてマル秘情報出したらヤバいわけ。

だからボケたコラムばっか出してるんじゃないの？
「初心者が見て勘違い」なんて、お前の会社のコーティング規約はどうなってるの？　と疑問視しちゃうわけ！

＠ITのエンジニアコラムって、デスマーチとか、この人自殺しちゃうじゃないかな、なんて業界にネガティブな印象を与えるものが結構あるので、もうどうでもいいんじゃないですか。見ても無視すればいいってことよ！

生島というコラムニストがここのコラムについておかしなこと書いてるよ。
たぶん、自分のコラムに誘導する釣りなんだろうけどさ。
http://el.jibun.atmarkit.co.jp/g1sys/2010/05/post-9262.html

悪影響があるから削除論＞
これだけ反論のコメントが付いていれば、読んだ人が初学者でも鵜呑みにしにくいと思いますので、そうなればむしろ残した方が教育上よろしいんではないでしょうか。

鬼塚氏＞
コーディング規約ごときが丸秘って本気で書いてるの？
というかstaticの使いどころを規約で統制するってのも実際的でないような…。

＞神戸氏
それこそ釣りだって（ｒｙ

何気なく見てて、あれよ々という間にすごい事になっているので、書き込みを躊躇していましたが・・・

私はオブジェクト指向という事が良くわかりませんので、じつはこれもいいのか悪いのか判らずに読んでいました。
自分が担当したシステムに当てはめた時、オブジェクト指向になっているかどうかが明確にわからないのです。
自分が考えているオブジェクト指向っていう考えがあっているかも判っていません。
なので文中に出てくる「結局、アルゴリズムだよ」的な発言を見たとき、
「そうだよね。メンテする側の事も考えて作っていく中で以下にバグを少なくするか、
効率的に仕事が進められるかが問題なんだよな」という感じで内容の細かい所以外が印象に残りました。

批判コメントを書いている方は、なんか、ただ突っ込み入れたい感じになっているだけに思います。
内容がないかどうかは、それぞれのレベルでも変わるし、ほんの1文でも心に残ったり、はっと思ったりすることがあれば、そのコラムは私はよいものだと思います。
もちろんなにも引っかかるものがなくてもいいです。
ここに書いている方はエンジニアであってもコラムニストではないので１００％に近かったり、正のみを発信しないといけないという事はないのだと思います。
当然、好き嫌いも個人の好みの問題だと思います。わざわざムキになって書き込む事ですか？
もし、ここに書いてあることが間違っていてもそれでいいのではないでしょうか。
信じた人がはじかいちゃったり、失敗しちゃったりしたらそれは、やっぱりその人の責任だと思いますよ。
それ以外の情報も吟味しないで失敗するほど何もしなかったという事だと思うので。
それに間違ったら間違いでもいいじゃないかと思います。間違ったら学べて良かったと思うけど。
個人攻撃と傍からみてて思うような書き込みは適切でないと思います。
かなり狭量な範囲でのやり取りになっていると感じます。
議論にもなっていないので単純にやめて欲しいです。

>「そうだよね。メンテする側の事も考えて作っていく中で以下にバグを少なくするか、

以下にでなく「いかに」でした

よみこさん

>Jitta 2010年5月12日 (水) 22:17
>　ASP.NET でこれをやると、複数のユーザーが同時にアクセスしたときに、
>ほぼ確実に障害が出るはずだけどなぁ。
>まぁ、メソッド ローカルな変数しか使っておらず、
>グローバル変数としての認識の元にクラス変数を使っていたら、
>障害は防げるけど。

この障害防止することを「スレッドセーフ」と言っています。
以下のリンクの１番に「参照のみと言う場合を除き、静的な変数は扱わない。」と書いてありますよね。

http://okwave.jp/qa/q5320569.html

しかし、みながわのおやじは、Jittaさんから指摘される１０日も前に以下のようにコメントしていて、スレッドセーフなプログラムにしているのです。

>みながわけんじ 2010年5月 2日 (日) 00:07
>static変数ではなくstatic関数はよく使います。
>引数のみから単純な論理でリターン値を返すものなので、
>他のセッションの影響は論理的に考えてないはずです。

もちろんインスタンス生成してスレッドセーフにする方法もあるでしょう。

ここのコラムのコメントの内容は雑音を除き非常に意味のあるものばかりなので、よみこさん理解できるようになってくださいね。

>みながわけんじ 2010年5月 2日 (日) 00:07
>static変数ではなくstatic関数はよく使います。
>引数のみから単純な論理でリターン値を返すものなので、
>他のセッションの影響は論理的に考えてないはずです。

スレッド間で共有されるオブジェクトや変数がなければ、そりゃスレッドセーフには違いない。違いないだろうけど、スレッド間で情報をやり取りする方法もないってことだよね…。そんなメソッドばかりで事が済むとは思えないんだけど。まぁ既製のフレームワークを使っていれば、その中に隠蔽された利用者からは見えないところでスレッド間の共有がなされている場合はあるだろうけど。

ログ自体は残すべきでしょうが、
みながわ氏、追放ものでしょう。
記事の程度の低さはまだいいとして、アカハラ&パワハラ的な発言してそれに対してなんのフォローもしてませんからね・・・。
(その意味だと某ベンチャー社長も・・・)

> (その意味だと某ベンチャー社長も・・・)

その某ベンチャー社長も、自爆した挙げ句、コメント終了になってるよ。
程度はどっちも似たようなもんだよ。

コメント欄を閉じない分、みながわさんが偉いと思えてきた。

うん、

＞理解力・日本語力のないカスの相手は精神的に大変です。

でコメント欄を閉じる生島さんと比べれば、まだ人間性を問うことができる。

こんばんは、はじめまして。生島さんのところで炎上を紹介されていたので来てみました。

　技術者ではないし、IT業界の住人でもない普通の事務職なので、技術的なお話はさっぱりなのですが、本文とコメント欄をざっと読んでみた限りみながわさんのネットリテラシーが心配になりました。

　自分がよくわからないことを書くときは、突っ込まれることを前提に間違っていたらごめんさいという低姿勢で書く、自分と異なる立場の人を尊重する、というのは大切だと思います。そして、それができそうにないときは匿名で書くのが大切ではないでしょうか。匿名での議論なら誰も（自分も、相手も、周囲の人間も）ネットの外で傷つくことはありませんし。

　私は、ときどきネット上で年金や健康保険の制度議論をします。10数年会社で、給与や社会保険関係の事務をやっていたところで、本職の社会保険労務士さんの法の条文まで網羅するような知識にはかないませんし、役所で国民健康保険や国民年金の担当をしていらっしゃる方のものの見方は制度を別の角度から見るのに役立ち刺激的です。
　
　すみません、話がそれましたね。
　生島さんの最新のアレに比べればまだ議論になっているし、見る価値のあるコラムと思いました。

某ベンチャーのコラムを読んできましたが、生の感情を文章に叩きつけている様で子供だなぁと思いました。

これらのコラムを読んだ読者がエンジニアって子供だなぁと思われてしまう訳で、何とも言い難い罰の悪さを感じます。

神戸さん

神戸さんのような高度な知識の方には、Webアプリケーションの作り方なんて低レベルなことかもしれませんが、

>みながわけんじ 2010年5月 2日 (日) 00:07
>一度レガシーASPでsession変数で定義すべきところを
>application変数で定義し痛い目にあってます。

とみながわさんは書いてあります。このapplication変数がWEBアプリケーションでスレッド間の情報をやりとりするものです。逆にスレッド内でWEBページ間のやりとりをするものがsession変数です。もう知っていたら素人の余計なおせっかいだと思うのでごめんなさい。

＞理解力・日本語力のないカスの相手は精神的に大変です。

理解力・日本語力がないのは生島だろうって突っ込みはおいといて。
生島のコラムを見た後でここを見るとここが実は非常に有意義なコラムであることに気づく。
どれだけたたかれても自説を曲げず、コメントを閉じないことで、
結果的に非常にわかりやすいコメントがそのまま残っている。
生島コラムと比べても、生島とみながわさんを比べても、
すべての面でみながわさんが勝っているな。

ところでふと気になったのが、
生島って例のブログ市長に似てない？
見た目もそうだけど、やり口が。
http://spysee.jp/imgcache/25735458/%E7%94%9F%E5%B3%B6%E5%8B%98%E5%AF%8C
http://tokotonmame.banzai.cx/index.php?p=&d=blog&c=&type=archive&dt=201003&pg=6

試合に出ない(発言しない)選手の評価がどんどん上がるとは、秒刊を見ているような気分です。

>ブリお得 2010年5月17日 (月) 21:34
>コメント欄を閉じない分、みながわさんが偉いと思えてきた。

数日で発言機会が過去に沈んでしまう某/.と違い、コラムニストさんが受ける限り半年でも１年でも、米に応じるというのは、１つのニッチとして有望なんでは無いですかねぇ。。

ここといい、生島コラムといい、エンジニアライフ自体が実はドッキリ炎上企画で、コラムニストの内数名は２ｃｈあたりから特に不快な人をスカウトしてきたんではなかろうか、と本気で、いや本気で思ってしまいます。それくらいあり得ない方々・・・。

>aun 2010年5月23日 (日) 01:19
>生島コラムといい、

実は大したことしてないんだけど、誇張や恫喝を織り交ぜつつ、さもすごいことをしているという幻想を与え、それを視野の狭い信者が熱狂するという構図…、あそこって、まさに宗教とか独裁国家みたいなもんですよね。
まっ、普通の常識を持った技術者からすれば、「アホか…」で終わりだけど。

ただ「プロフェッショナルなIT技術者・管理者のための…」じゃなかったんだっけ？@ITは。
ちなみに俺の中で@ITは、「とんでも情報技術サイト」って位置づけになってるよ。それでいいんだっけ？

みながわさんさあ、生島さんのコラムでどーでもいいコメントしているヒマがあったら、こっちを何とかしたらどうだい？
言っておくけど、いまさらみながわさんから、何かを学びたいなんて人はもういないから安心していいよ。反面教師的な学びを求めている人は別だけどね。
何らかの決着はつけるべきじゃないかな。

生島さんは、ついにコラムニストから除名されたそうだよ。

http://blogs.wankuma.com/jitta/archive/2010/05/28/189520.aspx
みながわさんのご意見をいただきたく。

どうにもみながわさんは時間切れを狙ってるような気がしますね。
生島氏のとこに頓珍漢なコメントをする暇があるのにこっちやCPUのエントリはほったらかしですからね。
ところがどっこい、ちょくちょく覗いてたりするのですよ。

>Jittaさん
直リンだめっぽいですよ。

@IT担当者殿へ

生島氏除名の件、素直に評価する。ただ、他のエンジニアライフの各コラムも、自主出版の自叙伝みたいなもので、レベルが低く見るべきものがほとんど無い。止めろとは言わないが、どうなの？とは言っておく。

生島氏へ（見てないかも知れないが）

他社のサイトで「炎上マーケティング」(笑)とか幼稚なことをしてないで、自社のサイトでブログを作成し、堂々と自分の意見を主張してみろ。
http://www.g1sys.co.jp/
本当に、自分の言っていることが正しいと自身を持っているならば出来るはずだし、最高のマーケティングになるはず。

「炎上マーケティング」のおかげで、そこそこ名前が売れたはずだから、人はたくさん集まると思うぞ。

生島さん、人気あるんですねー。
わざわざ他者のコラムで読んでくれないかも知れないメッセージを送るなんて、ほとんどストーカー化してるファンが、、。

ここをはじめ、いくつかのコメント欄を放置して荒れるに任せた@ITにも責任があると思うな。

方針も二転三転して信頼が置けない。

暴言という点では生島さんよりみながわさんの発言の方が問題あると思うけど、
こちらは除名無し？

AC/DC さんへ

インスタンス ・・・　実体

static ・・・　静的

何かの冗談？
だとしたら、全然おもしろくない。

っていうか、そんなのもうどうでもいいんだよ。

学歴とか「私は客だ」発言についてはどうなのさ？
ここまで炎上した原因、わかってるかい？

> Jitta 2010年5月28日 (金) 22:31
> みながわさんのご意見をいただきたく。

遅くなりましたが、みながわさんより5/31にメールにてご感想をいただきましたこと、報告いたします。

みながわさんへ：
私はここで、多くの人の目に触れるように、書き込みを行いました。ですから、多くの人の目に触れるように、読んだことをアピールしていただきたいと思います。
また、コメントを投稿するときに入力するメールアドレスですが、無効なアドレスでも受け付けられるのではないでしょうか。試しに、今回は無効なアドレスを記してみます。そうすると、このアドレスに対してメールを送っても、相手に届くかどうかはわかりません。ここ、もしくは私のブログのコメントにて、お送りいただきたかったです。
今回いただいたメールにて、本文中の一部の表現について、書いてある情報が少ない故に読み手に誤解があることがわかりました。できれば、本文を読む多くの人の目に触れるようにしていただきたいと思います。

生島氏はこちらで再開したようです。

http://d.hatena.ne.jp/Sikushima/

人間性とかではなく、純粋に技術的なやりあいを見てみたいです。