Tweet
Tweet

Slide 1

Slide 1 text

一緒に使うことが多い値は 別クラスにしよう （Data Clumps） リーダブルコード LT会 - vol.4 #readablelt 20220824 きり丸（水上　皓登）@nainaistar

Slide 2

Slide 2 text

※ Javaのソースコードで例示します。

Slide 3

Slide 3 text

名前：きり丸（水上 皓登） twitter：nainaistar GitHub：hirotoKirimaru ブログ：きり丸の技術日記 https://nainaistar.hatenablog.com/ 3 一度でいいから バズってみたい

Slide 4

Slide 4 text

良いコードとは？

Slide 5

Slide 5 text

良いコードとは悪くないコード

Slide 6

Slide 6 text

悪くないコードにするには、 Code Smellsに気を付けたらいい

Slide 7

Slide 7 text

今日のキーワード Data Clumps （データの塊）

Slide 8

Slide 8 text

Data Clumpsとは （データの塊） 関連性が高く、一緒に使われることが多いデータを 別のクラスにまとめること。 モデリングをしっかりしている人にとっては、 当たり前といえば当たり前のお話です。

Slide 9

Slide 9 text

期間（日付）

Slide 10

Slide 10 text

例えば、期間（日付） 開始日　または　終了日を纏めたクラスがあるとします。 最低限の仕様としては次の挙動が考えられます ● 存在する日付であること（2022/02/31は許容しない） ○ 文字列型ではなく、日付型なら発生しない ● 開始日は必須であること（終了日がないパターンは期間無限） ● 開始日のほうが終了日より古いこと（期間の逆転禁止）

Slide 11

Slide 11 text

例えば、 期間（日付） public class サブスクリプション { String id; LocalDate contractStartDate; LocalDate contractEndDate; int qty; BigDecimal price; } サブスクリプション のモデル。 契約開始日、契約終了日 を持っています。

Slide 12

Slide 12 text

例えば、 期間（日付） public class サブスクリプション { String id; 期間 contractTerm; int qty; BigDecimal price; } public record 期間( LocalDate start, LocalDate end ){ } ちょっとすっきり。 契約の開始日ではなく、 開始日、終了日と 単語を短縮できるのも好き。

Slide 13

Slide 13 text

例えば、期間（日付） 複雑な仕様も閉じ込めることができます ● 経過期間の計算 ○ 2022/01/15-2022/12/31 -> 11ヵ月？12ヵ月？ ● 期間が暦上の一か月で割り切れるかどうか。 ○ 開始日に対して、日割の発生しない終了日であるか ● 期間の重複チェック ○ A.start <= B.end && B.start <= A.end

Slide 14

Slide 14 text

例えば、期間（日付） 期間と期間の比較は初見は面倒。

Slide 15

Slide 15 text

期間（時刻）

Slide 16

Slide 16 text

例えば、期間（時刻） 株式市場の取引時間をアプリで管理するとします。 日本市場：0900-1500(9時から15時) 米国市場：2330-0600(23時30分から翌6時) 仮想通貨：0000-2400(24時間いつでも可能)

Slide 17

Slide 17 text

例えば、 期間（時刻） public class 取引時間 { String id; String startTime; String endTime; public isBusinessTime(LocalDateTime now) { // いい感じの処理 } } Stringの”0900”と”1500” を元に、 いい感じに処理する

Slide 18

Slide 18 text

例えば、期間（時刻） 日付を跨ぐ処理はどうしよう…？ 2400が上限値ではない？ 休み時間は…？ Stringをたくさんいじりたくないな…

Slide 19

Slide 19 text

例えば、期間（時刻） 開始時刻は同じように管理して、 終了時刻ではなくN時間連続して 営業していることを示せばいいのでは？ フレックスのように、 9:00勤務開始、18:00勤務終了 が大事ではなく、勤務時間が8H確保していることが大事では？

Slide 20

Slide 20 text

例えば、 期間（時刻） public class 取引時間 { String id; String startTime; int straightHours; public isBusinessTime(LocalDateTime now) { // いい感じの処理 } } 終了時刻はすぐにわからない が、日付を跨ぐ場合には優し いかもしれない

Slide 21

Slide 21 text

例えば、期間（時刻） このモデルが絶対的な正義だという話ではありません。 必要なデータだけに絞って注目し、 制約事項を丁寧に処理していた結果、 当初、想像できなかったモデリングに 導かれることがありうるという例です。

Slide 22

Slide 22 text

DBの複合キー

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

DBの複合キー public class 企業 { String 企業ID; } public class 契約 { String 企業ID; String 契約ID; } public class 販売 { String 企業ID; String 契約ID; String 販売ID; } public class 仕入 { String 企業ID; String 契約ID; String 販売ID; String 仕入ID; } 適切な例が思い浮かばず…

Slide 25

Slide 25 text

例えば、DBの複合キー 複合キー自体が、既にデータの塊。 あくまで一意に定めるための塊であり、振る舞いを持つものではない ただ、名前を持ったデータの塊は意図が非常に伝わりやすい。 例： ・企業IDと契約IDと販売IDから仕入全体の金額を知りたい ・この販売の仕入全体の金額を知りたい

Slide 26

Slide 26 text

※ 私がコードリーディングする時の 脳内に浮かんでいる図です

Slide 27

Slide 27 text

DBの複合キー public class 販売主キー { String 企業ID; String 契約ID; String 販売ID; } public class 仕入 { String 企業ID; String 契約ID; String 販売ID; String 仕入ID; 　# パラメータが一つにまとまる public boolean salesEquals(販売主キー id) { return (this.企業ID.equals(id.企業ID) && this.契約ID.equals(id.契約ID) && this.販売ID.equals(id.販売ID)) } } 販売の複合主キーとして、親 のIDをすべて持つ前提

Slide 28

Slide 28 text

DBの複合キー 企業IDと 契約IDと 販売IDから 仕入全体の金額を知りたい あまりER図は意識しない

Slide 29

Slide 29 text

仕入 企業IDで絞込 契約IDで絞込 販売IDで絞込

Slide 30

Slide 30 text

DBの複合キー この販売の 仕入全体の金額を知りたい コードリーディングで 認識すべき内容が減る

Slide 31

Slide 31 text

仕入 仕入 販売 販売

Slide 32

Slide 32 text

例えば、DBの複合キー ばらばらのデータだと、それぞれの値に関係性がない可能性がある。 一つのデータの塊にすると、意図を伝えてくれる。 特にER図で考えたときに、複合主キーという存在は、 データの絞込ではなく、一意に決定づけられるため、 思考コストが減る。

Slide 33

Slide 33 text

ちょっと脱線

Slide 34

Slide 34 text

ちょっと脱線 ● オブジェクト化したからと言って、 DBの構造も合わせる必要はありません。

Slide 35

Slide 35 text

例えば、 期間（日付） public class 販売 { String id; 期間 salesTerm; int qty; BigDecimal price; } public record 期間( LocalDate start, LocalDate end ){ } Javaの構造。

Slide 36

Slide 36 text

例えば、 期間（日付） CREATE TABLE 販売 ( id VARCHAR(13) PRIMARY KEY, start_date TIMESTAMP, end_date TIMESTAMP, qty INTEGER, price INTEGER, ); DBの構造。

Slide 37

Slide 37 text

例えば、 期間（日付） CREATE TABLE 販売 ( id VARCHAR(13) PRIMARY KEY, term_id VARCHAR(13), qty INTEGER, price INTEGER, ); CREATE TABLE 期間 ( id VARCHAR(13) PRIMARY KEY, start_date TIMESTAMP, end_date TIMESTAMP, ) わざわざ ここまでする必要はない。

Slide 38

Slide 38 text

例えば、 期間（時刻） CREATE TABLE 取引時間 ( id VARCHAR(13) PRIMARY KEY, start_time VARCHAR(4), end_time VARCHAR(4), ); CREATE TABLE 取引時間 ( id VARCHAR(13) PRIMARY KEY, start_time VARCHAR(4), straight_hours INTEGER ); モデリングの結果、 DBの構造を変えること自体は 良いこと

Slide 39

Slide 39 text

ちょっと脱線 ● 使いづらくなったら、 データ構造を解体してフラットにするのは全然あり

Slide 40

Slide 40 text

例えば、 期間（日付） public class サブスクリプション { 期間 contractTerm; LocalDate cancelDate; public boolean isCancelable{ // 期間クラスの開始日を使用する。 // 別クラスの属性を欲しがるという意味のCode Smells // Feature Envy // が起きかねない return this.contractTerm.start .isAfter(cancelDate) } } 解約日 という概念を追加。

Slide 41

Slide 41 text

例えば、 期間（日付） public class サブスクリプション { 期間 contractTerm; LocalDate cancelDate; } ↓ public class サブスクリプション { LocalDate contractStartDate; LocalDate contractEndDate; LocalDate cancelDate; public boolean cancelable?(){ return 　　　 // 期間クラスに // 解約可能かどうか判断メソッドを作ってもいい // 作らなくてもいい new 期間(contractStartDate, cancelDate) .noProration() } } 使いづらかったら、 データ構造をフラットに するのはあり。

Slide 42

Slide 42 text

ちょっと待って メリットだけなの？

Slide 43

Slide 43 text

メリットだけなの？ ● プリミティブな値をオブジェクト化しているので、 意図せずに別インスタンスから同一インスタンスを参照してしまう可能性 があります。 また、コピーも面倒です。 JavaScriptでは {...object} のシャローコピーで済むのに、 ディープコピーをするためにLodashを使う必要があります。

Slide 44

Slide 44 text

メリットだけなの？ ● どこまで処理を閉じ込めるかは議論の余地があります。 サブスクリプションを解約する際に、解約時点で利用が不可能になるか、 月末まで利用可能か、日割りが絡む中途半端な時期に解約できないか、 違約金を払えば解約できるのか…。 営業時間にサマータイムの時間は入りますか？

Slide 45

Slide 45 text

メリットだけなの？ ● 無難な処理については間違いなく含めていいです。 ただ、業務色が強い機能については、検討の余地があります。 もちろん、「期間」という一般名詞ではなく、 「立合時間」（株式が取引可能な時間）といった業務に特化した名前があ るのであれば、含めても問題ないでしょう。 🤼< 適切かどうかチームで話し合おう

Slide 46

Slide 46 text

その他の例

Slide 47

Slide 47 text

他にも ● 期間 ○ 開始日 と 終了日 ○ 開始時間 と 継続時間 ● 行列 ○ X と Y と Z ■ 加算・減算・内積・外積 等々

Slide 48

Slide 48 text

例えば ● ページング ○ 現在ページ数 と 最大ページ数 と ページサイズ ○ ソート ■ キー と 優先度 と 順番(ASC, DESC) と Nullableの扱い ● LIMIT, OFFSETをまとめたRowBounds

Slide 49

Slide 49 text

まとめ

Slide 50

Slide 50 text

まとめ 従えば必ず有力になる強力なルールではありません。 導入せずとも、特に困ることは無いでしょう。 ただ、データをまとめていくことで、 より洗礼されたモデルになる可能性があります。 期間という概念はどのシステムでも実装する概念だと思いますので、 まずは期間からまとめてみてはいかがでしょうか。

Slide 51

Slide 51 text

Appendix

Slide 52

Slide 52 text

例えば、期間（日付） 個人的には、日付の比較が非常に苦手なので、閉じ込めてしまいたいです。 これが嫌い。 AがBより古い（同値含まず）：　A.isBefore(B) AがBより古い（同値含む）　：！A.isAfter(B)

Slide 53

Slide 53 text

話すこと / 話さないこと ● Code Smells ● Primitive Obsession ● Java ● Primitive Obsession が有効ではない個所 (私もわからない) 詰めなおしは推奨されないので、 べき論が分からない 話すこと 話さないこと

Slide 54

Slide 54 text

対象者 / 非対象者 ● リファクタリングをしたいけど、 ヒントが分からない人 ● リファクタリングに興味が無い人 ● 動的型付言語 対象者 非対象者

Slide 55

Slide 55 text

登壇を見た人への期待するアクション ● Code Smellsに興味を持つ ● 型を作ることをやってみる アクション