skillup

技術ブログ

アーキテクト設計全般

オブジェクト指向 プレゼンテーション層

投稿日:2017年7月27日 更新日:

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。

本日はプレゼンテーション層、いわゆるMVCのViewにあたる部分。

プレゼンテーション層の考え方

要点

  • 画面ごとにプログラムを組むのではなく、関心ごとでプログラムを組む。そうしないと複数の画面でコードが重複する
  • 例えば詳細画面と登録確認画面は表示するデータの形式は一緒なことが多い。画面は違ってもプログラムは一緒
  • 関心ごとにより分け、画面の表示ロジックと業務ロジックを分離させる
  • 画面自体も機能ごとにわけ、あれもこれも詰め込まない(ECなら顧客氏名、注文内容、決済方法、配送手段、連絡先、注文確定などは分ける)
  • 画面の項目ごとに関心ごとをグルーピングする、あるいは画面自体を別にする。複数ステップ画面(タスクベースのユーザーインターフェイス)。1ページ、1メッセージ(プレゼント一緒!)
  • 画面とドメインオブジェクトが対応していないときは、ドメインオブジェクトの設計を見直す絶好のチャンス(関心ごとになっているのか?)。画面とドメインオブジェクトは利用者の関心ごとが一致するはず
  • 画面側のif文の分岐やcssの変更などもドメインオブジェクトの中に格納する。なぜならそれは関心ごとという枠組みだから。こうすることによりドメインオブジェクトだけを変更対象にすればOK。
  • 画面項目のグルーピング
    近接・・距離の近さは情報の近さ
    整理・・同じ意味のものは同じラインに。
    対比・・意味の重みの違いは文字の大きさや色の違いで区別
    反復・・同じ意味のものは同じパターンで

感想

画面項目を情報の意味でグルーピングするというのは、いろんな本でも書かれていたけど、基本ですね。今の業務アプリも特に注文画面にいろんな情報が詰め込まれており、あれもこれもになってしまっている。

というかデザインだけに限らずあらゆる領域で必要になってくる考え方だと思います。画面の分岐による変更ロジックをドメインオブジェクトの中に組み込む、というのは驚き(本書の中でもかかれていますが・・・)。ようはドメインオブジェクト=関心ごとなのだから、すべてドメインオブジェクトの中に入ってくるだろうということらしいんですね。

 

 

-アーキテクト設計全般

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

HTTPリクエストの分類について(POST、PUT、PATCT)

HTTPリクエストの分類(主に更新系のもの)について。 Contents1 POST2 PUT3 PATCH POST 更新系の代表的なHTTPリクエストですね。 通常はデータの取得=GET、更新=P …

no image

DIについての再考察

DIに関しては今までも何度か触れましたが、最終的には環境の差異を吸収できるなどが一番のポイントかと。 サンプルソース https://github.com/umanari145/effector 上記 …

no image

オブジェクト指向について その1

ちょっと最近、仕事でソースの書き方がいい加減になってきたのでオブジェクト指向について考え方を再確認しようと思います。 参考文献 SoftWareDesign 2015年9月号 何も考えずにプログラムを …

no image

オブジェクト指向について その3

今回は場合分けによる変更コストとオブジェクト指向のメリットについてです。 例えば給付金が発生して、その金額を死亡時、退職時、通常時で場合分けするとき、if-elseで書けば下記のようになります。 [c …

no image

Facadeパターンについて(Laravelを題材に)

LaravelのFacadeについて自作する機会があったので、メモ。 Contents1 サンプル2 使い所3 メリット4 デメリット5 参考リンク サンプル https://github.com/u …

アーカイブ