$30 off During Our Annual Pro Sale. View Details »

一緒に使うことが多い値は別クラスにしよう(Data Clumps)/data_clumps_is_useful

kirimaru
August 24, 2022

一緒に使うことが多い値は別クラスにしよう(Data Clumps)/data_clumps_is_useful

【LT登壇7名決定!】リーダブルコード LT会 - vol.4 #readablelt
https://rakus.connpass.com/event/253650/

kirimaru

August 24, 2022
Tweet

More Decks by kirimaru

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  4. 良いコードとは?

    View Slide

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

    View Slide

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

    View Slide

  7. 今日のキーワード
    Data Clumps
    (データの塊)

    View Slide

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

    View Slide

  9. 期間(日付)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. 例えば、期間(日付)
    期間と期間の比較は初見は面倒。

    View Slide

  15. 期間(時刻)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  22. DBの複合キー

    View Slide

  23. View Slide

  24. 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;
    }
    適切な例が思い浮かばず…

    View Slide

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

    View Slide

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

    View Slide

  27. 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をすべて持つ前提

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  31. 仕入
    仕入
    販売 販売

    View Slide

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

    View Slide

  33. ちょっと脱線

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  37. 例えば、
    期間(日付)
    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,
    )
    わざわざ
    ここまでする必要はない。

    View Slide

  38. 例えば、
    期間(時刻)
    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の構造を変えること自体は
    良いこと

    View Slide

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

    View Slide

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

    View Slide

  41. 例えば、
    期間(日付)
    public class サブスクリプション {
    期間 contractTerm;
    LocalDate cancelDate;
    }

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

    View Slide

  42. ちょっと待って
    メリットだけなの?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  46. その他の例

    View Slide

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

    View Slide

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

    View Slide

  49. まとめ

    View Slide

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

    View Slide

  51. Appendix

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide