| At line 1 removed 2 lines |
| ★このページはまだ書きかけです。 |
|
| At line 4 changed 4 lines |
| クラスを定義する際にはユーザからの業務要件が基になりますが、それはシステムあるいはプログラム、つまりオブジェクト指向で言えばクラスの役割を規定しているだけです。役割を規定しただけではモノを決められないことは前述の通りです。\\ |
| 私たち開発者は、その役割を実現出来るモノはどういう状態であるべきかを考える必要があります。状態はデータ構造によって規定されます。\\ |
| 繰り返しますが、その内部の状態がどうなっているかはクラスを利用する側からはあまり重要ではありません。利用する側からは「何をしてくれるのか」が重要だからです。\\ |
| しかしクラスの設計者は、「それをするためにはどうあるべきか?」を考える必要があります。 |
| クラスを定義する際にはユーザからの業務要件が基になりますが、それはシステムあるいはプログラム、つまりオブジェクト指向で言えばクラスの役割を規定しているだけです。__役割を規定しただけではモノを決められない__ことは前述の通りです。\\ |
| 私たち開発者は、その役割を実現出来るモノはどういう状態であるべきかを考える必要があります。なぜならば、 |
| *状態はデータ構造によって規定される |
| からです。\\ |
| 繰り返しますが、その内部の状態がどうなっているかはクラスを利用する側からはあまり重要ではありません。「何をしてくれるのか?」が利用する側からは重要だからです。\\ |
| しかしクラスの設計者は、 |
| *それをするためにはどういうデータが必要か? |
| を考えて決める必要があります。 |
| At line 10 changed 2 lines |
| クラスを設計する際に必要なのはデータ構造を考えることです。データ構造というのは「ひとかたまりとして扱いたい情報」です。\\ |
| AクラスとBクラスを異なるクラスとして定義するということは、Aの情報のかたまりとBの情報のかたまりとの間に境界があるということです。境界がなければ同じクラスでも構わないからです。境界線を引いた上で、境界線の内側にある情報(属性)同士が同じクラスとして扱われるべきです。\\ |
| クラスを設計する際に必要なのはデータ構造を考えることです。__データ構造というのは「ひとかたまりとして扱いたい情報」__です。\\ |
| AクラスとBクラスを異なるクラスとして定義するということは、Aの情報のかたまりとBの情報のかたまりとの間に__境界がある__ということです。境界がなければ同じクラスでも構わないからです。境界線を引いた上で、境界線の内側にある情報(属性)同士が同じクラスとして扱われるべきです。\\ |
| At line 23 changed 2 lines |
| 全てに共通するのが動詞となる名詞が付けられていることです。「送信する」「受信する」「制御する」「表示する」「管理する」です。\\ |
| 動詞になる名詞を持つということはすなわち処理に着目して定義されています。つまりそれは処理を共通化しようとしてクラス化されています。オブジェクト指向において共通化すべきなのは処理ではなくデータ構造なのです。\\ |
| 全てに共通するのが__動詞となる名詞が付けられている__ことです。「送信する」「受信する」「制御する」「表示する」「管理する」です。\\ |
| 動詞になる名詞を持つということはすなわち処理に着目して定義されています。つまりそれは処理を共通化しようとしてクラス化されており、誤っています。__オブジェクト指向において共通化すべきなのは処理ではなくデータ構造__なのです。\\ |
| At line 29 changed one line |
| これらは動詞を無理矢理名詞にしただけで本質は上記と変わりません。そしてこれらは「役割」を表現することがほとんどで、Interfaceとして定義されるべきものを多く含んでいます。 |
| これらは動詞を無理矢理名詞にしただけで本質は上記と変わりません。そしてこれらは__「役割」を表現することがほとんどで、Interfaceとして定義されるべきもの__を多く含んでいます。 |
| At line 32 changed 2 lines |
| それではクラスにすべきものは何でしょうか?\\ |
| システム要件の中に出てくる「物」と「結果」の2種類です。\\ |
| それではクラスにすべきものは何でしょうか? システム要件の中に出てくる、 |
| #物 |
| #結果 |
| の2種類です。\\ |
| At line 35 changed 3 lines |
| !物クラス |
| この種類に分類されるクラスは、実際に存在する物として人間が認識出来るものです。\\ |
| データベースのマスタデータとして分類されるものを多く含みます。 |
| !【物クラス】 |
| この種類に分類されるクラスは、実際に存在する物として人間が認識出来るものです。データベースのマスタデータとして分類されるものを多く含みます。 |
| At line 47 changed one line |
| !結果クラス |
| !【結果クラス】 |
| At line 62 changed 4 lines |
| このクラス図中の金額クラスは商品単価の金額値を持つクラスです。商品単価は「ある特定の日の商品の売り値(金額)」として定義されます。\\ |
| 日付クラスは、受注伝票クラスでも商品単価クラスでも利用されます。\\ |
| ところがこのクラス図には問題となる部分があります。商品が受注個数を持つようになっていますが、受注個数は受注のたびに変わるため、商品の一部としてこれを持つのは無理です。正しくは、「商品/受注個数/商品単価」の組合せとする結果クラスとして持つべきです。受注明細と一般的に言われるものです。\\ |
| これを訂正したのが次のクラス図です。\\ |
| このクラス図中では、 |
| *金額クラスは商品単価の金額値を持つクラス |
| *商品単価は「ある特定の日の商品の売り値(金額)」として定義される |
| *日付クラスは、受注伝票クラスでも商品単価クラスでも利用される |
| と定義しています。\\ |
| \\ |
| ところがこのクラス図には問題となる部分があります。商品が受注個数を持つようになっていますが、受注個数は受注のたびに変わるため、商品の一部としてこれを持つのは無理です。正しくは、 |
| *「商品/受注個数/商品単価」の組合せとなる結果クラスが必要 |
| です。受注明細と一般的に言われるものです。これを訂正したのが次のクラス図です。\\ |
| At line 75 added 8 lines |
| \\ |
| 上記図での注意点は商品単価です。商品単価は、 |
| *商品 |
| *日付 |
| の2つの要素によって決まりますが、このモデルでは、 |
| #受注伝票が持つ日付 |
| #受注明細が持つ商品 |
| によって商品単価を特定します。 |
| At line 69 changed 2 lines |
| 上記の「物」と「結果」に加えて、アプリケーションプログラムそのものを具現化するクラスが必要です。 |
| !レイアウトクラス |
| 上記の「物」と「結果」に加えて、アプリケーションプログラムそのものを具現化するクラスが必要です。次の3つがあります。 |
| #レイアウトクラス |
| #プログラムクラス |
| #メインクラス |
|
| !【レイアウトクラス】 |
| At line 77 changed one line |
| !プログラムクラス |
| !【プログラムクラス】 |
| At line 83 changed 5 lines |
| *入荷実績登録プログラムクラスの登録メソッドが呼ばれる |
| *画面レイアウトクラスが持つ入力情報を受け取る |
| *入荷商品ごとに在庫商品の数量を増加させる |
| *入荷予定を消し込む |
| というふうに、画面の情報を基に複数の結果クラスの状態を変えていく動きをします。 |
| #入荷実績登録プログラムクラスの登録メソッドが呼ばれる |
| #画面レイアウトクラスが持つ入力情報を受け取る |
| #入荷商品ごとに在庫商品の数量を増加させる |
| #入荷予定を消し込む |
| というふうに、画面の情報を基に複数の結果クラスの状態を変えていく動きをします。\\ |
| プログラムクラスはプログラム自身を具現化したものなので、 |
| *プログラムID |
| *プログラム名称 |
| などの属性を持たせます。 |
| At line 89 changed 2 lines |
| *メインメソッドを持つクラス |
| アプリケーションが起動される入り口のクラスです。このクラスはメイン関数(メソッド)を持っているだけです。メイン関数の中からプログラムクラスのインスタンスを利用します。\\ |
| !【メインメクラス】 |
| アプリケーションが起動される入り口のクラスです。このクラスはメイン関数(メソッド)を持っているだけです。\\ |
| メインは関数にならざるを得ないため、この中での処理はログ出力やエラー時の対応など最低限にとどめ、プログラムクラスのインスタンスに早く委譲するようにすべきです。\\ |
| メインクラスはアプリケーションプログラム個別に作成する場合と汎用的に一つだけ持つ場合があり得ます。\\ |
| At line 118 added 18 lines |
| !!アプリケーションのクラス構成 |
| 上記で説明したクラスを受注伝票登録画面のアプリケーションとして仕上げる場合、次のような構成になります。 |
| [order_classes4.png] |
|
| !!まとめ |
| *中心となるクラスは「物」と「結果」 |
| *動詞のクラスを作ってはいけない |
| *クラスを抽出する前にオブジェクト図でまず考えてみる |
|
| !!コラム |
| 「処理がクラスだ」と思っている開発者が大勢います。そう思っていなくても結果的にそういう実装になっている人も多いのです。\\ |
| クラスを設計する際は、 |
| *どんな情報が必要か? |
| *どんな状態を持つ必要があるか? |
| だけをひたすら追求するようにしてみて下さい。あとはそれらの組み合わせ方(関連)を考えるだけです。\\ |
| それが出来るようになればきれいな設計に自然に近づきます。\\ |
| \\ |
| 次: [小粒クラス] |
