Java読書会「現場で役立つシステム設計の原則」を読む会 第2回に参加
遅れて午後から参加しました。今回は、書かれていることは確かに理想だけど...という切り口の議論が多かったように思います
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
- 作者: 増田亨
- 出版社/メーカー: 技術評論社
- 発売日: 2017/07/05
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
かんしんごと vs かんしんじ?
(業務の) 関心事 ← 「かんしんじ」vs.「かんしんごと」で意見が割れている。自分は「かんしんじ」派かなぁ #javareading
— YutakaKato.jar (@kagaorange) September 29, 2018
#javareading
— yuYabu@転職中 (@yuyabu2) 2018年9月29日
関心事=かんしんごと?かんしんじ?どっちの読みが正しい?という話になった。昔みた増田さんが話しているビデオだと「ごと」で読んでたような?
増田さんの発表を聞いた人のブログにも「関心ごと」と書かれているので多分「ごと」が適切だと思うのですがhttps://t.co/kn8w21bhpj
YutakaKatoさんと漢字の読みで張り合っています
私は著者が講演で「かんしんごと」と発音しているビデオ(1:28:2~)に影響を受け、これにつられて「かんしんごと」で通しています
なぜ「関心事」だけ「じ」と読むのでしょうか?
「心配事」はいわば和語扱い、「関心事」は漢語扱いだからです。
日本語の読み方的には「かんしんじ」が正しいようです😇。DDD界隈読みということもありえるのでしょうか。
まぁ漢字の読み方とかにこだわっているわけではありませんが、この本やたらと「関心事」という単語が出てくるので、どうしても気になってしまうのです。
なんと252回も!出てきますw
とりあえずDRYみたいなのは有害
- 共通しているからという理由でまとめてはいけない。ドメインの観点から検討して、本当に共通か? を意識して共通化する必要がある。
- 共通化というのは結果にすぎない。
- とにかくDRY原則!というのが有害
- 日時系のAPIは日付概念はものすごく抽象化されているから便利に使える
- とりあえずなんとなく共通処理をまとめました、だと誰も使わない
https://qiita.com/tag1216/items/91a471b33f383981bfaa
- ドメインを考えるのはすごく大変。重複クラスをまとめるだけなら脳みそを使わない。
Accountパターンの出どころは?
関心事のパターン | 業務ロジックの内容 |
---|---|
口座(Account)パターン | 現在の値(現在高)を表現し、妥当性を管理する |
期日(DueDate)パターン | 約束の期日と判断を表現する |
方針(Policy)パターン | 様々なルールが複合する、複雑な業務ロジックを表現する |
状態(State)パターン | 状態と、状態遷移のできる/できないを表現する |
業務ルールを記述するドメインオブジェクトの基本パターンより抜粋
ちょっと議論の内容は失念したが、こういうプログラミングのプラクティスは
エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)
- 作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート
- 出版社/メーカー: 翔泳社
- 発売日: 2005/04/21
- メディア: 大型本
- 購入: 10人 クリック: 635回
- この商品を含むブログ (143件) を見る
アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)
- 作者: マーチンファウラー,Martin Fowler,堀内一,友野晶夫,児玉公信,大脇文雄
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2002/04
- メディア: 単行本
- 購入: 7人 クリック: 89回
- この商品を含むブログ (70件) を見る
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (131件) を見る
などが元になっていたりするらしい。 読書家な人が集まっているので「このパターンは一般的なやつ、このパターンはXXに乗ってるやつだね」という流れになったが、Accountパターンは何が元になっているか?という結論が出なかった。 エリックエバンスの本は手元にあったので一応中を調べてみたが、それらしいものはなかった
- PoEAAの訳はひどい
- とても読めたものではないので捨てた
粒度の小さいクラスを大量に作ることの是非
本書では単位や属性のクラスをかなり細かく作成していくが、クラス数が増えるほど依存関係が増えたり複雑になるので、とりあえずクラスを小さくすれば良いというものではない。
個人的に大事なことは責務が混ざらない程度に小さくすることだと思う
他技術的なトピックなど
適当に議論中に出たトピックをまとめます
for文でコレクションを確認しているコードはStream APIのAnyMatchなどを使うべき
JavaのStringクラスの方がクラス設計としては良いが、結果的にRubyが文字列をただのバイト列として扱っているやり方のほうが結果的に成功している
- JavaがStringクラスに採用している設計パターンが結果的に良くなかったという趣旨の話があった
JSR-305
@NotNull
などのアノテーションの標準化
Kotlin最高
- Springの開発スピードが早い(Kotlinの開発がついていけてないらしい)
次回は「小さく分けたサービスを組み立てる」から