プログラム設計
クラス設計
このプログラムの核となるクラス(ドメインモデル)を以下に示します。
この図はER図でもなく、テーブル設計図ではありません。
あくまでクラス図です。
基本的にこれがこのままC#のコードとして実装されます。
しかし、データベースのテーブルとしてはこのまま実装することはできません。
Part1でもお話しした通り、テーブルの説明は一番最後に行います。
注目してほしいのは書籍クラスと和書クラス、洋書クラスの関係です。
書籍クラスは抽象クラスとなっています。
発送予定日の計算ルールが和書と洋書によって異なるため、「発送予定日を計算する」メソッドを抽象メソッドとし、具体的な実装は和書クラスと洋書クラス内でそれぞれ行われます。
レイヤー構成
このプログラムでは以下のような論理三階層アーキテクチャを採用します。
三階層といっても一番下の階層はNHibernateが担当しているので、実際にこちらで実装するのは上の2階層だけです。
DAO(Data Access Object)パターンなどを使って、FacadeをNHibernateに依存させないような設計も考えられますが、あまりコードが分散するのとサンプルコードが説明しづらくなるのでこのようなレイヤー構成にしました。
処理シーケンス
「書籍注文ページ」の「注文する」ボタンを押したあとの処理シーケンスを以下に示します。
注目してほしいのは「書籍を探す」から「発送予定日を返す」までのシーケンスです。
NHibernateは漠然と書籍クラスを返しますが、実際には和書クラスか洋書クラスのいずれかです。
ただし注文Facadeはそれがどちらのクラスなのかを意識しません。
注文Facadeは単純に書籍に対して「発送を予約する」とメッセージを送れば、適切な発送予定日が返却されます。
仕様上では「和書の場合」「洋書の場合」という条件分岐が発生していますが、ソースコード上ではこの条件分岐は登場しません。
オブジェクト指向に詳しい方ならもうお分かりだと思いますが、これが有名な「ポリモーフィズム」です。
詳しくは実装コードの紹介時に説明したいと思います。
プログラム設計に関する説明は以上です。
次回はみなさんお待ちかねの実装コードを説明していきます。
