『現場で役立つシステム設計の原則』の画面とドメインオブジェクトを一致させる章を読んだが異文化に衝撃を受けた
異文化すぎて理解に苦しむ箇所もいくつかあったが、もちろん面白い箇所もあった。
タスクベースの画面いいよね
たしかに。しかも後の方で「とはいえなんでもできる画面の需要が尽きないのもわかるから、そういう時はドメインオブジェクトは分けつつもそれらを協調させるドメインオブジェクトを一つ切るといいよ」と書いてあって、さらに納得感が増した。 使えるようになるために学習が必要だけど使えるようになると1画面でなんでもできる、ってのはたしかに(特に社内ツールとかで)尽きない需要だと思う。
どこまでは「論理ビュー」で、どこからが「物理ビュー」なのか?
ここが自分ではよくわからなかった。読書会を一緒にやった同僚たちも首をかしげていた。 論理ビューとはプログラミング言語で出力を担保するビュー情報のこと、物理ビューとはテンプレートエンジンで出力を担保するビュー情報のことのようだ。
筆者いわく
- 段落の論理構造は
String[]
と表現できる論理ビュー - 「
<p>
タグとか、段落の先頭を全角一文字で字下げするといった物理的な手段」は物理ビュー - 場合によって出し分ける文言は論理ビュー(0件なら「見つかりませんでした」、1件なら「1件みつかりました」など)
- HTMLのclass属性は論理ビュー
あ、class属性はアプリケーションコードで持って良いんだ、と驚いた。 それまでの3つはたとえばHTMLでもJSONでも必要な情報だし、むしろどちらでも使える情報だからビューよりのドメインオブジェクトに持っておくのは筋が良いと思う。 そもそもビュー専用のオブジェクトが存在するのはよくあるパターンだし、全然理解できる。
でもclassはHTMLでしか必要ない。
その後で「画面を表示するロジックにif文が入り込み始めたら、要注意です」とあるが、たとえばclass属性の出し分け条件をドメインオブジェクトに寄せたとして、特定の条件の時にDOM自体を出したり出さなかったりする時はどうするんだろう。空の内容を描画しちゃって display: none;
はあまり筋が良いと思えない。
自分でこの本の内容を実践する時、どうするかなぁ。 ビューから全くif文がないこと、はコード品質の合格条件には入れられない気がする。
Clojureで書けば全部Clojureだからビューだろうがなんだろうが簡単に単体テストを書けるんだけど、それとこれとはちょっと話のレイヤーが違うからそれで解決したことにしちゃうのは反則技っぽいし、もうちょっとぼんやり考えよう。
その後
上の説明の後は、コードも段落分けすることだとか、プロパティをグルーピングすることなどが載っていた。そういう意味でのキレイさの話。