すごくすごくすごく大事で、これを理解しないとオブジェクト指向の恩恵の大部分を受けられないと言っても過言ではありません。
にもかかわらず、開発者が理解して使いこなせるようになるためには、ある程度の努力と経験が必要になってきます。
この話題に関しては、ソフトウェア開発と関係のない方のほうが、関門を越えていない開発者よりも、実は理解しやすいかもしれません。
ソフトウェア開発者というのは、なんでもプログラミングに直結して考えてしまいがちで、基本的な考え方がわかってないうちから、いきなり「プログラミング言語ではどう書けばいいのか？」と考え込んでしまいます。
どう書くかよりも、どう考えるのかの方が大事なんです。
考え方が理解できれば、書き方は後からついてきます。
開発者の方は、その順番を間違えないように気をつけて(というか、もう肝に銘じて)読んでみてください。
コンテンツ
同じようなインターフェイス
前回、インターフェイスの話をしました。インターフェイスとは、境目とそこでの約束事でしたね。
実は、世の中には、同じようなインターフェイスを持つものがいっぱいあります。
たとえば電源スイッチ。
電化製品のほとんどは、わりとわかりやすいところに電源スイッチを持っています。
全ての電源ボタンは、ぽちっと一度押すと、その電化製品が起動します。
もう一度押すと、電化製品は停止します。
全て、共通の操作方法を持ってるわけです。
だから、何かしらの電化製品を使い慣れてる人なら、他のほとんどの電化製品についても、電源を入れるくらいのことはできるわけです。
これがもし、ある製品は傾けると電源がつき、ある製品はスイッチを3・3・7拍子で押すと電源が切れるなんてことになると、もういちいち説明書読まないと電源も操作できないってことになりますよね。
第一、そんなの全部の電化製品分なんて、覚えてられません。
あなたも、今では当たり前のように電化製品を使ってらっしゃると思いますが、実はこれ、こういう共通のインターフェイスを持ってるからこそなんです。
昔、タッチセンサーでついたり消えたりするライトがちょっと流行ったりしましたね。
でも、最近ではあまり見かけなくなりました。
定着しなかったのは、こういう理由からかもしれませんね。
この電源スイッチのように、同じやり方で扱えるものは、他にもいろいろある。
くわしくは、わしの283ページに書いてあ～る。(ピ○ゴラスイッチ より)
というかんじで、私たちの身の回りにはたくさんの共通するインターフェイスがあります。
私たちが、新しい製品や初めて触れるものについて、それほど苦労することなく扱えるのは、このおかげなのです。
開発者の方は、ここで言っている「共通するインターフェイス」をあらためて定義したものこそ、プログラミングの際に宣言するinterfaceやprotocolであることを意識しておいてください。
記事Top結果は違う
さて、電源スイッチは共通するインターフェイスを持っていますが、その結果何が起こるのかについては、当然その電化製品が何であるかによって変わってきますよね。パソコンなら起動画面がモニターに表示されます。
テレビなら、前回電源を切ったときのチャンネルで、今放送されている番組が映し出されます。
ドライヤーならいきなり送風しはじめ、コタツなら温めはじめます。
このように、電源スイッチという同じインターフェイスを操作しても、それを受けつけるオブジェクトがなんであるのかに応じて、違う働きをすること。
これをポリモーフィズムと言います。
このとき、操作する側は常に同じ「あなた」です。
操作される側に応じて、結果が変わっているのです。
開発者の方向けに言い換えると、同じインターフェイスをインプリメントしているか、または同じスーパークラスから派生したクラスであれば、違うクラスのインスタンスを同じように扱うことができる。
そして、実際に扱ったインスタンスが何であったのかに応じて、結果が変わる。
ここ大事ですよ。
例えば顧客管理システムで、顧客に個人と法人が入り混じっていたとしても、個人のオブジェクトと法人のオブジェクトが同じインターフェイスをインプリメントしていれば、同じように扱えるということですよ。
たとえ個人と法人が同じ継承階層に属していないとしてもです。
そして、実際に扱ったのが個人なら個人のための処理が行われ、法人だったら法人のための処理が行われる。
そういうことなんですよー。
たとえば
前回、私たちの身の回りはインターフェイスだらけ…みたいなことを言いましたね。ということは、ポリモーフィズムもやっぱりたくさんあるんです。
あなたの生活に役立つように、これを利用しましょう。
例えば、あなたはXさんが好きだということを誰に打ち明けたいでしょうか？
- おしゃべりなAさん
- 話せばすぐに、みんなの知るところとなるでしょう。
公然の秘密にしてしまって、外堀から固めちゃいますか？
もう誰にでも相談できるようになるし、いろんな人が協力してくれるかもしれません。
Aさん一人に話せばみんなに伝わるんだから、便利ですね。 - まじめで口の堅いBさん
- まだおおっぴらにしたくないのなら、口の堅い人に相談するべきです。
それに、Bさんなら真剣に相談に乗ってくれるでしょう。
2人で作戦を練って、じっくりと攻めるのです。
「相談する」という操作を受け付けるオブジェクトが「Aさん」と「Bさん」で違うからです。
そして、どちらを選択するかはあなた次第です。
今のあなたの気持ちや状況から、より良いと思うほうを、好きなように選択できます。
このように、何かするときにはまず、その結果を予想してみてください。
次に、同じことをするのでも、違った結果が予測できる相手はいないか、あるいは違う結果を生みそうな物事はないか、ちょっと考えてみてください。
そういうモノが見つけられれば、あなたには自由な選択権が与えられるのです。
まぁ常に予測が的中するわけではありませんので、必ずいい結果が生まれるというわけではありませんが。
でも、より良いと思うものを選ぶための選択肢というのは、常にあったほうがいいですよね。
開発者の方は、ポリモーフィズムによって条件分岐を表現できることにお気づきですか？
実際に変数に入っているインスタンスが何であるのかによって、実行される処理が違うわけですから、単にその変数に対してメソッドをコールするだの、プロパティを参照するだけで、条件分岐になりますよね。
そして、ぜひこのことを知っておいていただきたい。
if文やswitch文などの条件文による条件分岐よりも、ポリモーフィズムによる条件分岐の方が常に高い柔軟性を発揮できます。
理由は、リスコフの置換原則を参照してください。
その他にも、条件自体の抽象化など、柔軟性を決めるいくつかの要因があります。
ただし、人のやることの大抵がそうであるように、ソフトウェア開発においても、常にトレードオフがつきまとうことも忘れないでください。
ポリモーフィズムによる柔軟性には、少しのオーバーヘッドという代価が必要です。
非常に微々たるものですが、これが無視できないような事情もあるかもしれません。
また、よほどよくできたファシリティ、フレームワークを持っていない限り、ポリモーフィズムで全ての条件分岐を解決しようとしたら、とんでもなくクラス数が膨らんでしまうでしょう。
もちろん、コード量も爆発的に増えるでしょう。
柔軟性と、パフォーマンスやコンパクトさ。
どういうシーンでどちらが必要なのか、それを的確に判断することが必要です。
オススメ
ソフトウェア開発者の方向けには、System Engineerの戯言というブログのオブジェクト指向言語を利用するメリットについて考えてみる ～ オブジェクトの多態性・・・第一章という記事はいかがでしょう。コントちっくな会話形式でおもしろく、わかりやすく解説されています。
で、参考になる本としては、こればっかりで恐縮なんですけど、ソフトウェア開発者の方にはオブジェクト脳のつくり方がオススメです。
またか、というかんじですが。
要するに、もう基本的なことは、この本でばっちりだということですね…たぶん。
0 件のコメント:
コメントを投稿