2003年8月31日号
「システムはオブジェクト指向 Ruby & Flash」(#002) 福井修@Fsys 【○】本日のお題 オブジェクト指向とは ━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■ なぜオブジェクト指向なのか ──────────────────────────────────── 前回 注1)なぜオブジェクト指向なのか そして Ruby&Flash なのか を説明しま した。 なぜ オブジェクト指向なのか？に対する答えは、次のとおりと前回書きました。 １．従来の 「手続き型」の方式に対して、共通部品化（カプセル化）において 優れている。 ２．共通枠の「クラス」と個別実体「インスタンス」という概念を導入すること で、モデル化および実装において整理が進んだ。 ３．「継承」という方式が、持ち込まれて、親クラスを継承した子クラスでは、 差分のみの実装ですむようになった。 ４．同じ名前で、文脈によって内部で少し違う処理を実行できる（ポルモーフィ ズム）ので、便利。もちろん違う処理は、違う名前で が基本。 ５．便利さを実感できるまで敷居は、低くはないが、一旦味をしめるともう手放 せなくなる。 今回は、オブジェクト指向について、さらに話しをすすめます。 オブジェクト指向のメリットは、『再利用』です。これが、ポイントです。 これを実現するために、いろいろしんどい準備をするのです。 思い出してください。ワープロが導入された頃のことを。なぜしんどい思いを して慣れないキーボードと格闘して、一生懸命打ち込んだのかを。 デジタル化しておけば、あとで再利用できるし、そこで楽ができるからだったで しょう。それと同じです。 オブジェクト指向しておけば、あとで再利用ができて楽ができるのです。 従来の手続き型の方式では、手続き部しか部品化できなかった（それでもそれな りのメリットはありましたが）のに対して、オブジェクト指向では手続き部とデ ータ部を合わせて部品化できるのでより大規模に、部品化（＝再利用可能）でき るのです。再利用してやっとコストメリットが出るので、最初の部品化だけに着 目するとかえってコストが、かかります。この点は、要注意です。 オブジェクト指向についていろいろな解説は、参考記事等 注2)も参照して頂く として、ここでは私なりの切り口で、解説します。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■『オブジェクト指向分析・設計』と『オブジェクト指向プログラミング』 ──────────────────────────────────── 真のオブジェクト指向システムは、『オブジェクト指向分析・設計』をするべ きだと教科書には、書いてあります。そのとおりでしょう。条件が整えば。 費やせる時間が、たっぷりあるなら、今から UML を勉強して... というアプロ ーチもありでしょう。しかしながらそんなに恵まれた状況はなかなか無いと思い ます。そうすると先に『オブジェクト指向プログラミング』から手をつけても良 いのでしょうか？やっぱり『オブジェクト指向分析・設計』をきちんと学んで身 につけてからなのでしょうか？ どちらが先かは、明らかです。『オブジェクト指向プログラミング』から始める のが賢明です。 オブジェクト指向プログラミングで、再利用のメリットはすぐに得られます。 また クラス設計 は難しいので、クラスに慣れるまでは、クラスを使用する実装 での経験を積むのが早道だと思います。 野球がうまくなるのには、まずボールに慣れることからです。 実践のオブジェクト指向では、いかにクラスを作って、使うかが勝負です。 でもはじめの一歩は、「クラスって何？」っていうところからですね。 クラスは、『設計図』であり、『たこ焼き器』であり、手続き（＝メソッド）と データ（＝プロパティ）をまとめたところの『くくり（＝管理単位）』です。 どのような『くくり（＝管理単位）』が良いのかは、場合の数だけ答えはありま す。そこがデザインの世界と共通するところです。工業製品にように、規格とル ールを決めたら画一的に、一定の品質で物が作れるというのとは、やはり土俵が 違うと思います。（まあ画一的にできる土俵も一部にはあるでしょうが） ＤＢのテーブル設計もデータの『くくり（＝管理単位）』の決め方の問題です。 画面設計も答えは、場合の数だけありますね。何に重点を置くかで、いろいろな 解があるわけです。 オブジェクト指向プログラミングについては、次回 Rubyの話しで、取り扱うの で今回はパスします。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■ デザインパターンを利用する ──────────────────────────────────── クラス設計は、難しい です。 まあ難しいのは、クラス設計だけでなく、画面設計やＤＢ設計も難しいでしょう。 センスと経験の両方が必要なのは、同じです。 良い作品は、悪い作品との比較で評価できますから、クラス設計もどんどん駄作 を重ねてゆくうちにどんどん磨かれて、良い作品に進化します。 C++で、マイクロソフトのクラスライブラリよりボーランドのクラスライブラリの 方が良くできていたとか、Javaのクラスが、膨大になったら、C#が改善案を出し てくるとか、Flash ActionScript が Flash5 から、磨かれて、機能が増えて FlashMX に進化したりとか、RubyのクラスもVersion1.6.8から1.8がリリースされ 進化...『 クラス道 』追求の世界かな。 この進化は、終わらないで続きます。このあたりは、なんでも 摂理 ですね。 汎用クラスライブラリは、プロ達が腕を競う訳ですが、アプリケーションの世界 も、それらを利用しつつ、自分でもクラスを設計し、再利用してゆく訳です。 UMLのクラス図を、すんなり書けるようになるにはそれなりの慣れが必要です。 上達の早道は、何でもそうですが、先達の真似をすることです。オブジェクト指 向の設計には、GoF(the Gang of Four)の２３パターンという教科書が存在して います。この『オブジェクト指向における再利用のためのデザインパターン』 （通称GoF本）の洗礼を通過しないと一皮むけません。溺れないように^^; せっかくなので GoFの２３パターンを眺めてみましょう。注3) ───── ・ 生成 ───── Abstract Factory オブジェクトの組を実行時に切替えて使えるようにする方式 Builder 構造や要素が異なっていても生成方法を共通化して使う方式 Factory Method インターフェースだけ規定して生成はサブクラスにての方式 Prototype 雛型を決め、複製して生成する方式 Singleton インスタンスが１つであることを保証する方式 ───── ・ 構造 ───── Adapter 別のインターフェースを組み合わせる方式 Bridge インターフェースと実装を別々に独立して変更できる方式 Composite ツリー構造で、単一と復数を区別せず扱えるようにする方式 Decorator 動的に機能を追加できる方式 Facade 複数の内部に、外からのシンプルな窓口を提供する方式 Flyweight 多数を共用を利用して、効率よくする方式 Proxy オブジェクトのアクセスに代理を利用する方式 ────── ・ 振る舞い ────── Chain of Responsibility 要求に応える役割をチェーンでつなぐ方式 Command 要求をオブジェクト化し、再利用できるようにする方式 Interpreter 文法表現と解釈を同時に定義する方式 Iterator 要素に順にアクセスする方式 Mediator 相談役を立ててメンバー同士の独立性を維持する方式 Memento 状態を保存して、後で復元できるようにする方式 Observer 状態を監視し、変化を通知する方式 State 状態に合わせて動作を変えるのに条件分岐を使わない方式 Strategy 処理をカプセル化し、交換可能にする方式 Template Method 全体は変えずに一部をサブクラスで変更する方式 Visitor 構造を渡り歩きながら操作や、追加をする方式 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ※ 注釈、資料、参考情報 ──────────────────────────────────── 注1) http://www.melma.com/mag/02/m00020302/a00000592.html 注2) 浅海 智晴さんの 「オブジェクト指向分析/設計概論」 http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html 注3) ・ 『オブジェクト指向における再利用のためのデザインパターン』改訂版 Erich Gamma/Richard Helm/Ralph Johnson/John Vlissiders 著 本位田 真一/吉田和 樹 監訳 ソフトバンクパブリッシング 7973-1112-6 ・ 『Java言語で学ぶデザインパターン入門』結城 浩著 ソフトバンクパブリッシング 7973-1646-2 ・ UMLプレス Vol.1 技術評論社 ・ 日経ソフトウェア 2002/3 「デザイン・パターン入門」特集 ・ デザインパターンの骸骨たち2 http://www002.upp.so-net.ne.jp/ys_oota/mdp/ ・ ギコ猫とデザインパターン http://www.hyuki.com/dp/cat_index.html ・ Paul Graham「ものつくりのセンス ---Taste for Makers---」 http://www.shiro.dreamhost.com/scheme/trans/taste-j.html ・ いろんな言語でデザインパターン http://www.hyuki.com/dp/dpml.html#lang ・ Delphi で学ぶデザインパターン入門 http://www.acesekkei.com/dp_frame.htm ・ VB.NET/C#でデザインパターン http://hccweb1.bai.ne.jp/tsune-1/ ・ 「MixJuice によるデザインパターン改善カタログ」 http://cvs.m17n.org/~akr/mj/design-pattern/ 【プロフィール】 福井 修 ( FUKUI Osamu )o-fukui@po.iijnet.or.jp 福井システムリサーチ http://fsys.net/ 主幹。システム構築歴２７年。 システム構築エキスパート 日本リヌクス協会、神戸商工会議所、情報処理学会 会員 関西ソーホ・デジタルコンテンツ事業協同組合員 デジタルハリウッド三宮校 Java講師
