|
|||
オブジェクト指向オブジェクト指向の概念 prev<< | >>next オブジェクト指向での再利用性向上について ハードウェアでは当たり前のカプセル化
ソフトウェアは、テレビや冷蔵庫のように実際の物として目に見える形で存在しません。
それが故に普段当たり前のように思っていることが、システムの開発時になると何故かできなくなっていたりすることがあります。
例として、エレベータを考えてみましょう。 私たちが通常エレベータを使う際に行う操作は、エレベータに乗る前は、上に行くか下に行くかのボタンを押すこと。 エレベータの中では、行きたい階のボタンを押す、他には、開ける、閉めるのボタンを押す程度です。 しかし実際エレベータの動作は、動力源となるモータの回転数の制御や、停止位置に正しく止まっているかの確認、 ドアの安全な開閉など、全てがスムーズに動作しており、私たちはそれらを何の気にも留めることなくエレベータを使っています。 ボタンの隣に、モータの回転数を調整するつまみがあったり、エレベーター外側のドアの開閉を行うボタンがあったりしたら、とっても危険です。 テレビはどうでしょう。電源、チャンネル、音量、基本はそのくらいです。プラスアルファで、色調やコントラストの調整などはできたりします。 しかし、本体を分解し、中のものを直接触って、、、なんてしていると、メーカー保障の対象外になってしまいます。。 つまり、製品としていろんな複雑な処理、動作は内部でしっかりと行います。通常使用する部分、時折調整を行う部分はユーザーが触れるように してあります。どうぞご自由に操作してください。でも、内部はだめですよ。といった具合です。 大雑把な例ではありますが、エレベータやテレビに限らず、洗濯機、自動車、自動販売機、携帯電話など、とにかくありとあらゆる「もの」は、ユーザーが操作できる箇所を 必要最小限(ユーザーが操作するために必要な箇所、ユーザーが独自に調整を行ってもよい箇所など)だけ公開しています。まさにカプセル化です。 そして操作をした際の実際の内部動作については全然意識しませんよね。操作方法さえ知っていればいいんです。 このようにハードウェアは、昔からありとあらゆる所で当然のごとくカプセル化が行われています。それはユーザーが操作できる箇所を明確に定義すること、 そして、ユーザーが誤った操作をしてしまい、その結果、製品が壊れる、人的被害が発生するというのを未然に防ぐという安全策がとられているからです。 (PL法とかもありますし) こういった面からわれわれの扱っているシステム・プログラムを見てみるとどうでしょうか? 構造化プログラミングでは、そういった機能を実現するためにどうするか?で処理を考えます。 オブジェクト指向では、その「もの」を考えて作ります。つまり、先にあげた実際の「もの」と同様な感覚でシステムを構築します。 クラスを定義する際に、何を行うクラスであるかを明確にし、そのクラスを使う人はどのような操作を行えるか(メソッド)、どのような値の設定・取得を許すのか(プロパティ)、 クラスは外部にどのタイミングで何を通知するのか(イベント)を定義します。 これでクラスの枠組みは完成です。あとは、それに合う動作をクラス内部で組み込んでいくのです。 そうすることで、クラスを使う人は、操作方法を知っていればクラスを使うことができます。 という点で、実際の「もの」と同じような発想で、システムが作られていきます。 小さな部品のクラスでも、それらを組み合わせた大きなクラスでも守るべき思想は変わりません。 このような発想で考えていくのがオブジェクト指向です。 しかし、継承などからは現実のもので例えて話をすると結構混乱してしまうようです。例え話は例え話。それらを聞いた後、 うのみにせずに、「で、ソフト的にはどうだろう?」ともう一度自分なりに考えることが大切です。
よく例えられますが、クラスは設計図、オブジェクトは設計図からつくられた物。といわれます。
確かにオブジェクトはクラスから作られたインスタンスではありますが、オブジェクト指向はすべてがその「もの」であるインスタンスで
完結できるようなものではありません。
|
|
||