実施日時：2020/2/12
対象範囲：第7章
参加者：yodai、くめごん、まぶり、kassyi

画面アプリケーションの開発
画面単位のプログラムはソフトウェアの記述を複雑にする。
入り組んだ画面を画面単位で開発すると画面の複雑さに引きずられてプログラムが肥大化する。
画面アプリケーションのコードが複雑で変更が厄介になる原因
・画面そのものが複雑
・画面の表示ロジックと業務ロジックが分離できていない
これを変更する
・汎用画面でなく、用途ごとシンプルな画面にする
・画面のロジックと業務ロジックを分ける
画面を関心事ごとに分ける
大きなメソッドを関心事ごとに小さなメソッドに分ける
用途を特定した小さな単位に分けた画面にする
→タスクベースのユーザーインタフェース
議論：
今の画面開発は、スマートフォンの画面を作成してからPC用の画面を作成する。
表示速度の問題も大きい、ある一定以上だと離脱率が跳ね上がる。
一度に大きなデータの通信するやり方から、小さな単位で頻繁に通信するやり方に変化している。
何でも画面（複合画面）のニーズはあるが、内部の設計はタスクベースにするべき。
画面の設計は以下の3つの方法がある
１．ドメインオブジェクトをそのまま画面に対応する
２．ビュー専用のオブジェクトを用意する
３．データの受け渡しのデータクラスを用意
３は使うべきでない、１と２なら１を重視するべき
現在は、画面にロジックを書くのが主流、PHPとか
物理的な表現手段（pタグや字下げとか）はドメインオブジェクトで持つべきでない
論理的な表現手段はドメインオブジェクトで持つ
場合ごとの表現の違いをドメインオブジェクトで出しわける
検索結果の画面表示をドメインオブジェクトで持つ
→・・・件見つかった、見つかりませんでしたなど
→議論：
　画面表示用のロジックを作るべきだと思う
画面（視覚表現）とソフトウェア（論理構造）を関連付ける
画面での項目の並びと、クラスのフィールドの並び順を一致させる
近接／整列／対比／反復のデザイン原則とドメインオブジェクトの設計を一致させる
プレスリリース、リリースノート、利用者ガイドの内容が一致している事が大事
不一致ならば何かの問題がある
オブジェクト指向とは、利用者の関心事とプログラムの表現を一致させるための工夫