二度目の３連休、そのうちお休みがもう２〜３日増えて秋のゴールデンウィークにならないかな、と思う今日この頃(^^;;またも台風接近＆暑くなったり寒くなったり、いい気候でもあり、体調を崩しやすいシーズンでもあり、皆さまいかがお過ごしでしょうか？アメリカでもまたもハリケーンが南部直撃だそうですね。あのハリケーンてのはアルファベット順の女性の名前らしいので、前のカトリーナはＫ、今回のリタはLitaなのかRitaなのかわかりませんけど、Ｌなら連続ということになります。きっとアメリカが京都議定書を批准するまでハリケーンラッシュがつづくに違いありません(x_x)
さてさて、前回以来いろいろ細かいことから大きいことまで内容について検討してきました。で、内容変更に伴い、変更事項をオブジェクト設計図としてのクラス図に落としこむと……書き落とすと…なんだかしっくりきません(~_~;)もともと、このクラス図をもとにプログラムを組むことになるんですけど、プログラムを動かすにあたっての細かい内容は、図に入れてしまうと見づらいのできちんとはいれていなかったのです。大まかな内容だけ入れていれば、細かい内容はおのずから明らかになる……
……わけはなく、プログラムを書いているうちに、だんだん細かい内容が交錯してきて、全体の見通しが悪くなります。そうなってくると細かい内容もプログラムに直接書くんでなく、クラス図で表現したくなってくるんですよね。だいたい、家を１軒造るのだって、プラモデルを作るんだって、設計図があります。ひとりプログラムだけ設計図なしでやっているのか、というと、これがそうやっているようなんですね(~_~;)プロのプログラマー(^^;じゃないので本当のところはわかりませんが、とはいえ、プロのプログラムというものがどういうものかというのがよく本になったりしています。
それを読んでみると、これがなかなかすさまじい世界のようで…(x_x)まずもってとにかく動けばよい、と、とんでもなく複雑なプログラムを書いて、他の人はおろか、書いた本人すら何を書いているのかわからないことが多かったりするのは当たり前、顧客の仕様変更をＳＥ（私はこの職種の人って、しすてむえんじにあ、というより単なる営業の人のような気がするんですけど…）が安請け合いしてきて、連日徹夜なのが連日徹夜になり（同じか(^^;）死にそうになったりだとか…知的な制作者というより、ある種の肉体労働者で、この業界からの転職者を私もなぜか結構よく知っています(^^;;で、やめた理由はというと、あまりにきつくて体壊す（壊した）から、と(*_*)
そんな世界なので、設計図もへったくれもなく、とにかく動きさえすれば良いと、身を削って１行１行書きなぐっているのが実情……新しいWindowsVistaだって、特に登場が遅くなってます。WindowsXPの標準保守期限は実は発売後５年、来年中頃なのに、新しいWindowsVistaの登場は来年末頃。保守期限を明示しているくせに、一時的とは言え、保守がない製品しか一般向けに販売しないのがまいくろそふとという会社のようです(~_~;)プロ中のプロだってこんなもんですか、はあ。
Windows95以来、OSも、まだまだ実はＣ言語で書かれている部分もあるらしいところ、現状多くの部分はオブジェクト指向で作られているようです。そこまでオブジェクト指向が主流となっていながら、プログラムとは別の設計図というものを、どう書けばいいのかはっきりしていないという気がするのです。
確かに方法はあります。私が学んだ、これまで何度も登場した『オブジェクト指向開発講座』においても、まず、要求仕様を文章で書き、コンピュータ自体の内容、たとえばどう表示させるとか、ＯＳは何かといった内容を除いて、要求されている問題領域そのものに注目する、と。その中の名詞に着目し、名詞をオブジェクト候補としてピックアップして図に描きます。それぞれどう関連しあうかを要求仕様を詳細化しつつ検討しつつ、考え考えしながら表現していきます。
で、そのオブジェクト図（クラス図）が問題領域そのものを表現し、要求仕様を満たす、つまり問題が解決できているところまで練り上げます。そうしてはじめて実際のプログラムに移るんですが、当然動くプログラムを作るために必要な内容を含めて、再びオブジェクト図に戻って設計図を再び練り直すことも、オブジェクト指向ならば容易だ、とされています。
容易だ、です。オブジェクト指向自体これまでのプログラム手法より変更に強く、図を練り上げながら、また、作りながら、また図に戻って精査しなおすことが容易だ、ということです。容易だ、です。繰り返しますが、容易だ、です。
まあ、作っている間に練り直すことが容易なのは確かにその方がいいんだと思うんですよね。設計段階がすぎて製作段階に至れば、二度と設計段階に戻れない、となると、設計どおりいかなかったとしたら、設計を無視して無理やりつくるか、全部おじゃんで一から設計し直しになるか、ということになります。先程のお話、今のプロのプログラマーの世界というのは、どうやらこうなっているようなのです。まず、設計自体が完璧でない。客はプロのプログラマーでも設計屋でもないので、要求をきちんと伝えきれません。逆に、ＳＥはじめ開発サイドも、客の仕事のプロでないので、要求仕様が正しいのかどうか、きちんと表現できたのかどうかわかりません。そんな中でできた設計は、当然完璧なものとはほど遠いのです。ただ、プログラマーは、そんな設計どおり、とりあえずつくることはできるのです。ところが、その仕様、設計自体が客の真の要求とずれています。ずれていれば、ここをこう直してほしい、という要求がすぐに登場します。これは、もともとの意思疎通にせよ、設計にせよ、完璧でないので仕方ありません。
しかし当然、プログラマーはもともとの設計で動くようプログラムしています。ここで当初の設計と違う内容を製作できるように…なっていればいいんですけど、ほら、なっていないと、設計を無視して無理やりつくるか（だからとんでもないことになる）一から作りなおすか（だから納期なんて守れない）、ということになって、徹夜につぐ徹夜につぐ徹夜で、体を壊すことになります。発展途上の世界という感じですね。まさに現代版女工哀史というかなんというか…(ToT)
となると、オブジェクト指向のメリット、製作から設計に戻ることも容易、という点が生きてくる、のです(￣^￣)………しかしですな、本来設計段階でうまく仕様を満たしていれば、こんなことにはならないのです。たいていの特注システムより、市販のプログラムの方がはるかに安く、はるかに高機能だったりするのは、作りたい人間と作っている人間が同じか、似た発想を持っていて、仕様がはっきりしているからです。ということは、特注システムにおいても、いかに意思疎通ができて、いかにうまく仕様を反映させることができていれば、それなりにいいものができるはずなのです。
そのためには、どれだけうまく仕様が設計に反映できているか、ということも大きいのですが、うまく反映できているのかどうか、実際のところはよくわかりません。わからないのです。ここが気になるところです。だから、繰り返して設計図を練り直すことが容易なことがメリット、ということになります。メリット、なんですが、容易ということは、残念ながら、試行錯誤しなきゃやっぱりできない、ということとイコールだったりします。
要するに、その設計でいいのかどうかは作ってみなきゃわからない、だから作ってから作りなおすことができることが容易！ほら便利でしょ！！って、ねぇ(~_~;)それはいくらなんでも何かが違う気がします。プラモデルにしても、家にしても、正しく完成していればこう、という、その設計図とは何か別の基準があります。設計図どおり作れないプラモデルだとか、設計図どおり建ててみれば倒れる家だとか、そんなのではだめなんです（￣□￣；）作ってから作りなおすことができるってのは、この接着剤は簡単に外せますよ、とか、倒れそうになったらつっかい棒をサービスしますよ、とか、そういうことを言っているのと同じなのです。そうじゃなくて、正しく完成する設計図がほしいわけです。
なんとなくもやもやしていた疑問がようやくはっきりしました(^O^)つまり、正しい設計図、正しいオブジェクト指向図とは何か、どういう基準であれば正しいとわかるのか、そこがよくわからなかったのです。作り直しが容易だから、作ってみてから作り直してね、とか、試行錯誤していけば自ずからいいものができる、とかではいかんのです(@_@)
一時期新刊のオブジェクト指向本が少なかったのですけど、最近また増えてきました。ただ、わかる！系が多いのが気になりますし、『オブジェクト指向開発講座』以上にほんとにわかるか、というとどうも疑問な感じです。わかる！系、ある程度わかっている人間が見ると、これだけでわかるんかいな？という感じがよくわかります。短くまとめても必ずしもわかるわけではない、というのは、受験勉強でもパソコン本でも同じ。わかるように書いてくれないとわからないものはわからない。類百の中『オブジェクト指向開発講座』以上にわかる本は少なく、かつ、この本以上の内容が書かれている本はない…？
が、ありました(^O^)『ーデザインパターンとともに学ぶーオブジェクト指向のこころ』（アラン・シャロウェイ＋ジェームズ・Ｒ・トロット著、ピアソン・エデュケーション、3,800円＋税）です。寡聞にして聞いたことがない社名＆2005年9月20日初版という、まさに窮すれば通ず、出会うときは出会うという典型ですね。最近普段本屋に行ってなかったのに、久々行ってみたら、すぐ出会ったという、いや、なんというか(^O^)
こんな高い本（レシートには辞書と書かれていた…）＆翻訳はたいてい読みにくい、という、買うにしては躊躇しやすい条件がそろっていながら、珍しくろくすっぽ立ち読みもせず、速攻買ってしまいました(^^;;というのも、このフレーズです。「私の失敗は、問題領域からクラスを抽出し、その後、それらクラス群をつなぎ合わせて最終的なシステムを作ろうとしていたがために起こったのです。」（まえがき）
まさにもやもやしていたところそのものじゃあないですか（￣□￣；）『オブジェクト指向開発講座』でも、こうする、と、されていたこの方法、失敗！？ほら、買いたくなるっしょ？(^^;;翻訳本とは思えない読みやすい文体、わかりやすい内容、『オブジェクト指向開発講座』も結構読むのに時間がかかったというのに、この連休中であっと言う間に読み終えてしまい、名残惜しい内容、珍しく名著です。オブジェクト指向というものの解説は少ししかないので、まったくオブジェクト指向を知らない人には向きませんが、少しでもかじった人、これまで開発していて、何かもやもやしたものを感じた人には絶対おすすめです。オブジェクト指向未経験の人でも、『オブジェクト指向開発講座』と、『オブジェクト指向のこころ』を２冊読めば、オブジェクト指向で開発できるようになれます(^^;;;
で、何が問題なのか。『オブジェクト指向のこころ』では、『オブジェクト指向開発講座』でも書かれていた、要求仕様から名詞を抜き出してオブジェクトとし、そのオブジェクトにあう動詞をメソッド（≒機能）とする、という方法論が、これではうまくいかない、とされています。なぜか。単純な話であり、私がもやもやしていたことと同じです。その方法では、単に最初に思いついたからそうしただけであることが多く、それが正しいとどうしてわかるのか？つまり、正しさに対する保証がないのです。とりあえずそれで作り、プログラムも完成してから、はじめて、失敗していたと気づくのです。まさに、おかしいおかしいと思いながら設計図どおり作ってみたら、やっぱり本物と似ても似つかぬおかしなプラモデルであったり、二階に足を踏み入れると、床＝天井が抜ける家であったりするのと同じ、とんでもない方法なのです。
実はオブジェクト指向においても、どういうものが正しいのか、昔から検討に検討を重ね、これが最も効果がある、有効な方法だ、というものがあります。それがデザインパターンと言われるものです。私も気にはなっていたのですけど、各種のデザインパターン本は、なぜかなんだかよくわからないなあ、というものでした。わからないのもそのはず、本家デザインパターンは、そういう検討を重ねていったコミュニティ向けの本であって、十二分に経験を積んでいる人向けの本だったからだそうです。オブジェクト指向初心者の私が見ても、なんでそうなのかわからないのもそのはず、試行錯誤を繰り返していた人々が練り上げに練り上げた、究極のエキスがデザインパターンなのです。その本家がはっきり書いていない（書かずとも当然、という人向けの本なので）ゆえ、その解説本、解説サイトも、はっきり書けていません。それどころか、デザインパターンについては、結局使えないだとか、デザインパターンに従うあまりうまく書けなくなったとか、悪評も漂っていました。私自身、読んでもさっぱりわからず、どう使えばいいのかわかりませんでした。
それがはっきり、なぜデザインパターンがいいのか、どうしてわかるのかが『オブジェクト指向のこころ』なのです。いやあ、すっかり宣伝になってきていますが(^^;;これは、デザインパターンを使ったオブジェクト指向学習書なんです。学習にとって最適とされる欄外小見出しも使われ、読みやすくなってます。後で使いやすく探しやすいんです。いいですね〜(^O^)
と、すっかり長くなってきたので、これを実際の開発にどう使おうか、というのは次回まわしとして(^^;;デザインパターンが開発にとってどういいのか、です。要は、型なんです。Typeじゃあなく、武道やなんかで重視される、型です。オブジェクト指向が現実の問題領域を写し出す設計図だとしても、現実をまるまる表現できるわけはありません。私が昔検討したように、問題領域を抽象化によって表現する以上、現実そのものではありません。
抽象化とは、ことばがまさにそれでした。たとえば家ということばが、赤い屋根の隣の家や、私の家そのものを表せないように、けれども赤い屋根の隣の家や私の家の両方を指すこともできるように、抽象化しているのです。現実そのものではない、つまり、共通化したものだけを切り抜くのが抽象化という方法である以上、切り抜き方によって大きく異なる、そして、その切り抜き方の中で、精錬されてきたものが、デザインパターン、と、こういうわけなんです。
武道も型によって流派が分かれ、良し悪しも分かれてきたように、デザインパターンも絶対完璧なわけはありません。完璧な武道の型があればそれは無敵ですけど、そんなことはなく、型だけでは実戦では戦えません。デザインパターンも同じです。型だけはしっかりしていると揶揄があるように、デザインパターンも、それを墨守することがよいデザインになるわけはありませんね。とはいえ、型だけでも、無手勝流よりは戦えるかもしれません。逆に喧嘩作法で上り詰めることもあります。それでも、型を極め、型を超えた達人には歯が立たず、その達人の下で修行して強くなる、というのは、この手のお話の王道です(^^;;
要するに、型を学び、その中でなぜその型がいいのか、という型の神髄、奥義(^^;;を見だし、実戦では、型どおりではなく、型の精神を使って戦っていく、と、こういうわけなのです。で、オブジェクト指向のこころ、デザインパターンの精神は、というと、どうやらカプセル化、そしてオブジェクトは何をするのか、ということにあるようです。まだ型を学んだばかりの私には、なかなかうまく表現できませんが、次回、詳しく検討していきましょう(^^ゞ
｜index｜
このページへのリンクはフリーです。