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

by MinoDriven

Slide 1

Slide 1 text

クソコード動画『カプセル化 Mk-II』で考える上手くカプセル化できない理由 2024/03/24(日) お茶の水女子大学オブジェクト指向カンファレンス2024 #ooc_2024 ミノ駆動 ( @MinoDriven )

Slide 2

Slide 2 text

この動画の解説スライドですクソコード動画『カプセル化 Mk-II』

Slide 3

Slide 3 text

ミノ駆動エンゲージメント向上サービスを手掛ける株式会社スタメンで働いていますアプリケーションアーキテクトとして以下設計全般に取り組んでおります ● 技術的負債の解消 ● アーキテクチャの再設計 ● 拡張性向上設計 ● エンジニアへの設計サポート（助言、提案など） @MinoDriven

Slide 4

Slide 4 text

著書紹介『良いコード／悪いコードで学ぶ設計入門』技術的負債を作り込まない変更容易性の高い設計を学ぶ初級〜中級向け入門書新卒エンジニアに最適です輪読会も多数開催されております発売 23ヶ月で 11刷重版発行部数 3万部超え

Slide 5

Slide 5 text

ITエンジニア本大賞2023 大賞受賞

Slide 6

Slide 6 text

ここから本題です

Slide 7

Slide 7 text

カプセル化　とはデータとそのデータを操作するロジックをひとまとめにすること。クラスベースオブジェクト指向言語では、カプセル化の手段としてクラスが提供されている。インスタンス変数とインスタンス変数を操作するメソッドとしてクラスにひとまとめにする。正常に操作可能なメソッドのみ実装し、公開する（setterは不正値も含めどんな値でも代入できてしまうため避けること）。 Class field : type method() インスタンスメソッドは、必ず自身のインスタンス変数を使うこと

Slide 8

Slide 8 text

関心の分離　とは関心ごとに構成を分離する考え方。カプセル化と表裏一体の関係にある。関心単位でカプセル化することにより、異なる関心を分離隔離できる。関心単位で分離することにより、ある関心の変更が別の関心に影響しなくなる。ある関心について考えている間、別の関心を忘れることができ、認知負荷が低減する。総じて保守や変更に強くなる。関心事A用のクラス関心事B用のクラス

Slide 9

Slide 9 text

ところが

Slide 10

Slide 10 text

上手くカプセル化したつもりでも壊されてしまう

Slide 11

Slide 11 text

状況により必要なデータ、不必要なデータが違う

Slide 12

Slide 12 text

予期しない変更影響が生じる、変更に弱くなってしまう

Slide 13

Slide 13 text

一体なぜだろう？こんなに頑張って設計してるのに…

Slide 14

Slide 14 text

ていうか関心って何だよ！？

Slide 15

Slide 15 text

カプセル化と関心について整理します

Slide 16

Slide 16 text

本発表の一番大事なことそれは…

Slide 17

Slide 17 text

目的

Slide 18

Slide 18 text

目的

Slide 19

Slide 19 text

目的

Slide 20

Slide 20 text

大事なことなので 3回言いました

Slide 21

Slide 21 text

目的を軸にカプセル化を紐解いていきます

Slide 22

Slide 22 text

システムとは一体なにか？

Slide 23

Slide 23 text

【手段】目的のために手段が編み出される【目的】目的地にはやく行きたい

Slide 24

Slide 24 text

【手段】【手段】【手段】システムとは目的達成手段【目的】食べ物を温めたい【目的】髪を乾かしたい【目的】掃除したい

Slide 25

Slide 25 text

当然ITシステムも目的達成手段【目的】商品を売買したい【目的】意思疎通したい【手段】 ECサイト【手段】 SNS

Slide 26

Slide 26 text

重要観点システムは手段手段には目的がある

Slide 27

Slide 27 text

目的の構造特性

Slide 28

Slide 28 text

【目的】山登りしたいたとえば「山登りしたい」という目的があるとする。何も考えずに山は登れるものでしょうか…？？いろいろリスクが考えられますね。

Slide 29

Slide 29 text

目的があってはじめて問題が顕在化する【目的】山登りしたい【問題】急な気温変化（低体温症、熱中症）【問題】遭難【問題】虫刺され

Slide 30

Slide 30 text

そして問題は（上位目的に対する）下位目的となる【上位目的】山登りしたい【下位目的】急な気温変化に対応したい【下位目的】正しいルートを把握したい【下位目的】虫刺されを防ぎたい

Slide 31

Slide 31 text

各目的に対応する解決手段を用意する【上位目的】山登りしたい【下位目的】急な気温変化に対応したい【下位目的】正しいルートを把握したい【下位目的】虫刺されを防ぎたい【手段】登山ウェア【手段】地図 GPS 【手段】虫除けスプレーおにやんまくん

Slide 32

Slide 32 text

つまり目的が決まることで目的達成に必要な要素が洗い出される【超重要】各目的それぞれで必要な要素は異なる

Slide 33

Slide 33 text

ECサイトの目的「商品売買」も下位目的に分解可能【上位目的】商品を売買したい【下位目的】在庫管理したい【下位目的】注文したい【下位目的】配送したい

Slide 34

Slide 34 text

やはり各目的それぞれで必要な要素やルールが異なる【上位目的】商品を売買したい【下位目的】在庫管理したい【下位目的】注文したい【下位目的】配送したい発注金額在庫量安定在庫量在庫回転期間入庫ルール発注ルール商品注文数注文金額支払い方法ポイントバック注文ルール梱包サイズ総重量配送元配送先配送ルート配送ルール

Slide 35

Slide 35 text

ちなみに目的の構造特性についてはこの書籍が詳しいです

Slide 36

Slide 36 text

ところで話は変わって都市伝説「電子レンジと濡れた猫」

Slide 37

Slide 37 text

ある人が濡れた猫を乾かしてあげようと猫を電子レンジに入れて温めたところ猫が死んでしまったという都市伝説な、なにをするつもりだ、ヤメロ…！！アバーーーーーーーーー！！！！！！

Slide 38

Slide 38 text

電子レンジを目的外に利用してしまった。家電製品の取扱説明書にも「目的外の使用で損害が生じた場合保証できない」とある。【目的】食べ物を温めたい【手段】電子レンジ【目的】猫を乾かしたい【超重要】手段から見て、対応する目的はひとつ

Slide 39

Slide 39 text

主張ソフトウェアでも同じことが言える

Slide 40

Slide 40 text

【目的】注文したいですわ【目的】予約したいですわ【目的】映画を沢山観たいですわ商品注文数注文金額支払い方法注文ルールポイント還元率商品注文数注文金額支払い方法予約日時予約ルールポイント還元率プラン名地域支払い方法サブスクルールポイント還元率各目的それぞれで必要な要素やルールが異なる

Slide 41

Slide 41 text

【手段】注文明細クラス【目的】注文したいですわ【目的】予約したいですわ【目的】映画を沢山観たいですわそ、そんなみんなの願いをいっぺんに叶えられるわけ…… どああああああああ！！！！注文明細クラスが多目的に使われていたのが原因。各目的（関心）のデータやルールが混在してしまい、なんとか動作させるためにむりやりsetterを追加する、例外的な処理を加えるなど、カプセル化を破らねばならなかった。

Slide 42

Slide 42 text

どうカプセル化すべきだったか【目的】注文したいですわ【目的】予約したいですわ【目的】映画を沢山観たいですわ【手段】予約クラス【手段】注文クラス【手段】映画サブスク注文クラスクラスが単目的になるよう設計する。ぞれぞれ、たったひとつの目的を確実に達成できるようデータやロジックをカプセル化する。

Slide 43

Slide 43 text

モデリングの話

Slide 44

Slide 44 text

保守性、変更容易性を高めるにはなんといってもモデリング

Slide 45

Slide 45 text

みなさん上手くモデリングできていますか？

Slide 46

Slide 46 text

どういう観点でモデリングしていますか？

Slide 47

Slide 47 text

商品モデル例えばECサイトのモデリングを考えてみます商品モデル……これでいいのでしょうか？？もうイヤな予感しかしないですね

Slide 48

Slide 48 text

【手段】商品モデル【目的】在庫管理【目的】注文【目的】配送あらゆる目的と結びついてあっという間に巨大化複雑化します

Slide 49

Slide 49 text

モデル　とはドメインにおける選択された側面を記述し、そのドメインに関連した問題を解決するのに使用できる抽象の体系。(*1) (*1)『エリック・エヴァンスのドメイン駆動設計』著： Eric Evans、監訳：今関剛、訳：和智右桂、牧野祐子、 2011年刊行、翔泳社、p.519より引用意訳）問題解決のために、物事の特定の側面を抽象化したもの

Slide 50

Slide 50 text

抽象化といってもどう抽象化すればいいんだろう？

Slide 51

Slide 51 text

目的論的抽象

Slide 52

Slide 52 text

https://qiita.com/hirokidaichi/items/61ad129eae43771d0fc3

Slide 53

Slide 53 text

『スケールする要求を支える仕様の「意図」と「直交性」』、著：広木大地より引用 https://qiita.com/hirokidaichi/items/61ad129eae43771d0fc3 (この記事では隠れた意図 (目的)を探り当てることで、直交性が高くなる、すならち変更に強い構造が得られる旨が解説されています )

Slide 54

Slide 54 text

存在論的な抽象化では目的に合う要素だけを上手く抽出できない目的論的な抽象化だと目的に合う要素を上手く抽出できる

Slide 55

Slide 55 text

冒頭で解説した重要観点システムは手段手段には目的がある

Slide 56

Slide 56 text

対象物に付随する様々な特徴のうち、ある目的に合致した特徴のみを抜き出すこと(*2) (*2)『「具体⇄抽象」トレーニング思考力が飛躍的にアップする 29問』著:細谷功, PHPビジネス新書, p.97より引用書籍『「具体⇄抽象」トレーニング』では抽象化を次のように説明しています。

Slide 57

Slide 57 text

つまりモデルとは何かを整理するとモデル：ある目的を達成するために、目的に合致した特徴のみを抜き出し、他を捨て去ったもの。モデリング：特徴を抜き出し、他を捨て去る活動。であると考えます。唯一無二の真のモデルなどは存在しません。そこにあるのは単なる選択であり、目的を満たすためのモデルを選択しなければなりません。(*3) (*3)『セキュア・バイ・デザイン安全なソフトウェア設計』著： Dan Bergh Johnsson、Daniel Deogun、Daniel Sawano、訳：須田智之、2021年刊行、マイナビ出版、 p.90より引用【重要】他の目的の要素は捨て去れ、ということ捨てないと他の関心が混ざり込んでしまう

Slide 58

Slide 58 text

【手段】注文品モデル【目的】在庫管理【目的】注文【目的】配送【手段】配送品モデル【手段】在庫品モデル目的を丁寧に見分けて区分し（←ココ重要）、各目的の達成に必要な特徴のみを抜き出し、モデルにしよう。

Slide 59

Slide 59 text

今日から使える！適切にカプセル化するための目的駆動アプローチ

Slide 60

Slide 60 text

カプセル化と関心（目的）の分離の基本 ● クラスを多目的に流用すると整合性維持が困難になります。変更に弱くなります。 ● クラスは単目的になるよう設計しましょう。 ● 目的の違うものは、それぞれ別のクラスに分離し、カプセル化しよう。

Slide 61

Slide 61 text

複雑なクラスを解消するための要点 ● 複雑で混乱したクラスがある場合、複数の目的のために利用されていないか疑いましょう。 ● 似たような目的が複数ある場合、見分けがつきにくいので要注意です。 ● 目的が異なると、扱うデータやロジックに差異が生じます。ある状況ではこのデータは使わない、または状況によって用いるロジックが違う場合、複数の目的が混在している可能性大です。 ● フラグやenumで処理を切り替えている箇所は、複数の目的に対応するために処理（手段）を切り替えている可能性大です。 ● 目的を列挙、整理しましょう。そして各目的に特化したクラスを再設計しましょう。

Slide 62

Slide 62 text

要求分析 ● PdMやドメインエキスパートとは、目的について話し合いましょう。目的とはたとえば顧客要求やプロダクトが提供したい価値です。 ● 問題は目的があって初めて顕在化します。「こういう問題を解決したい」という話になったら、なぜその問題を解決したいのか、根本にある目的を探りましょう ● 目的は人から生じます。ユースケース分析ではアクターを必ず洗い出しましょう。そして各アクターがどんな目的を持っているのか定義しましょう。このとき、微妙に異なる目的が含まれていないか特に注意です。目的が違っていたらアクターを分けましょう。目的：アクター＝１：１。

Slide 63

Slide 63 text

仕様策定 ● 手段に対して目的は1つです。そして仕様は目的達成のための手段です。 ● ある仕様がどの目的に対応するものか確認しましょう。 ● 仕様変更は特に注意が必要です。既存仕様が別に仕様に変わった場合、または付随仕様が追加される場合、目的に変化がないか、別の目的が加わっていないか注意しましょう。 ● 仕様書だけマルナゲされた場合、目的がわかりません。必ず目的を確認しにいきましょう。

Slide 64

Slide 64 text

……ここで終わりなんですが

Slide 65

Slide 65 text

伝えたいことが多すぎてこのスライドに全然おさまらん！本1冊書けてしまう

Slide 66

Slide 66 text

というわけで

Slide 67

Slide 67 text

特報

Slide 68

Slide 68 text

性懲りもなくまた本を書くことにしました

Slide 69

Slide 69 text

その名も

Slide 70

Slide 70 text

良いコード／悪いコードで学ぶ目的駆動設計（仮）

Slide 71

Slide 71 text

目的を主軸に、保守性や変更容易性の高いコードを設計するにはどうすればいいかを解説する設計本。今までよく分からなかった原理原則が、目的を切り口に理解できるようになる。前作同様膨大なサンプルコード付きで解説。

Slide 72

Slide 72 text

乞うご期待

Slide 73

Slide 73 text

クソコード動画はこのあとX(旧Twitter)に投下しますリツイートしてくれると嬉しいです

Slide 74

Slide 74 text

ご清聴ありがとうございました