クソコード動画『カプセル化 Mk-II』 で考える 上手くカプセル化できない理由 / encapsulation2

オブジェクト指向カンファレンス2024

クソコード動画『カプセル化 Mk-II』
https://twitter.com/MinoDriven/status/1771763728234537310

下記セッションで用いたスライドです
https://fortee.jp/oocon-2024/proposal/9e935d37-5480-4488-bc6d-3b9ee492106f

1. クソコード動画『カプセル化 Mk-II』 で考える 上手くカプセル化できない理由 2024/03/24(日) お茶の水女子大学 オブジェクト指向カンファレンス2024 #ooc_2024 ミノ駆動 ( @MinoDriven )
2. この動画の解説スライドです クソコード動画『カプセル化 Mk-II』
3. ミノ駆動 エンゲージメント向上サービスを手掛ける 株式会社スタメンで働いています アプリケーションアーキテクトとして 以下設計全般に取り組んでおります • 技術的負債の解消 • アーキテクチャの再設計 • 拡張性向上設計 • エンジニアへの設計サポート（助言、提案など） @MinoDriven
4. 著書紹介 『良いコード／悪いコードで学ぶ設計入門』 技術的負債を作り込まない 変更容易性の高い設計を学ぶ 初級〜中級向け入門書 新卒エンジニアに最適です 輪読会も多数開催されております 発売 23ヶ月で 11刷重版 発行部数 3万部 超え
5. ITエンジニア本大賞2023 大賞受賞
6. ここから本題です
7. カプセル化　とは データとそのデータを操作するロジックをひとまとめに すること。 クラスベースオブジェクト指向言語では、カプセル化の 手段としてクラスが提供されている。 インスタンス変数とインスタンス変数を操作するメソッ ドとしてクラスにひとまとめにする。 正常に操作可能なメソッドのみ実装し、公開する （setterは不正値も含めどんな値でも代入できてしまう ため避けること）。 Class field : type method() インスタンスメソッドは、必ず 自身のインスタンス変数を使 うこと
8. 関心の分離　とは 関心ごとに構成を分離する考え方。カプセル化と表裏一体の関係にある。 関心単位でカプセル化することにより、異なる関心を分離隔離できる。 関心単位で分離することにより、ある関心の変更が別の関心に影響しなくなる。ある関 心について考えている間、別の関心を忘れることができ、認知負荷が低減する。総じて 保守や変更に強くなる。 関心事A用の クラス 関心事B用の クラス
9. ところが
10. 上手くカプセル化したつもりでも壊されてしまう
11. 状況により必要なデータ、不必要なデータが違う
12. 予期しない変更影響が生じる、変更に弱くなってしまう
13. 一体なぜだろう？ こんなに頑張って設計してるのに…
14. ていうか 関心って何だよ！？
15. カプセル化と関心について 整理します
16. 本発表の一番大事なこと それは…
17. 目的
18. 目的
19. 目的
20. 大事なことなので 3回言いました
21. 目的を軸に カプセル化を紐解いていきます
22. システムとは一体なにか？
23. 【手段】 目的のために手段が編み出される 【目的】 目的地に はやく行きたい
24. 【手段】 【手段】 【手段】 システムとは目的達成手段 【目的】 食べ物を温めたい 【目的】 髪を乾かしたい 【目的】 掃除したい
25. 当然ITシステムも目的達成手段 【目的】 商品を売買したい 【目的】 意思疎通したい 【手段】 ECサイト 【手段】 SNS
26. 重要観点 システムは手段 手段には目的がある
27. 目的の構造特性
28. 【目的】 山登りしたい たとえば「山登りしたい」という目的があるとする。 何も考えずに山は登れるものでしょうか…？？ いろいろリスクが考えられますね。
29. 目的があってはじめて問題が顕在化する 【目的】 山登りしたい 【問題】 急な気温変化 （低体温症、熱中症） 【問題】 遭難 【問題】 虫刺され
30. そして問題は（上位目的に対する）下位目的となる 【上位目的】 山登りしたい 【下位目的】 急な気温変化に 対応したい 【下位目的】 正しいルートを 把握したい 【下位目的】 虫刺されを 防ぎたい
31. 各目的に対応する解決手段を用意する 【上位目的】 山登りしたい 【下位目的】 急な気温変化に 対応したい 【下位目的】 正しいルートを 把握したい 【下位目的】 虫刺されを 防ぎたい 【手段】 登山ウェア 【手段】 地図 GPS 【手段】 虫除けスプレー おにやんまくん
32. つまり目的が決まることで 目的達成に必要な要素が洗い出される 【超重要】 各目的それぞれで 必要な要素は異なる
33. ECサイトの目的「商品売買」も下位目的に分解可能 【上位目的】 商品を売買したい 【下位目的】 在庫管理したい 【下位目的】 注文したい 【下位目的】 配送したい
34. やはり各目的それぞれで必要な要素やルールが異なる 【上位目的】 商品を売買したい 【下位目的】 在庫管理したい 【下位目的】 注文したい 【下位目的】 配送したい 発注金額 在庫量 安定在庫量 在庫回転期間 入庫ルール 発注ルール 商品 注文数 注文金額 支払い方法 ポイントバック 注文ルール 梱包サイズ 総重量 配送元 配送先 配送ルート 配送ルール
35. ちなみに目的の構造特性についてはこの書籍が詳しいです
36. ところで話は変わって 都市伝説「電子レンジと濡れた猫」
37. ある人が濡れた猫を乾かしてあげようと猫を電子レンジに入れて 温めたところ猫が死んでしまったという都市伝説 な、なにをするつもりだ、ヤメロ…！！ アバーーーーーーーーー！！！！！！
38. 電子レンジを目的外に利用してしまった。 家電製品の取扱説明書にも「目的外の使用で損害が生じ た場合保証できない」とある。 【目的】 食べ物を温めたい 【手段】 電子レンジ 【目的】 猫を乾かしたい 【超重要】手段から見て、対応する目的はひとつ
39. 主張 ソフトウェアでも 同じことが言える
40. 【目的】 注文したいですわ 【目的】 予約したいですわ 【目的】 映画を沢山観たいですわ 商品 注文数 注文金額 支払い方法 注文ルール ポイント還元率 商品 注文数 注文金額 支払い方法 予約日時 予約ルール ポイント還元率 プラン名 地域 支払い方法 サブスクルール ポイント還元率 各目的それぞれで必要な要素やルールが異なる
41. 【手段】 注文明細クラス 【目的】 注文したいですわ 【目的】 予約したいですわ 【目的】 映画を沢山観たいですわ そ、そんなみんなの願いをいっぺん に叶えられるわけ…… どああああああああ！！！！ 注文明細クラスが多目的に使われていたのが原因。 各目的（関心）のデータやルールが混在してしまい、なんとか動作 させるためにむりやりsetterを追加する、例外的な処理を加えるな ど、カプセル化を破らねばならなかった。
42. どうカプセル化すべきだったか 【目的】 注文したいですわ 【目的】 予約したいですわ 【目的】 映画を沢山観たいですわ 【手段】 予約クラス 【手段】 注文クラス 【手段】 映画サブスク 注文クラス クラスが単目的になるよう設計する。ぞれぞれ、たったひとつの 目的を確実に達成できるようデータやロジックをカプセル化する。
43. モデリングの話
44. 保守性、変更容易性を高めるには なんといってもモデリング
45. みなさん上手く モデリングできていますか？
46. どういう観点で モデリングしていますか？
47. 商品モデル 例えばECサイトのモデリングを考えてみます 商品モデル……これでいいのでしょうか？？ もうイヤな予感しかしないですね
48. 【手段】 商品モデル 【目的】 在庫管理 【目的】 注文 【目的】 配送 あらゆる目的と結びついて あっという間に巨大化複雑化します
49. モデル　とは ドメインにおける選択された側面を記述し、そのドメインに関 連した問題を解決するのに使用できる抽象の体系。(*1) (*1)『エリック・エヴァンスのドメイン駆動設計』著： Eric Evans、監訳：今関剛、訳：和智右桂、牧野祐子、 2011年 刊行、翔泳社、p.519より引用 意訳）問題解決のために、物事の特定の側面を抽象化し たもの
50. 抽象化といっても どう抽象化すればいいんだろう？
51. 目的論的抽象
52. https://qiita.com/hirokidaichi/items/61ad129eae43771d0fc3
53. 『スケールする要求を支える仕様の「意図」と「直交性」』、著：広木大地 より引用 https://qiita.com/hirokidaichi/items/61ad129eae43771d0fc3 (この記事では隠れた意図 (目的)を探り当てることで、直交性が高くなる、すならち変更に強い構造 が得られる旨が解説されています )
54. 存在論的な抽象化では 目的に合う要素だけを上手く抽出できない 目的論的な抽象化だと 目的に合う要素を上手く抽出できる
55. 冒頭で解説した重要観点 システムは手段 手段には目的がある
56. 対象物に付随する様々な特徴のうち、 ある目的に合致した特 徴のみを抜き出すこと(*2) (*2)『「具体⇄抽象」トレーニング 思考力が飛躍的にアップする 29問』 著:細谷功, PHPビジネス新書, p.97より引 用 書籍『「具体⇄抽象」トレーニング』では 抽象化を次のように説明しています。
57. つまりモデルとは何かを整理すると モデル：ある目的を達成するために、目的に合致した特徴の みを抜き出し、他を捨て去ったもの。 モデリング：特徴を抜き出し、他を捨て去る活動。 であると考えます。 唯一無二の真のモデルなどは存在しません。そこにあるのは 単なる選択であり、目的を満たすためのモデルを選択しなけ ればなりません。(*3) (*3)『セキュア・バイ・デザイン 安全なソフトウェア設計』著： Dan Bergh Johnsson、Daniel Deogun、Daniel Sawano、訳：須田智之、2021年刊行、マイナビ出版、 p.90より引用 【重要】他の目的の要素は捨て去れ、ということ 捨てないと他の関心が混ざり込んでしまう
58. 【手段】 注文品モデル 【目的】 在庫管理 【目的】 注文 【目的】 配送 【手段】 配送品モデル 【手段】 在庫品モデル 目的を丁寧に見分けて区分し（←ココ重要）、 各目的の達成に必要な特徴のみを抜き出し、モデルにしよう。
59. 今日から使える！ 適切にカプセル化するための 目的駆動アプローチ
60. カプセル化と関心（目的）の分離の基本 • クラスを多目的に流用すると整合性維持が困難になります。変更に弱くなります。 • クラスは単目的になるよう設計しましょう。 • 目的の違うものは、それぞれ別のクラスに分離し、カプセル化しよう。
61. 複雑なクラスを解消するための要点 • 複雑で混乱したクラスがある場合、複数の目的のために利用されていないか疑い ましょう。 • 似たような目的が複数ある場合、見分けがつきにくいので要注意です。 • 目的が異なると、扱うデータやロジックに差異が生じます。ある状況ではこのデータ は使わない、または状況によって用いるロジックが違う場合、複数の目的が混在し ている可能性大です。 • フラグやenumで処理を切り替えている箇所は、複数の目的に対応するために処理 （手段）を切り替えている可能性大です。 • 目的を列挙、整理しましょう。そして各目的に特化したクラスを再設計しましょう。
62. 要求分析 • PdMやドメインエキスパートとは、目的について話し合いましょう。目的とはたとえ ば顧客要求やプロダクトが提供したい価値です。 • 問題は目的があって初めて顕在化します。「こういう問題を解決したい」という話に なったら、なぜその問題を解決したいのか、根本にある目的を探りましょう • 目的は人から生じます。ユースケース分析ではアクターを必ず洗い出しましょう。そ して各アクターがどんな目的を持っているのか定義しましょう。このとき、微妙に異 なる目的が含まれていないか特に注意です。目的が違っていたらアクターを分けま しょう。目的：アクター＝１：１。
63. 仕様策定 • 手段に対して目的は1つです。そして仕様は目的達成のための手段です。 • ある仕様がどの目的に対応するものか確認しましょう。 • 仕様変更は特に注意が必要です。既存仕様が別に仕様に変わった場合、または 付随仕様が追加される場合、目的に変化がないか、別の目的が加わっていないか 注意しましょう。 • 仕様書だけマルナゲされた場合、目的がわかりません。必ず目的を確認しにいきま しょう。
64. ……ここで終わりなんですが
65. 伝えたいことが多すぎて このスライドに全然おさまらん！ 本1冊書けてしまう
66. というわけで
67. 特報
68. 性懲りもなく また本を書くことにしました
69. その名も
70. 良いコード／悪いコードで学ぶ 目的駆動設計（仮）
71. 目的を主軸に、保守性や変更容易性の高いコードを設計するに はどうすればいいかを解説する設計本。 今までよく分からなかった原理原則が、目的を切り口に理解でき るようになる。 前作同様膨大なサンプルコード付きで解説。
72. 乞うご期待
73. クソコード動画は このあとX(旧Twitter)に投下します リツイートしてくれると嬉しいです
74. ご清聴ありがとうございました