強健な構造

閲覧数1,322

ダウンロード数0

ページ数 : 3ページ
会員550円 | 非会員660円

資料紹介

情報工学特講
強健な構造
オブジェクトオリエンテーションは様々に変化し、伝統的方法より拡張することができるソフトウェアを与えるとしばしば主張されます。そして、継承とカプセル化は解決策の重要な部分であるとしばしば主張されます。第4章では、function/data方法に関する問題について議論して、オブジェクト指向解決策を示しました。しかしながら、それ自体でオブジェクトオリエンテーションは強健で拡張することができるソフトウェアを保証しません。この土台としてこの例を見ます。例はこの本の前書きの著者が議論した前の例への拡大です:デーヴ・トーマス(1989)は例にOO解決策を紹介しました、そして、ラリー・コンスタンティーヌ(1990)は機能的な解決策を紹介しました。例のシステムは多くの異なったタイプのアカウントに対処しなければなりません。例として3つのアカウントタイプが含まれています: passbook savings、checkingおよびbonus savings。それぞれのアカウントタイプに、多くの異なった取引（処理）が有効です; 簡単に3つ示されていますが、実際のアプリケーションではそれはより多くなるかもしれませんそれぞれのトランザクション処理モジュールは各アカウントタイプのための異なった変化に対処しなければなりません。しかしながら、いくつかのモジュールの上で再利用されるモジュールには部品があるでしょう、データベースアクセスや、ユニークな部品などのように、ボーナス貯蓄の処理などのように。良いストラクチャードデザインでは、機能が分解されるので、一般的な処理はどこでも、デザインとコード化の複製なしで必要であるところで再利用することができる下位のモジュールで見つけられています。様々なアカウントタイプは現在、抽象的なクラスAccountの子孫としてモデル化されるでしょう。
操作（Open, Deposit and Withdraw (あけて、預ける、引き出す)）を引き継ぐ。
ことによるとこれらは異なった実現を必要としますが、少なくともそれらには、同じインタフェースがあります。‘other object’は様々な取引（処理）でこれらのオブジェクトを操作するそれらのオブジェクトを表します。オブジェクトインターフェースが一般的であるのでポリモフィズムを使用することでAccountを作動させるためこれらのオブジェクトの大部分を記述することができます。しかしながら、少なくともオブジェクトの創造は様々なアカウントタイプの間で異ならなければなりません。現在、これらの解決策のどちらが、より変えやすいですか?いくつかの典型的な変化を考えましょう。money marketアカウントなどの新しいアカウントタイプを加えたいと思う場合、どうなるでしょうか? function/dataソリューションに新しいアカウントタイプを加えるのは、図6.18で示されるように私たちがこのアカウントタイプにおけるそれぞれの有効な取引のための新しいモジュールを加える必要があります。これらのモジュールはもちろんデータベースアクセスなどなどの既存の低レベルモジュールを使用するかもしれません。さらに、アカウントタイプ、すなわち、すべての取引モジュールを決めるためモジュールを変更する必要があります。通常これらのモジュールで、ボディーはアプリケーションのための特定のタイプに決めるためのCASE-表現方法です。その結果、すべての適切な取引のために新しいケースを加える必要があります。したがって、この場合、新しいアカ