レンタル用ビデオの在庫管理と顧客管理システム

在庫/貸出管理

ビデオのタイトル名、購入本数、種別、購入価格、購入日、在庫本数、貸出本数、廃棄本数

20回レンタルを行なったものは廃棄。?購入日から3ヶ月間は新作扱い。

顧客の年齢により貸し出しの規制を行なう。(15,18,20才）

１ヶ月以上の長期返却のないものは不良貸し出し扱いとする。

3ヶ月以上平均貸し出し率が 0.1 以下のものは不良在庫扱いとし、店頭から、1本を残し、引き上げる。

顧客管理

会員制、1年更新、年会費無料(管理しない）

顧客の名前、年齢、性別、住所、認証方法、お知らせ送付の有無

貸し出し記録、不良貸し出し記録

貸し出し毎に上記の情報を管理する

不良貸し出しがあるか、過去１ヶ月間にあったときは貸し出しを行なわない

自分の好きな方法でクラス発見を行ってみてください。

詳細化レベルは、主要なクラスとそのクラスのクラス名と主要な操作と属性だけの概要レベルにします。

クラス設計においてのアピールポイントや注目ポイントがあれば、それを記載してください。

次回は、このクラス設計から行うようにします。

• A 君:  え、ここで終わり。
• G 君:  そのようじゃ。まぁ、テレビ番組から学んだのじゃろぅ。困ったもんだ。
• A 君:  そうすると、次は演習の説明からになるの？困ったもんだ。

See you again !!

5日目 ---(クラスの発見3) レンタルビデオショップのクラス発見(現物クラス編)

今日は、レンタルビデオショップのクラス発見を行っていきます。

まずは現物クラスの候補を発見します。

手法は、取り敢えず、「名詞句による発見」でやってみましょう。

現物クラス by 名詞句による発見

名詞句の分類

与えられた問題を眺めて、名詞句を抜き出し、それを「普通名詞」「固有名詞」、「単数形」「複数形」に分類します。 「代名詞」のときはそれを指す名詞に変換してから、分類します。

また、本来は動詞であることを名詞で表現しているもの、例えば、「初期設定」「運用」「管理」などは省くために別に分類します。

レンタルビデオの問題では、以下のように分類しました。

1. 普通名詞・単数形
   タイトル名、購入本数、購入価格、購入日、在庫本数、貸出本数、廃棄本数
   期間（問題には、「間」「長期」のように出現）
   不良貸し出し、不良在庫、平均貸し出し率
   顧客の名前、年齢、性別、住所、認証方法、お知らせ送付
   貸し出し記録、不良貸し出し記録
2. 普通名詞・複数形
   ビデオ、会員（顧客は会員制であるので、同じものとして分類）
3. 固有名詞
   (出現した名詞の１状態を表す固有名詞)
   15才、18才、20才、3ヶ月間、1ヶ月以上、3ヶ月以上、0.1 以下、1本、1年、有無、過去1ヶ月間
4. 動詞になる名詞
   購入、廃棄、新作扱い、貸し出し、規制、長期返却、不良貸し出し扱い、更新
5. 外部または無視していい名詞
   年会費(管理しないから）

日本語では単数形と複数形は明示されていませんが、文意からそれらを分類します。

問題からは、ビデオと会員別に分類されていましたが、上記にまとめるときに一緒にしています。これを再分類します。 このときに共通のクラスが発見できることもあります。

この段階で、動詞になるべき名詞（上記 4）やシステム外部の名詞や無視していい名詞(年会費)、 同じものを別の名詞で表現しているもの（会員と顧客）を既に分類しています。 通常は名詞の分類が終わった後に、さらにこの分類を行い、名詞の分類をリファインします。

• A 君: 問題に与えられているものより、見にくくなっていません？
• G 君: 実際のユーザとのヒアリング結果は、今回の問題のように「まとまって」はいないんじゃ。
• G 君: 今回はまぁ、もう一度、まとめなおすという感じじゃ。
• A 君: あー、そうですか。想定の範囲内でしたが、言い訳ぽいですが。

現物クラスのスケッチ

次に分類された名詞句から、クラスのスケッチ（概略のクラス構成）を抽出します。

すべての名詞は、「オブジェクト」か「オブジェクトの属性」の候補になります。

クラス候補は、「普通名詞・複数形」のものになります。ここでは、「ビデオ」「会員」になります。

「普通名詞・単数形」からクラス候補がないかを調べてみます。

このシリーズの最初にも書きましたが、効率化のために、クラスは一定の大きさが必要になります。 一定の大きさの例は、属性の種類や個数が4個以上というものがあります。 ここでは「普通名詞・単数形」のものから属性として4個以上持つ可能性があるものを調べてみましょう。

「貸し出し記録」と「不良貸し出し記録」は、会員やビデオ、貸し出し日付、返却日付など、 4個以上の属性を持つことが予想されますので、これらもクラス候補にします。

「住所」も住所を細かく管理すれば、複数の属性を持ちますが、レンタルビデオショップではそのような管理をしないと仮定して、 ここではクラス候補にしません。

それでは、発見したクラスの属性であるものとをマッチングしてみましょう。

クラスと属性のマッチング

1. ビデオ
   タイトル名、購入本数、購入価格、購入日、在庫本数、貸出本数、廃棄本数、平均貸し出し率
2. 会員
   名前、年齢、性別、住所、認証方法、お知らせ送付
3. 貸し出し記録
4. 不良貸し出し記録

これは与えられた問題と同じ内容になっています。逆に言えば、問題の段階で「現物クラス」 のスケッチがまとまっている段階のものになっていたことになります。

それでは、上記に出現しない普通名詞はどういうものになるかを見ていきましょう。

属性からのクラスの発見

「期間」を考えてみます。これはビデオの貸し出し期間の意味と、ビデオの在庫期間の意味の二つがあります。

貸し出しや在庫はビデオに関係するものです。この意味で、ビデオクラスの属性に「貸し出し期間」と 「在庫期間」を追加するという考えもあります。

しかし、前述したビデオクラスは、購入本数などの属性があることから、 同一タイトルのビデオ全体をインスタンスとするクラスになります。 そこで1本1本のビデオをクラスにすることを考えます。 これを前述のビデオクラスと混同しますので、前述のものを「ビデオタイトル」クラスにして、 1本1本のクラスを「ビデオ」クラスにします。

ビデオクラスの属性としては、「在庫期間」や「貸し出し期間」を与えます。またビデオタイトルも一つの属性にします。

• A 君: ビデオタイトルとビデオですか、少し分かりにくいネーミングでは？
• G 君: ネーミングは大切じゃ、でもこうじゃ。

機能クラスの抽出

名詞に相当するクラスは、いわゆるデータを持つモデル系クラスになります。このモデルクラスとは別に、 操作を中心とした機能クラスを作成する場合があります。

レンタルビデオショップのシステムでは、「貸し出し」は中心となる機能で、仕様変更も発生する可能性も高いと予想されます。 そこで、「貸し出し」クラスを機能クラスとして、ビデオクラスの操作から抽出して、独立のクラスにします。

貸し出しクラスの属性としては、貸し出し期間、ビデオ、会員を抽出します。

ビデオの属性であった貸し出し期間を廃止し、その代わりに貸し出しとの関連にします。

まとめ

名詞句によるクラス発見による現物クラス＋α（機能クラス）を以下にまとめます。

1. ビデオタイトル
   タイトル名、購入本数、購入価格、購入日、在庫本数、貸出本数、廃棄本数、平均貸し出し率
2. 会員
   名前、年齢、性別、住所、認証方法、お知らせ送付
3. ビデオ
   貸し出し、在庫期間、ビデオタイトル
4. 貸し出し
   貸し出し期間、ビデオ、会員

• A 君: 操作はないんですか？
• G 君: これからの楽しみじゃって、へへへ。
• A 君: 嘘、考えていないんでしょ。

明日は、抽象クラスを発見し、クラス構成をリファインするようにしたいと思います。

See you again !!

6日目 ---(クラスの発見4) レンタルビデオショップのクラス発見(抽象クラス編)

今日は、レンタルビデオショップのクラス発見のうち、抽象的なクラスの発見を行っていきます。

現実の世界に「物」として存在するクラス（＝現物クラス）は、比較的発見が容易なクラスです。このときは5日目に書きましたが、クラスにするか属性にするか、操作をクラスとして独立させるかなどの選択はありましたが、ほぼ一直線に発見できました。

ここで抽象クラスとは、「インスタンスオブジェクトを生成しないクラス」だけに留まらずに、「直接的な現物」を持たないクラスとして考えます。

抽象クラスの役割

ここでは、まず抽象クラスがなぜ必要か、その役割や目的を紹介します。

1. 分割統治クラス
   分割統治することを目的として、上位に位置する分割統治クラスとしての役割。トップダウン設計のときに用いる。機能クラスになりやすい。
2. 共通クラス
   共通のデータ構造（属性）や共通の機能（操作）を取り出した共通クラスとしての役割。差分を継承や委譲で実装する。
3. 抽象概念クラス
   共通クラスの目的とも関係するが、概念的に抽象化したクラスであり、純粋な抽象概念クラスとしての役割。80年代の抽象クラスの本来的な姿。
4. 部品用クラス
   再利用を行うために、属性や機能を抽象化する部品クラスの共通クラスやインタフェース用クラスとしての役割。部品クラス自身をさらに抽象化したクラスを発見しないとまとまりが悪くなる。
   部品クラス抽出のためのインタフェースクラスの場合はインスタンスが実在する現物クラスの場合もあるが、一緒に検討するためにここに加える。
5. 抽象インタフェースクラス
   外部との連携を行うために、一部機能を変更したり（アダプタクラス）、インタフェースを共通化したり（ファセードクラス）、などのためのインタフェースクラスを抽象化インタフェースクラスとしての役割。
   現物系のインタフェースクラスも、一緒に検討するためにここに加える。
6. シンプルクラス
   機能(操作）が複雑であるとか、データ構造（属性）が複雑であることを解消するために導入する「シンプル設計用クラス」の役割。2　の共通クラスや 3 の抽象概念クラスなどは、結果的には、シンプルクラスの一つになりますが、ここでは、シンプルにする目的だけに特化したクラスを意味しています。

• A 君: 下へ行くほど、抽象クラスぽくないですが・・・
• G 君: 現物クラスを発見するときに見つけにくかったクラスの「再発見」「再構成」の意味もあるんじゃ。
• A 君; 「二つのことを同時に行ってはならない」に反しますが、まぁ、いいでしょう。

手続き型指向では、一般的に、機能はトップダウン的に統治分割し、データ構造はボトムアップ的に作成することが多いです。一方、オブジェクト指向では、機能とデータ構造の両者をまとめて、クラス設計します。このため、上記のようにトップダウン的抽象クラスとボトムアップ的抽象クラスがあり、これらを発見する必要があります。

ビデオレンタルショップの抽象クラス

ビデオレンタルショップの例に戻ります。

現物クラスとして、ビデオタイトル、会員、ビデオ、貸し出しの4個を発見しました。すべて現物クラスですので、それぞれ実体を格納するデータ構造や操作があり、そのインスタンスオブジェクトが存在します。

例. 現物クラスのインスタンスオブジェクトの例： 「Back to the Future Part 2」、「小津安二郎」、「シリアル番号 12345 の StarWars episode III」、「貸し出し：2005年5月30日貸出、2005年5月31日返却・・・」

• A 君: なんか古すぎ。
• G 君: 今回の突っ込むところはそこか。

これらの現物クラスから、このシステムで必要か、または将来必要となる抽象クラスを考えてみます。

記録クラス

貸し出しクラスの主要な属性である「貸し出し記録」は、「記録」の部分は他にも利用可能なものであるでしょう。ここでは、これを抽象クラスとして考えてみましょう。つまり、抽象クラス「記録」クラスです。

この記録クラスは、抽象化したデータを記録することを目的とします。このため、役割としては、３の抽象概念や実際に共通化できたときは 2 の共通クラスの役割を果たします。また、部品クラスとして機能(操作)を抽象化すれば、部品クラスとしての役割も持ちます。

1. [貸し出し] ---コンポジション---> [貸し出し記録] ---汎化---> [記録]

の関係になります。(UML 用語を使って表現しています）。

会員クラス

会員クラスは現物クラスとして、既に発見しています。しかし、このシステムで将来、優良会員（お得意様）や未成年会員、家族会員などの会員種別が必要になってくると「予想」して、会員クラスを現物クラスではなく、抽象クラスとして定義し、現物クラスであった会員クラスを「一般会員」クラスにします。

これは、将来的な共通クラスになる役割や抽象概念の役割を果たす抽象クラスになります。

1. [一般会員] ---汎化---> [会員]

の関係になります。将来の別の会員クラスの会員は、会員クラスのサブクラスにします。

• A 君:  現物クラスのときに、会員クラスの発見が失敗だったのでは？
• G 君: そうではないのじゃ。クラス設計は「気楽に」「やり直すことを前提に」する方がいいんじゃ。

商品クラス／商品情報クラス

ビデオタイトルとビデオの関係は、商品情報と商品の関係です。このように抽象化することによって、外部システムと連携を取るときのインタフェース層として、適当なものになります。

これは、抽象概念クラスの役割を果たします。ビデオレンタルショップで、ビデオ以外を扱うときは共通クラスの役割も果たしますが、現時点ではそこまでを予想しません。

1. ビデオ ---汎化---> 商品
2. ビデオタイトル ---汎化---> 商品情報
3. ビデオ　---コンポジション---> ビデオタイトル
4. 商品　---コンポジション--->　商品情報

の関係になります。外部システムと連携するときには使用することを役割の一つとしますが、アダプタクラスなどのインタフェースクラスを明示的に作成する必要があるかも知れません。

抽象クラスのまとめ

以上の4個の抽象クラスを発見してきました。実装段階に入ると、シンプルにするための役割を持ったシンプルクラスを導入することがあります。典型的な例では、デザインパターンのクラスになります。

次回はクラス設計の詳細化を行っていく予定にしています。

See you again !!

7日目 ---(クラスの発見5) レンタルビデオショップのクラスの詳細設計

今日は、レンタルビデオショップのクラスの詳細設計をしていきます。

前回までで現物系のクラスと抽象クラスを発見してきました。それをまとめたものを以下に示します。

 
 +---------------+     +---------------+                           +---------------+
 | 商品情報      |     | 商品          |                           | 記録          |
 +---------------+     +---------------+                           +---------------+
       ↑汎化　　　　　　　　↑ 汎化                                   ↑ 汎化
 +---------------+     +---------------+     +---------------+     +---------------+
 |ビデオタイトル |     | ビデオ        |     | 貸し出し      |     | 貸し出し記録  |  
 +---------------+     +---------------+ use +---------------+ has +---------------+
 | タイトル名    |     | 貸し出し      | →  | 貸し出し記録  | →  | ビデオ        |
 | 購入本数      |     | 在庫期間      |     |               |     | 会員          |
 | 購入価格      | ←  | ビデオタイトル|     +---------------+     +--|------------+
 | 購入日        | has +---------------+                              |
 | 在庫本数      |                                                    |
 | 貸出本数      |                                                    |
 | 廃棄本数      |                                                    |
 | 平均貸し出し率|                                                    |
 +---------------+                                                    |
                                                                      |
 +---------------+                                                    |
 | 会員          |←--------------------------------------------------+
 +---------------+
 | 名前          |
 | 年齢          |
 | 性別          |
 | 住所          |
 | 認証方法      |
 | お知らせ送付  |
 +---------------+
       ↑ 汎化
 +---------------+    将来のクラス +---------------+ +---------------+
 | 一般会員      |                 | 特別会員      | | 返却          | ・・・
 +---------------+                 +---------------+ +---------------+

テキスト図形で見にくいですが、UML に準拠しています。 これを元にクラスの詳細化をやっていきましょう。

• A 君: なんで、テキストで図形を描くんですか？　手抜き？
• G 君: ノスタルジックを出してみたまでじゃ。決して手抜きではないぞ。
• A 君: それにしても、やや複雑のような気がしますが。
• G 君: ついつい、こういうところで作ると多めに作ってしまうんじゃ。これを「教科書効果」と呼んでおる。

クラスの詳細化に入る前に、日本人特有の問題について話します。

詳細化方針 1 --- (日本人特有の問題) 日本語と英語の名前

今までのクラスの発見では、クラス名や属性名など名前は「日本語」で発見してきました。 一方、Java などでは日本語の名前は技術的に使えますが、まだその文化になっていません。 また Java の予約語が英語ですので、日本語で書くとプログラムはある違和感があります。

それで「日本語の名前をいつ英語に変更するか」という問題が出てきます。

それに対する一つの解が、クラスの詳細化を行うときに「ついでに」やってしまう方法があります。 クラスの詳細化と名前の英語化とは、本来関係がないフェーズです。 しかし、このフェーズで英語化と詳細かを同時に行うことが多く、 「詳細化は英語化」また逆に「英語化は詳細化」という誤解があるのも事実です。

この英語化に対する施策には以下のものがあります。

1. 概要設計は日本語で、詳細設計は英語
2. 最初から英語のみの名前を使う
3. 最初から日本語と英語の名前のペアを使う
4. 最初から最後まで日本語の名前を使う

このうち、4 の最初から最後まで日本語というのは、見かけたことがありません。 (3) のものは、UML ツールが IBM/Rational ツールであるときはエイリアス機能が使えます。 また、そうでないときはノートで日本語または英語を記述しているものもありました。

ここでは、このような誤解を恐れずに (1) の英語化と詳細化を同時に行います。

• A 君: 誤解しますって。英語化が詳細化だって。
• G 君: まぁ、こちらも「見栄え＝ごまかし」に使いたいから、いいんじゃ。

詳細化方針 2 --- プラットフォーム依存

いままでは、実装については、一切触れずに話を進めてきました。 例えば、実装するプログラミング言語は何か？　使うライブラリは何か？　などに 全く触れませんでした。

設計思想の一つに「実装と切り離して設計する」のがあります。 これにより、設計の再利用やデザインパターンなどの 有用な技術に繋がっていきます。

一方、プログラミングするときには、プログラミング言語の決定や使用するライブラリの 決定が必要になります。概要設計では上記よりプラットフォーム独立にします。

もう一つの思想に「決めるのはなるべく後回しにする」というものがあります。 後回しにすることにより、自由度が高まり、変更容易性が高まり、さらに再利用の割合が 増加するという利点があります。

では、いつ、プラットフォーム依存にするのでしょうか？

1. このクラスの詳細化で行うのでしょうか
2. それともプログラミングフェーズになって初めて行うのでしょうか。

これはクラスの詳細化の「粒度」に依存します。 一番、詳細化が進んだ粒度では、プログラムコードと1対1対応していますので、 プラットフォーム依存になります。

つまり、プラットフォーム依存の詳細化は、詳細化の粒度を決めていくときに 決定できます。

• A 君: え、結局、答えは？
• G 君: 詳細化粒度に依存じゃ。
• A 君: でもアーキテクチャ設計で、プラットフォームは決定するのでは？
• G 君: 気のせいじゃ。概要のクラス設計が終わってからでも Java からアセンブラに変更可能じゃ
• A 君: え、アセンブラってオブジェクト指向でしたっけ。

詳細化方針 3 --- 詳細化の粒度

コード生成をツールで行うときなどは、プログラムと完全に1対1対応する詳細化 が必要になります。 しかしそうでないときは、プログラムコード自身で十分なことと、 逆にツールによって、プログラムコードからこの詳細化の粒度に対応した クラス設計の図を自動生成することも可能です。 このために、ここではプログラムコードと1対1対応する詳細化は行わないようにします。

段階的に詳細化を行う方法もありますが、最終段階の詳細化はどれくらいのものが必要 でしょうか。

端的に言えば、クラステンプレートが「プログラマがそれを見るだけでプログラミングできる」 程度の詳細化が必要になります。 但し、この文の中でプログラマやデザイナについて言及していませんので、 詳細化の粒度の決定には、この文だけではまだ不十分です。

ここでは詳細化の規則 R を以下のようにします。

1. 名前を英語にする
2. プラットフォーム依存にする。ここでは Java Web System にする。
3. クラスはすべて記述する
4. インタフェースはすべて記述する
5. 汎化はすべて記述する
6. 関連、コンポジション、依存は原則記述する
7. private 以外の属性はすべて記述する
8. 操作は、アクセッサ（セッタ、ゲッタ）は記述しない（原則記述する）
9. コンストラクタは、興味深いものだけ記述する（原則記述しない）
10. アクセス属性は興味深いものだけ記述する（原則記述しない）
11. 引数名は記述する
12. 引数のタイプは興味深いものだけ記述する
13. 値のタイプは興味深いものだけ記述する

• A 君: え、これだけ。詳細化が弱いのでは。
• G 君: 詳細化はシステム規模に依存するんじゃ。大規模になれば詳細化は弱い
• A 君: 設計はスケーラブルではないの？
• G 君: 気のせいじゃ。設計の詳細度は中規模が詳細で、大規模も小規模も荒いんじゃ。
• A 君: でも大規模ではない。あ、小規模だからか。これなら設計もいらないのでは。

クラスの詳細化

それでは、上記の方針1から3に基づいた詳細化規則 R によって、クラス図を詳細化します。

 
+--------------------+    +-------------------+                   +---------------+
| ProductInfomatioin |    | Product           |                   | Record        |
+--------------------+    +-------------------+                   +---------------+
| name               | ← | productInfomation |                   | records       |
| price              |has |                   |                   |               |
| wholesalePrice     |    |                   |                   |               |
| date               |    +-------------------+                   +---------------+
| purchaseNumber     |
+--------------------+        ↑                                      ↑
       ↑汎化　　　　　　　　 汎化                                    汎化
+---------------+     +---------------+     +---------------+    +---------------+
| VideoTitile   |     | Video         |     | Lending       |    | LendingLog    |
+---------------+     +---------------+ use +---------------+ has+---------------+
| genre         |     | lending       | →  | lendingLog    | → | video         |
| ageRate       |     | period        |     |               |  +-|-member        |
| stockNumber   | ←  | videoTitle    |     +---------------+  | +---------------+
| lendingNumber | has +---------------+     | lend          |  | | lend          |
| wasteNumber   |     | lend          |     | (member,video,|  | | (member,video,|
| lendRateAvg   |     |(member,period)|     |  period)      |  | |  period       |
+---------------+     | waste()       |     +---------------+  | +----|----------+
| checkAgeRate  |     +---------------+                        |      |
|  (age):boolean|                                              |      ↓
| waste()       |                                              | 　+------------+
| lend()        |                 　　　　　　　　　　　　　　 |　 | Priod      |
|               |                                              | 　+------------+
+---------------+                                              | 　| start      |
 +---------------+                                             | 　| end        |
 | Member        |←-------------------------------------------+ 　| holiday    |
 +---------------+                                                 +------------+
 | name          |                                                 | period()   |
 | age           |                                                 +------------+
 | sex           |
 | address       |
 | certification |
 | reportMail    |
 +---------------+
       ↑ 汎化
 +---------------+
 | RegularMember |
 +---------------+
 | cost          |
 +---------------+

新規のクラスとしては貸し出し期間を表す Priod を作成しました。 これを特別にクラスにした理由は、営業休日などの計算をカプセル化するためです。

属性の一部をスーパークラスの方へ移動したものがあります。 新たな操作として、貸し出しの中で年齢チェックを行う操作を追加しています。

ビデオ Video クラスの貸し出し操作 lend の周辺を見れば、貸し出しの 実行が以下のように推測できるかと思います。

Video.lend(member, period) 
    → VideoTitle.checkAgeRate(member.age)
    → VideoTitle.lend()
    → Lending.lend(member, video, period) 
             → LendingLog.lend(member, video)

それでは少しプログラミングもしてみましょう。 上記の Video クラスを作ってみます。

class Video {
  Lending lending;
  Period period;
  VideoTitle videoTitle;

  Video (VideoTitle videoTitle) {
    this.videoTitle = videoTitle;
    lending = New Lending();
  }

  void lend(Member member, Period period) {
    if (videoTitle.checkAgeRate(member.age)) {
       videoTitle.lend();
       lending.lend(member, this, period);
    } else {
       System.out.println("This is XXX for you.");
    }
  }
}

クラス設計だけでは、 操作の実行に情報をあまり与えていませんので曖昧さがあり、上記はその推測の例です。

• A 君: クラス図の操作と関連だけで作るなんて。推測というより妄想のような
• G 君: これも常日頃、妄想しているからじゃ
• A 君: 途中で色々と追加したでしょ。詳細化という名を借りての仕様変更では？
• G 君: 外部仕様を変更せずのマイクロリファクタリングじゃ。

今日は、レンタルビデオショップのクラスの詳細設計をしてきました。 その中で詳細化の方針や、詳細化の粒度を決めて詳細化をしました。

See you again !!

8日目 ---オブジェクト指向機能の効率　（その方針）

今日は、オブジェクト指向機能の効率について考えてみましょう。

効率の面から、クラス設計にどんな影響を与えるか見ていきましょう。

オブジェクト指向の参考書などでは、「オブジェクト指向機能の効率は『それほど』悪くない」と書いてあるものが多いようです。 実際にサンプル(トイ)プログラムを作って実験して数値を出しているものもあります。確かにそれらを見れば「それほど」悪くありません。そして、オブジェクト指向設計本では、「最初は効率よりも設計の美しさ」と書いてあります。

さらにそれらの本を読み進めていきますと、その本の後半になっても「効率のための(再)設計」についてはあまり触れていません。その頃には読者も忘れてしまっているかも知れません。ここではこのような本をお手本にせずに、効率の面から見たオブジェクト指向設計を考えていこうと思います。

効率を考える点で一番いいのは、オブジェクト指向機能の実装を見てみることです。クラスの実装やインスタンス、継承、委譲の実装を見ることにより、これらが どの程度遅くなるか（または気にすることがないか）が類推できるようになります。

• A 君: なんか、マニアック過ぎません？
• G 君: こういうことも必要なんじゃ。決して効率オタクではないぞ。
• A 君: でも、プログラミングするのに、その言語の実装を思い浮かべるなんて、面倒では。
• G 君: 実装を思い浮かべるのを習性にしてしまえばいいんじゃ。そのためにも言語は1個は作らんと。

レンタルビデオショップの例

レンタルビデオショップをもう一度振り返ります。

「オブジェクト指向機能はそれほど遅くない」という言葉を信じて、 例えば、ビデオ1本1本をクラスにしてみます。これはビデオ「ターミネータ」の12番のビデオをクラスにするというイメージです。この設計は、ビデオの種別ごとにクラスにするという前述した設計と 比較して、メモリフットプリントが大きくなり、その結果、実行速度も悪くなるでしょう。例えば、Java であれば、他で紹介しているフリーの計測ツールで測定してみましょう。

これは、どうしてこうなるのでしょうか。

クラス化のパターン

上記の結果はクラスの実装を考えずに、クラスにするかインスタンスにするかの設計を決定してしまったことにあります。

• A 君: 普通しないでしょ。また極端な例を持ってきて・・・
• G 君: そうではないぞ。昔、辞書を作るときに、そこに出てくる単語一つ一つをクラスにしたのがあったぞ。
• A 君: えー、世界最多のクラスでギネスでも狙っていたんですかね。

Java や C# などのクラスベースのオブジェクト指向機能では、クラスは多大なコストが掛かります。 例えば、空間的コストとして、クラスの情報を保持するためのメモリが必要です。 時間的コストとして、クラスの情報をアクセスするためにはメモリアクセスを何回か実行するコストも掛かります。 これは、「クラスの情報を動的にメモリに保持して、動的にアクセスする」 という仕様とその実装からくるものです。

• A 君: これを言っちゃお終いなのでは。誰もクラスベースのオブジェクト指向なんか使わなくなるんでは。
• A 君: なんか、オブジェクト指向批判者に聞こえますが・・・
• G 君: トレードオフなんじゃ。甘いものには罠があるということを知っておいて罠に嵌（はま）るんじゃ。

これらを考慮すれば、どの程度のものをクラスにするか、直接クラスにせずに共通化したものをクラスにして、対象のものはそれの インスタンスにするかを決めることができます。また、どのパターンのクラス化にするかという設計・実装を選びます。 これらを便宜的に以下のように名づけます。

1. 独立クラス型
   例. ビデオの1本1本をクラスにする。
2. 共通クラス型
   例. 「ビデオ」の共通クラスを作成し、ビデオの一つ一つは、そのインスタンスにする。
3. 非クラス型
   クラスにせずに値型1個かまたは複数の値型のオブジェクトにする。

例えば、クラスのサイズやクラス資源にアクセスする時間の空間/時間コストをまとめて ClassCost、対象のすべてのインスタンスオブジェクトの合計サイズとメソッドアクセスの平均時間からなる空間/時間コストを AllInstanceCost とします。さらに1個の対象インスタンスのみのコストを InstanceCost とします。

これらの値によって、どのパターンにするかを以下にまとめました。

1. 独立クラス型
   AllInstanceCost と InstanceCost がほぼ同じ大きさで、かつそれらの絶対値が比較的大きい。
   例. インスタンスの個数が２個までと少なく、1個のインスタンスのサイズが４以上の大きさを持ち、やや大きい。
2. 共通クラス型
   AllInstanceCost と InstanceCost に比較的差が有り、かつ絶対値が比較的大きい。
   例. インスタンス個数が３個以上で、１個のインスタンスのサイズは４以上の大きさを持つ。
3. 非クラス型
   各々の絶対値が比較的小さい。
   例. インスタンスサイズが３以下である。

上記の例には、3 とか 4 とかの具体的な個数が現れていますが、多人数でプロジェクトを運営するときには、 このレベルの個数も決めておいた方がいいでしょう。そうしないと「先生役」の人はこのような質問を例えばレビューのときにされて、 うんざりになるでしょう。

閾値の決定方法

それでは、上記の例にある閾値（上記の個数をこのように呼びましょう）を決定する方法を示します。

無難な方法は「実験」してみることがお勧めです。 （なお、毎回、実験する必要はありませんので、例えば、同一フレームワークで1回で十分です。）

• A 君: えー、面倒くさいのですが。
• G 君: 毎回毎回、行う必要はなく、感覚を掴むだけでもいいんじゃ。実装を思い浮かべるのと同じじゃ。
• A 君: Java や C# だったら、同じでいいですか。
• A 君: 両者ともクラスベースで、単一継承で、クラスライブラリも似ていますから、同じでもいい？
• G 君: デリゲーションや匿名メソッドがあるから、C# の方が触りがいがあるんじゃが、面倒だからいいじゃろ。

実験は、速度やメモリフットプリントだけでなく、「読解性」「拡張性」もその観点に入れるべきです。 両者は相反することになることも多いですが、トレードオフを取ることにします

• A 君: 読解性や拡張性って、機械的に判断できないのでは。
• G 君: そういうこともある。「美人プログラミング」がいいんじゃ。
• A 君: 宣伝！

また、世の中で公開されているエレガントなプログラムや、教科書に載っているものは、 この閾値の決定の補完として使えます。例えば、ライブラリ系であれば、Java の swing system がお勧めです。また、OSS の中には多くの見るべきプログラムがあります。

今日はここまでになります。実際の効率については、筆を改めてしたいと思います。

9日目 --- リファクタリング(デザインパターン編)

今日は、設計のリファクタリングを行っていきます。

• A 君: 最初からへたくそなものを作らない方がいい！
• G 君: まぁそれはその、将来が変わるのはあるしの
• A 君: それは隠れ蓑で、実際はへたくそな作りの尻拭いなのでは？
• G 君: 単に作り直しや見直しと言うよりも、リファクタリングと言えば、カッコがつくじゃろ。

リファクタリングの種類と方向

設計のリファクタリングには色々な方法があります。その一例を以下に示してみます。

1. クラス間の関係からのリファクタリング
2. クラスの粒度/クラス数からのリファクタリング
3. ホットスポットの観点からのリファクタリング

１はクラスの質とも言うべき関係からのリファクタリングです。2 はクラスの量からのリファクタリングです。 3 は将来拡張する部分やデータに依存して抽象化しておきたい場所に依存したリファクタリングです。

デザインパターンは 3 のホットスポットの観点からのリファクタリングに使える道具になります。

リファクタリングをするときに、クラス設計を見ていく方向として、以下のものが考えられます。

1. トップダウン
   クラス設計をトップから見直す方法です。大掛かりになる傾向性があります。
2. ボトムアップ
   クラス設計をボトムから見直す方法です。共通クラス化などに注意する必要があります。

デザインパターンを用いるリファクタリングは、ボトムアップ的ですが、 見かけ的には「一定の高さを持った山」を探すことになります。 これはツリー的に言えば「一定のリーフを持った枝」に相当するところを対象にします。

ホットスポット

リファクタリングをするためには、リファクタリングの目的を明確にして、それを元に手段を決め、 次にリファクタリングする場所を探します。

今回のリファクタリングの目的は、(1) 将来の変更に備えて抽象化することと、(2) プログラムの読解性を高める ことにします。このための手段としては、デザインパターンのいくつかを採用します。

将来拡張する場所などのような、リファクタリングで注目するべき場所を「ホットスポット」と呼びます。 逆にそれ以外の拡張せずに固定的に使うなど、リファクタリングで注目しない場所を「コールドスポット」 と呼びます。

ユーザ要求の分析をしているときに、どこをホットスポットとし、どこをコールドスポットとするかを発見する のが重要になります。

ホットスポットは多い方がいいように感じるかも知れません。 例えば、以下のように言えるように、システムをホットスポットだらけにするのがいいかも知れません。

「このシステムはどのような拡張に対してもオープンであり、他のプログラムはその拡張に対してクローズドです」

しかし、これは良くありません。この理由はホットスポットを、デザインパターンなどで抽象化することは、以下の結果になります。

「デザインパターンは、プログラムを見にくくします」

これは直感と違うと感じる方がいるかも知れません。

読解性が向上したと見えるのは、デザインパターンを採用した結果、 プログラムの実装手法や、クラス名やメソッド名などの名前そのものまでパターン化した効果によるものです。

デザインパターンや抽象化そのものは、プログラムの複雑度を上げます。 例えば、1回の関数呼び出しでよかったところを抽象化するために途中に関数呼び出しを増加させます。 他の例ではクラス数が増えるのもあります。プログラムは複雑になり、プログラムは見にくくなります。

これは一般論ですべてのパターンがプログラムを見にくくするものではありません。例えば、シングルトンはプログラムを見やすくするでしょう。

• A 君: なんか、プログラムを見にくくするって、過激な事を
• G 君: 単純に考えても、複雑になるから、単純じゃなくなるんじゃ
• A 君: 「見やすさを損なう危険性があります」ぐらいでどうでしょう

「デザインパターンはプログラムを遅くします」

効率についても読解性と同じことが言えます。効率と読解性の面からもホットスポット設計は重要になります。

つまり、これらから、ホットスポットとコールドスポットのトレードオフを見つけることになります。 これが結果として、デザインパターンの適度な採用になります。

もう一度、繰り返しますが、デザインパターンを多用することが目的でありません。 また、システムの多くの場所を拡張可能にするためではありません。

つまり、全体のバランスを考え、目的や問題に応じて、ホットスポット単位に適用するデザインパターンを 検討することになります。

多用には注意することを書いてきましたが、しかしそれをやや勧める「デザインパターンの適用パターン」があります。

1. インタフェースやデリゲーション、インヘリタンス、コンポジションは比較的多用する
   これらの使い分けは後述します。
2. 動的な機能クラス(制御クラス）は生成系デザインパターン(factory, prototype, builder など)を使う
   どの生成系パターンがいいかは後述します。
3. 状態が多くなったら、状態管理系パターン(state, command, interpreter など)を使います。
   どの状態系パターンがいいかは後述します。
4. その他
   その他の「デザインパターンの適用パターン」は別途書くようにします。

これがデザインパターンを適用するパターンになります。 インタフェースやコンポジションの多用に関しては、それほど違和感は少ないかと思います。 しかしインヘリタンスの多用には異議を申し立てる人も多いかも知れません。 ここでは、他の差分化が失敗して、かつ always に is_a 関係があるときにのみ、多用するという意味です。 多少、違和感が減ったかと思いますが、どうでしょう。

デザインパターン本では、これらは「商売柄」、やや多目に適用するように書かれていますので、「真に受けずに」適当に適用するようにしてください。

デザインパターンの適用アンチパターン

前節では、デザインパターンの適用パターンのいくつかを紹介しました。 しかし、デザインパターンを学んだ直後には、多くの種類のパターンを無闇矢鱈と採用することがあります。 そこで、適用パターンを論じるのではなく、適用してはいけないパターン、つまり、適用アンチパターンを 紹介することで、その戒めとすることにします。

1. インヘリタンスを用いた階層化インタフェース
   もし階層化 API を作成する目的で、これを使おうとするのであれば、 階層間(インタフェース間）の関係はデリゲーションを使うことを勧めます。
   経験から、これは「例外処理」があるために階層間に is_a 関係が always でない場合が多いと思うからです。
   さらに将来パフォーマンスチューニングを行うときに、インヘリタンスでは途中の階層を省略する「中抜け」テクニックを使いにくくします。一方、デリゲーションは比較的容易に中抜けをすることができます。
2. レベルが異なる生成系パターン
   複数のオブジェクトを持つ生成系パターン（abstract factory, builder など)が、静的オブジェクト（ファシリティ）や 動的オブジェクト（エンティティ）が混合しているなどレベルの異なるオブジェクトを同時に持つようにしないことを 勧めます。
   生成系クラス(factory, creator など)によって、一つのグループにすることにより、意味がないのに意味を生じさせて、 それを元にプログラムを読むことを困難にさせるからです。
   対策は別の生成系パターンにして、グルーピングしてから、まとめる方法も考えられますが、ファシリティとエンティティは一緒にしないのが無難です。
3. 複雑すぎるステートパターン、単純すぎるステートパターン
   状態が多くなったときに使うステートパターンですが、これは状態数と状態遷移の複雑さによって、使い分ける必要があります。
   複雑すぎる状態を単純なステートパターンを使うと、プログラムは意味不明になります。ステートを階層化する、グルーピングする、グラフ化するなどで状態の複雑さを局所化します。
   一方、2値で使う人もいないでしょうが、4個の状態で使うのは、プログラムをいたずらに複雑にするだけです。一定個以上のときに使います。また状態遷移がスター型のときは使わなくてもいいでしょう。メッシュ型のような複雑なときに使います。
4. 入れ子になったパターン
   デザインパターンを適用するホットスポットが入れ子状態になっているときに別々にパターンを適用している。
   独立しているパターンであるときには複雑さ以外の問題はないが、独立ではない場合が多い。

他のアンチパターンもあります。デザインパターンの種類よりも多いでしょう。デザインパターンは定理のようなものであるのに対し、アンチパターンは反例のようなものになります。

• A 君: うわ、これは、デザインパターンにいちゃもんを付けているみたい
• G 君: いちゃもんを付けられるということはじゃ、見込みがあるということで喜ぶべきじゃ
• A 君: そうかな・・・そうなんでしょうねぇ・・・そうだよね・・・そうなんだ

デザインパターンの適用方法

次にデザインパターンの適用について考えます。今までに書いてきたことをまとめてみます。

1. リファクタリングの目的を知る
2. ホットスポットの候補を探る
   　　　ホットスポットによっては、他のホットスポットを一部または全部を含んでいる場合もある
3. コールドスポットの候補を探る
4. ホットスポットとコールドスポットを設計する
5. ホットスポットに適用するデザインパターンを発見する
   　　　既存のパターンから適当なものを探す
6. (参考）目的と合致するパターンがないときは、新規に作成する

健康のためにデザインパターンの使いすぎには注意しましょう。しかし、デザインパターンを知らなくて使わないのは賢明とは言えません。楽しいリファクタリングになるためにも、「名前の付いた」パターンを適用していくことはいいことでしょう。

• A 君: 何気にまとめようとしている
• G 君: 実際のプログラムに適用しない限り、絵に描いた煎餅じゃ
• A 君: 煎餅よりも羊羹を。適用方法よりも実際のプログラムの適用を。