blogこの広告は、90日以上更新していないブログに表示しています。実はオブジェクト指向ってしっくりこないんです!とりあえず現時点でのこのコラムへのコメントのエッセンスを纏めます。それよりも、ポリモーフィズムがオブジェクト指向の肝だと思います。ポリモーフィズムをうまく使うと条件分岐の記述を減してすっきりしたコードが書けます。貴重なご意見ありがとうございました。ポリモーフィズムについては勉強したいと思っております。ポリモーフィズムについては、私は「関数へのポインタ(C言語)のデラックス版を使って、何かをやる」と捉えています。「たまたまその時、どんな関数がそのポインタに指し示されていたか」によって、結果がまちまちになりますよね。この特性を意図的に活用すると面白いことができるかも知れない。引数と戻り値の型は揃っているが処理内容がまちまちな関数をいくつか用意しておき、プログラム実行時、その時その時の事情に合わせて関数をチョイス(ポインタにセット)すれば、後はそのポインタを通じて呼び出された関数が、宜しく仕事をしてくれる訳です。複数の関数をまとめてポインタで扱えればより便利かも知れない。その関数群の内輪だけで共通の定数や変数を持たせられればより便利かもしれない。(デラックス版)ポリモーフィズム(多態性)を知らずにオブジェクト指向という単語を口にするなー!!!と正直思いましたが、それゆえオブジェクト指向がしっくり来ないのでしょうね。ぬ様の最後に引用した箇所は恐らくGoFのデザインパターンのStateパターンを念頭に書かれているのではないかと想像します。何でポリモーフィズム(多態性)が必要なの?10行×10列程度の状態遷移マトリックスを昔ながらの方法(if文、switch文での分岐)で実装すると可読性はかなり落ちます。100行×100列程度になると、もやは保守しつづけるのは神の世界です。#今のシェアは知らないけど2000年頃はシェアTOPだった銀行ATMメーカでの話。#多分、自動車のECUも似たようなものだと思う。こんな分岐だらけのコードをステップ実行による全パス網羅のホワイトボックステストをやろうとすれば想像を絶する苦行になります。#それでも実機を使ったテストよりもはるかに容易いのだが。今ではコスト要件や性能要件が厳しい組込開発でしか意識しなくてもいいのかもしれませんけど、実行時に分岐すれば性能(実行スピード)にモロに響きます。4はクロック周波数をひたすらあげるためにとんでもなく深いパイプラインになっていて、分岐でパイプラインが乱されたときのペナルティが大きいです。Wikipedia)以下の2つの状態遷移マトリックスのセルの数だけ分岐ルートを作るのは、書くのもテストするのも保守するのも大変。実行時に分岐を行うと性能が劣化する。いう問題を避けるため、状態に応じて事前に全ての必要な分岐を行っておくというアプローチが有効です。これをうまく実現する手段がポリモーフィズム(多態性)を活用したStateデザインパターンなのです。(1/3):CodeZineStateデザインパターンって何?Javaを知らなくてもいいので、ここがわかりやすいんじゃないかなー?#C++が判り易いかというツッコミはあえてスルーwhttp://www.geocities.jp/ky_webid/design_pattern/015.htmlStateパターンを使うと、状態遷移マトリックスの実装が必須な組込とかのハードウェア制御系の開発効率が異次元に向上するの間違いなし!#まぁ、大手は多分やってるよね。ブログで書くのはしんどいので、気が向いたらスライド書いて、SlideShareに上げるかも。ちなみに「オーバーヘッドが大きいからC++は使えないよー」みたいなお仕事でも、さっきのCodeZineの技を使えばC言語でStateデザインパターンが使えます。「じゃあ、お前書いてみろっ」と言う方、仕様と時間を与えて下さい。あとは書くもののライセンス等に応じて、あなたの熱いハートかそこそこのお金*1が必要ですwで、この仕組みで実装してあると、状態マトリックスの状態縦1列が1クラス、イベント横1行が1メソッドになるので見通しが非常に良くなる上に、ホワイトボックステスト(命令網羅&分岐網羅)がdJUnitなどで容易にできます。i7くらい開発効率に差が出るんじゃないかなー。圧倒的にJavaの資料が多い!C#の資料はあまりないんだけど。CLRで実装みたいだけど。ところで、「みながわけんじ様」はどんなお方?大学の専攻が情報工学ではなく電子工学なのでハードのほうが電子工学の知識が応用できると思ったからだ。以後、その会社をやめるまでハード設計の仕事につくことになった。いっても、やはり職場にはUNIXのワークステーションがあり、C言語を使ってハードの動作を検証するシミュレーションに大きな時間を費やしていた。正しい道を歩まれた方のようです。とリレーショナル・データベースであった。ついてはGUIベースのアプリケーションを手軽に開発できるという意味で画期的だった。コンポーネントの属性にプロパティというオブジェクト指向っぽい手法が取り入れられていた。コボル、C言語の熟練プログラマーでさえ抵抗感があり、C++の入門書を読んでもピンとこない概念であるから、それを開発手法にとり入れることは非常に先駆的である。このあたりで、M$にVBという麻薬を打たれてしまったようです。この手軽さから、わたしはVB開発はやめてASPによる開発を全面に押し出していった。CGIに比べれてASPは確かに先進的でしたが、独自ActiveXが必要なお仕事には不向きですね。言ってActiveXで部品化すべきロジック(=ビジネスロジック)を全部VBScript/JScriptで書いちゃうと*.aspのファイルサイズに応じてIISがメモリ喰っちゃうので、少なくとも大規模システムには向かない様ですね。インデントやコメントも含めて*.aspが丸のままメモリにロードされるみたいです。100MBくらいコメントだけの*.aspを読ませたら、IISのプロセスサイズが悲惨な事になりましたww#パフォーマンスモニタでメモリ使用量はかりました。ビジネスロジックをSQLServerのストアードプロシージャで書かない、かつて携わったそのプロジェクトのアーキテクチャが終わってた訳ですが。現在マイクロソフト製品による動的なサイトの開発の主流はASPではなくASP.NETになっている。個人的にはASPは非常に気に入ってが、現在ASP.NETでシステム開発を行っている。マイクロソフトはASP.NETに将来を託しているに違いないので、その路線に乗らざるを得ないってとこですかね。「みながわけんじ様」はM$に毒されてしまったお気の毒な方のようです。VisualStudioのせいで再起動させられた。8参加グループWindows開発者はてなブログをはじめよう!babydaemonsさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。