書籍

作者: 増田亨
出版社/メーカー: 技術評論社
発売日: 2017/07/05
メディア: Kindle版
この商品を含むブログ (4件) を見る

感想

かなりさらっと読めてしまった。プログラムの関心で設計するのではなく、業務の関心で設計していくことがオブジェクト指向の視点から重要という学びだった。マイクロサービスという言葉はあまり出てこないが、オブジェクト指向はマイクロサービスとかなり関連がある概念なのではないか。パッケージや業務ドメインの小さい単位で分類することで、プログラムの変更の影響を小さいものにして、安全で柔軟なソフトウェアを構築する技法がオブジェクト指向設計であるという認識である。

今まではデータは基本的にDTOを用いる設計が多かった、DTOの中に業務ロジックを記述したことはない。(int や String をラップして業務に特化したクラスを設計する、というアプローチもあまり業務では見かけなかったように思える。なぜだろうと思ったが、これは業務ロジックはほぼデータベースに寄せる設計であったからのように思える。)データとロジックと同じクラスにもつことがオブジェクト指向らしいクラス設計とあった。「データとロジックを1つのクラスにまとめる」という記述はこの書籍の中で何回も出現するのでよほど強調したい事項なのだろう。これは少し見直してみたい。概念的な理解をより具体化するためには、モノリシックなコードをリファクタリングすることで学べると感じている。新装版リファクタリングを通じて感じてみたい。

オブジェクト指向設計のよさは最初から完璧なクラス設計を実現するのではなく、重要度の高い業務から少しずつ改良していくことができることと感じた。サービスを利用する側になるべくロジックを寄せない。使われる側のクラスで完結させることでロジックの凝縮度が上がることは嬉しい。

メモ

(途中までw)

小さくまとめてわかりやすくする

設計
- ソフトウェア全体をすっきりした形に整えること
- どこに何が書いてあるかわかりやすくし、修正や拡張が楽で安全になるコードを生み出す
ソフトウェア開発は、このような「ちょっとした」コードの追加の繰り返し
変更が大変になるのは、決まって、こういうちょっとしたコードの修正や機能の拡張を繰り返したプログラム
目的ごとに別々のローカル変数を用意
メソッドとして独立させる
業務で使われる用語に合わせて、その用語の関心事に対応するクラスをドメインオブジェクト
目的に限定した小さなクラスが業務アプリケーションの基本部品
「値」を扱うために専用のクラスを作る
値オブジェクトは「不変」にする
- インスタンス変数はコンストラクタインジェクションする
- インスタンス変数を変更するメソッド(setterなど)は作らない
- 別の値が必要であれば、別のインスタンスを作る
コレクション型を扱うロジックを専用クラスに閉じ込める
あるクラスにデータとロジックを閉じ込める
使う側のプログラムの記述がかんたんになるように、使われる側のクラスに便利なメソッドを用意するのがオブジェクト指向設計のコツ
「業務の関心事」と、プログラミング単位である「クラス」を1対1に対応させる

場合分けのロジックを整理する

判断や処理のロジックをメソッドに独立させる
else句を書かない
区分ごとのロジックはプログラムを複雑にするやっかいな存在
使う側のクラスが、実際にどのような区分があるのか「知らない」ことが重要
ポリモフィズム
オブジェクト指向では、業務の関心事や業務ロジックを分析し整理する活動と、クラスを設計する活動は基本的に同じもの
型列挙を活用することで、見通しよく整理でき、変更も楽に安全にできる

業務ロジックをわかりやすく整理する

データクラスを使うと同じロジックがあちこちに重複する
クラスはデータとロジックを1つのプログラミング単位にまとめるしくみ
データとロジックを一体にして業務ロジックを整理する
三層のそれぞれの関心事と業務ロジックの分離を徹底する
オブジェクト指向らしいクラス設計
- メソッドをロジックの置き場にする
- ロジックをデータを持つクラスに移動する
- 使う側のクラスにロジックを書き始めたら設計を見直す
- メソッドを短くして、ロジックの移動をやりやすくする
- メソッドでは必ずインスタンス変数を使う
- クラスが肥大化したら小さく分ける
- パッケージを使って整理する
ロジックの置き場所やクラス名/メソッド名の改善を続け、より良い設計を見つけていくのが、オブジェクト指向設計の基本

ドメインモデルの考えで設計する

ドメインモデルで設計する狙い
- 業務的な判断/加工/計算のロジックを重複なく一元的に記述する
- 業務の関心事とコードを直接対応させ、どこに何が書いてあるかわかりやすく整理する
- 業務ルールの変更や追加のときに、変更の影響を狭い範囲に閉じ込める
ドメインモデルは対象業務(ドメイン)をオブジェクトの集合として表現する技法
全体を俯瞰する道具
- パッケージ図
- 業務フロー図
どうやって機能を実現するかに注目するのではなく、ある特定の業務のデータとそのデータを使った判断/加工/処理の業務ロジックだけを切り出した独立したオブジェクトを作る
業務の関心事を ヒト/モノ/コト で分類する

アプリケーションの機能を組み立てる

データベースの設計とドメインオブジェクト

画面とドメインオブジェクトの設計を連動させる

アプリケーション間の連携

アプリケーション間の連携方式

方法	説明
ファイル転送
データベース共有
Web API
メッセージング	メッセージ基盤*1を使って非同期にデータ(メッセージ)を送る