『現場で役立つシステム設計の原則』
https://gyazo.com/85cd5fb742f0b0c9f4998484bed8130d
タイトルと表紙見て、本当に良い本なのか〜？？と思ってたが
これは読まなきゃ、という気持ちになったので即ポチった
OOPでの話をしている
サンプルコードはJava
コードはそんなに出てこない
OOPでmodelingするならめちゃくちゃ良い本だと思うmrsekut.icon
要点がまとまっていて簡潔
それでいてわかりやすい、読みやすい
もっと早く読みたかった
ダイジェスト
https://www.youtube.com/watch?v=CHJSnZb8dgk
第1章 小さくまとめてわかりやすくする
関数を小さく作る、などmrsekut.iconにとっては当たり前な話
やっぱOOPってだるいな、という気分になる
制限の緩すぎる言語を使って、制限を自分らで作って運用していくことになる
記述的に冗長にもなる
最初から制限が入っている言語を使ったほうが楽
知っている内容も多かったけど、これが1章にまとまっているのはすごく良いと思うmrsekut.icon
OOPをチームでやる時に、「この本の1章だけでも読んで！」と言えばだいぶマシになる
第2章 場合分けのロジックを整理する
区分ごとのロジックを別クラスに分ける
interfaceを使ってポリモーフィズムることで、if文を消せる
4章の話の伏線になっている
Javaの列挙型を使えばもっとかんたん
区分ごとの業務ロジックを区分オブジェクトで分析し整理する
状態の遷移ルールをわかりやすく記述する
第2章のまとめ
第3章 業務ロジックをわかりやすく整理する
DomainObjectのことは前から知っていたけど、
この章を読むことで、
データクラスと機能クラスを併用すること
DomainObjectを作ること
の違いがハッキリと分かるようになったので良かったmrsekut.icon
第4章 ドメインモデルの考え方で設計する
分析クラス
利用者の関心事を明らかにする
実装に基づいていないので自由になりすぎる
抽象的すぎて、これがどういうものを指しているのかいまいちわからんmrsekut.icon
なので、ここら一体の説明がほとんどよくわからない
設計
人間のやりたいことを動くソフトウェアとして実現する方法を考える
設計クラス
プログラミング単位を明らかにする
分析クラスと設計クラスを一致させることが重要
OOPは手続き型と違ってボトムアップに設計できる p.105
OOPもトップダウンだと思っていたmrsekut.icon
全体を俯瞰する方法
一応読んだけど、もっと複雑なアプリケーションを作る時に再読すると良さそう
ECのような、コトが役立つやつ
第5章 アプリケーション機能を組み立てる
ドメインモデルに業務ロジックを書く
UseCase的な
第6章 データベースの設計とドメインオブジェクト
めちゃくちゃ良い話ばかり書いているmrsekut.icon
第7章 画面とドメインオブジェクトの設計を連動させる
楽天の客層のように、ごちゃごちゃした画面が好きなユーザーが対象だと、そのデザインの複雑さにはモデリングが口出しできない感じがある
タスクベースのユーザーインターフェースにすべき
p.205
画面も分けてしまう
タスクベースのインターフェースが増えている2つの理由
タスクベースに分ける設計が今後の主流
画面とドメインオブジェクトを連動させる
選択肢
表示用のロジックを持つView専用objectを用意する
第8章 アプリケーション間の連携
アプリケーションを連携する4つのやり方
ファイル転送
DB共有
Web APIo
メッセージング
JSONよりも複雑なことを表現できる
非同期メッセージング
第9章 オブジェクト指向の開発プロセス
DDDの本の序盤に書いているような内容mrsekut.icon
分析と設計を同じ人がやって、ドメインモデルに落とし込む
コードのみで完結するものはコードで表現する
別途ドキュメントを書くことは不要
利用者に向けた文書などは書く
第10章 オブジェクト指向設計の学び方と教え方
OOPの学び方
リファクタリング
巨大なクラスの改善
参考文献一覧