■

 「現場で役立つシステム設計の原則～変更を楽で安全にするオブジェクト思考の実践技法」を読む。

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

オブジェクト思考を学びたいならこれ！的にQiitaで良くお勧めされてたので読んでみた。良い例と悪い例をJavaの実際のコードで比較する形で紹介しており、分かりやすい。Javaを書いたことはほとんどないが、こういう書き方ほとんど意識してなかったなぁと感じる。例によって、自分に刺さったフレーズを備忘録としてメモっておく。

・「業務の理解とプログラムの設計を直接的に関連付ける。」
・「小さなクラスでわかりやすく安全に」
・「Javaは「クラスに基づいた、オブジェクト指向の汎用のプログラミング言語」として開発された。」
手続き型言語(COBOLやC)ではデータと機能を分けて書くが、クラスとはそもそもそれを一つにまとめる仕組みである。
ポイント
　メソッドをロジックの置き場所にする。
　ロジックを、データを持つクラスに移動する。
　メソッドを短くする。
　メソッドでは必ずインスタンス変数を使う。使ってないのは要はロジックがないということ。
・値を扱うためには専用のクラスを作り、不変にして使いまわさない。
・コレクションや配列を扱うとき、getterやsetterメソッドを使わない。
内容を書き替えずに安定させる。
この設計を完全コンストラクタという。
・if文を使う時は、判断や処理のロジックを中にかかず、別のメソッドに抽出する。
・if文を使う時はelse句を使ってローカル変数に代入する書き方をしちゃだめ。
・オブジェクト思考はボトムアップで部分と全体を行き来しながら作っていく。
。・ソースコードで業務の要求仕様を表現することをプログラムの自己文書化という。
・三層＋ドメインモデルの構造を実装するためのフレームワークにSpring Frameworkがある。
早期リターンとかガード節という。
・ネストになっていたif文を単文に出来れば、それぞれが疏結合になり順番を変えてもうまく動作できる。
・異なるクラスのオブジェクトを同じ型として使えることを多態という。
多態も疏結合を実現する書き方。
・列挙型(enum)を使って区分ごとのロジックを整理することを区分オブジェクトという。
審査中とか承認中とか実施中とか、業務ロジックと結びついて理解できる。
・テーブル設計として、「予備項目」とかnullの項目を作っておくのは良くない例。
・テーブル設計として、NotNull制約や外部キー制約などを使って不要なデータが入らないようにして正規化する。
・コトの記録として、記録タイミングが異なる事実は別のテーブルに記録する。
・オブジェクトとテーブルをマッピングするフレームワークSQL Mapper。
・画面設計として、タスクベースのユーザーインターフェースを心がける。
汎用的に全ての項目を一画面に表示させず、用途ごとに小さく画面を切りだすことでユーザも使いやすくなる。
・画面表示用のロジックを持つビュー専用オブジェクトを用意する。
・アプリ連携はJSONやXMLも良いが、Web APIを使うのが懸命。
・SeaggerUIとかSpring MVCのRestControllerやJSOとオブジェクトのマッピングに使うJacksonが便利。
・非機能要件はテストコードとして記述しておけばソースコードで自己文書化出来る。
・手っ取り早くオブジェクト指向を学ぶためには、リファクタリングしてクラスを小さくする。