コラム「システムエンジニア 生き残りの極意」でちょっとした祭りになっている件
"ちょっとした祭り"の実態は?
えーと、ソースはこちらです↓
とりあえず現時点でのこのコラムへのコメントのエッセンスを纏めます。
それよりも、ポリモーフィズムがオブジェクト指向の肝だと思います。
ポリモーフィズムをうまく使うと条件分岐の記述を減してすっきりしたコードが書けます。
ぬ様
貴重なご意見ありがとうございました。ポリモーフィズムについては勉強したいと思っております。
と正直思いましたが、それゆえオブジェクト指向がしっくり来ないのでしょうね。ポリモーフィズムについては、私は
「関数へのポインタ(C言語)のデラックス版を使って、何かをやる」
と捉えています。C言語において、関数をそのまま呼ぶのではなく、ポインタを通じて呼ぶようにすると、
「たまたまその時、どんな関数がそのポインタに指し示されていたか」
によって、結果がまちまちになりますよね。
この特性を意図的に活用すると面白いことができるかも知れない。
引数と戻り値の型は揃っているが処理内容がまちまちな関数をいくつか用意しておき、プログラム実行時、その時その時の事情に合わせて関数をチョイス(ポインタにセット)すれば、後はそのポインタを通じて呼び出された関数が、宜しく仕事をしてくれる訳です。さらに、複数の関数をまとめてポインタで扱えればより便利かも知れない。さらにさらに、その関数群の内輪だけで共通の定数や変数を持たせられればより便利かもしれない。(デラックス版)
ぬ様の最後に引用した箇所は恐らくGoFのデザインパターンのStateパターンを念頭に書かれているのではないかと想像します。
#全力で易しく説明しようとしているぬ様は神
何でポリモーフィズム(多態性)が必要なの?
10行×10列程度の状態遷移マトリックスを昔ながらの方法(if文、switch文での分岐)で実装すると可読性はかなり落ちます。100行×100列程度になると、もやは保守しつづけるのは神の世界です。
#今のシェアは知らないけど2000年頃はシェアTOPだった銀行ATMメーカでの話。
#多分、自動車のECUも似たようなものだと思う。
こんな分岐だらけのコードをステップ実行による全パス網羅のホワイトボックステストをやろうとすれば想像を絶する苦行になります。
#それでも実機を使ったテストよりもはるかに容易いのだが。
今ではコスト要件や性能要件が厳しい組込開発でしか意識しなくてもいいのかもしれませんけど、実行時に分岐すれば性能(実行スピード)にモロに響きます。
x86ではCoreアーキテクチャが主流になった現状からすると適切な例では無いかもしれませんが、NetBurstアーキテクチャのPentium 4はクロック周波数をひたすらあげるためにとんでもなく深いパイプラインになっていて、分岐でパイプラインが乱されたときのペナルティが大きいです。
(cf. NetBurstマイクロアーキテクチャ - Wikipedia)
以下の2つの
- 状態遷移マトリックスのセルの数だけ分岐ルートを作るのは、書くのもテストするのも保守するのも大変。
- 実行時に分岐を行うと性能が劣化する。
という問題を避けるため、状態に応じて事前に全ての必要な分岐を行っておくというアプローチが有効です。これをうまく実現する手段がポリモーフィズム(多態性)を活用したStateデザインパターンなのです。
Stateデザインパターンって何?
Javaを知らなくてもいいので、ここがわかりやすいんじゃないかなー?#C++が判り易いかというツッコミはあえてスルーw
Stateパターンを使うと、状態遷移マトリックスの実装が必須な組込とかのハードウェア制御系の開発効率が異次元に向上するの間違いなし!
#まぁ、大手は多分やってるよね。
ブログで書くのはしんどいので、気が向いたらスライド書いて、SlideShareに上げるかも。
ちなみに「オーバーヘッドが大きいからC++は使えないよー」みたいなお仕事でも、さっきのCodeZineの技を使えばC言語でStateデザインパターンが使えます。
「じゃあ、お前書いてみろっ」と言う方、仕様と時間を与えて下さい。あとは書くもののライセンス等に応じて、あなたの熱いハートかそこそこのお金*1が必要ですw
で、この仕組みで実装してあると、状態マトリックスの状態縦1列が1クラス、イベント横1行が1メソッドになるので見通しが非常に良くなる上に、ホワイトボックステスト(命令網羅&分岐網羅)がdJUnitなどで容易にできます。
Stateパターンで書かれたコードをxUnitでテストしたときのカバレッジレポートで命令網羅率や分岐網羅率が100%にするのと、それを分岐だらけのコードでデバッガでステップ実行して実現するのを比較すると、もうi8086とCore i7くらい開発効率に差が出るんじゃないかなー。
ちなみに、ググって資料さがしましたが、
#まぁ、でもNASDAQの取引システムはSQLServer+SQL CLRで実装みたいだけど。ところで、「みながわけんじ様」はどんなお方?
大学の専攻が情報工学ではなく電子工学なのでハードのほうが電子工学の知識が応用できると思ったからだ。以後、その会社をやめるまでハード設計の仕事につくことになった。といっても、やはり職場にはUNIXのワークステーションがあり、C言語を使ってハードの動作を検証するシミュレーションに大きな時間を費やしていた。
正しい道を歩まれた方のようです。
わたしがこのC/Sシステムの走りの時代に特に興味をもったものは、マイクロソフトのVisual Basic とリレーショナル・データベースであった。Visual Basic についてはGUIベースのアプリケーションを手軽に開発できるという意味で画期的だった。
また、コンポーネントの属性にプロパティというオブジェクト指向っぽい手法が取り入れられていた。オブジェクト指向はBASIC、 コボル、C言語の熟練プログラマーでさえ抵抗感があり、C++の入門書を読んでもピンとこない概念であるから、それを開発手法にとり入れることは非常に先駆的である。
このあたりで、M$にVBという麻薬を打たれてしまったようです。お気の毒に。。。
ところが、マイクロソフトのASPというものを知りノートパッドでコードを書き、IISの設定を行うことで動的なサイトが簡単に作れる! この手軽さから、わたしは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(_ _)mSEE ALSO
*1:愛知県最低時給に比べて十分に高い単価w