気分はstatic！

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

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

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

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

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

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

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

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

いんやぁ、ここ１０年くらいは　クライアント、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 に対してロジックを記述するようなプログラミングしてたら、ポリモルフィズムは当たり前すぎて特に意識してないと思います。

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