skillup

技術ブログ

アーキテクト設計全般

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

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

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

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

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

要点

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

感想

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

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

 

 

-アーキテクト設計全般

執筆者:


comment

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

関連記事

no image

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

LaravelのFacadeについて自作する機会があったので、メモ。 デザインパターンの一種かと思います。 Contents1 サンプル2 使い所3 メリット4 デメリット5 参考リンク サンプル h …

no image

ここ1年ぐらいで再確認したネタなど

今の現場では比較的、いわゆるモダンな環境で開発をしていることもあり、非常に勉強になります。 今の現場に入る前に10年近くはPHPをやっていますが、まだまだ知らないこと(といいますか新しいことがふえてき …

no image

値オブジェクトやファーストコレクションなどについて

以前から言葉としては知っていたけれど、オブジェクト思考の重要な概念に関して。 Contents1 値オブジェクト(Value Object)2 ファーストコレクション(コレクションオブジェクト) 値オ …

no image

DIについての再考察

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

no image

オブジェクト指向 データベース層

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にデータベース層の考え方について。 Contents1 データべース層1.1 要点1.1.1 典型的なダメテーブル設計1.1 …

アーカイブ