やったこと

現場で役立つシステム設計の原則 7章 読了

学んだこと

画面アプリケーション開発の難しさ

画面は、利用者の様々な要望に応える内に、徐々に複雑化する。
要望に応えるには、画面の表示処理に業務ロジックを埋め込むのが手っ取り早い。
しかし、この方法は、各クラスに業務ロジックが散らばる原因となり、ソフトウェアの複雑化を進める。

難しい原因

次の二つが主な原因

• 画面そのものが複雑
• 画面と表示ロジックと業務ロジックが分離できていない

どちらも、「関心事が分離できていない」ことに起因する。
つまり、以下のように関心事を整理すると、複雑さを軽減できる。

• 一つの汎用的な画面ではなく、複数のシンプルな画面構成とする
• 画面表示のロジックと、業務ロジックを分離する

複雑さ軽減の方針

画面とドメインオブジェクトを、うまく連動させる設計を目指すことが方針となる。

画面は利用者にとって視覚的な表現であり、ドメインオブジェクトは論理的な表現。
どちらも利用者の関心事を違う角度から表現しているにすぎないため、これらは十分連動可能。

画面の関心事を小さく分けて独立させる

小さな関心事（タスク）に分けて、タスクごとに画面とロジックを用意する。
-> タスクベースのユーザーインターフェースの採用

複雑な処理は、小さなタスクを組み合わせて達成する。

画面とドメインオブジェクトを連動させる

主な選択肢

• ドメインオブジェクトをそのまま画面表示にも使用する
  • タスクベースのユーザーインターフェースを採用する場合に有効
• 画面表示専用のオブジェクトを用意する
  • 万能画面を提供する場合に有効

ドメインオブジェクトに書くべきことを整理する

以下の3つの観点が重要。

• 論理的な情報構造はドメインオブジェクトで表現する
• 場合ごとの表示の違いをドメインオブジェクトで出しわける
• HTML の class 属性をドメインオブジェクトから出力する

論理的な情報構造はドメインオブジェクトで表現する

ビューの記述を、以下の二つに分離させる。

• 物理的なビュー
  • 画面表示する技術（≒HTML）に依存したビューの表現
  • 例) 段落を<p>タグや<br>で表現する
• 論理的なビュー
  • 「複数の段落」といった、論理構造だけを保持する
  • 例) 段落をString配列で保持する。段落分けや改行は、物理的なビュー側で表現する

場合ごとの表示の違いをドメインオブジェクトで出しわける

画面表示している条件分岐を、ドメインオブジェクト側へ移動できないか検討する

HTML の class 属性をドメインオブジェクトから出力する

例)
```
String readStatus() {
if (isUnread()) return "unread";
return "";
}

<p class="${mail.readStatus}">
```

加工や判断ロジックと、その結果どういった値を返すかは、ドメインオブジェクト側で保持しておくと良い。
画面表示ロジックにif文が現れるほうが問題。

可能な限り、画面とドメインオブジェクトの構造を一致させる

画面は利用者の関心事であり、画面とドメインオブジェクトが一致している状態は、利用者の関心事をとらえていることを意味する。

また、両者が一致している状態は、画面の変更にかかるドメインオブジェクトの変更箇所を発見しやすくなる。
つまり、変更が容易になる。

両者を一致させていく改善が、ドメインオブジェクトを洗練させる。