はじめに
GWに「良いコード/悪いコードで学ぶ設計入門」という本を読んでみて、非常に勉強になったので、
備忘録も兼ねて感想を残していきたいと思います。
この本を知ったきっかけ
自身のTwitterのタイムラインに著者であるミノ駆動(@MinoDriven)さんが本書を紹介しているツイートが流れてきたのがきっかけでした。
ミノ駆動さんは以前からクソコードの動画をツイートされており、個人的に面白く視聴しつつ、クラス設計の重要性についてとても勉強になっていました。
クソコード動画「共通化の罠」 pic.twitter.com/MM750CNXc2
— ミノ駆動 (@MinoDriven) May 12, 2019
（ざっくりした）全体の感想
私はこれまで技術力をつけるために、
Javaの資格を取得する、現場で利用しているFWの学習をする、読みやすいコードを書けるようになるために書籍（リーダブルコードなど）やQiitaなど技術投稿サイトを見る、現場のソースコードを読み込む・・・
などで少しずつ技術力をつけていきました。
その一方で、現場での開発は、既存のソースコードをベースに改修を進めていくことが多く、
経験を積んでいく中で、一から設計してシステムを作り上げていくためのスキルを身につけていきたいという気持ちが強くなっていきました。
そんな中この本を読むことで 「変更容易性」 というキーワードを軸として設計する視点およびスキルを得ることができたのではないかと思います。
本書では、自分がこれまで経験した現場では見たことない実装が多く登場しており、
現場で出てきたソースと比較することで オブジェクト指向を意識した設計／コーディングの引き出しが増えた と感じています。
サンプルコードも豊富で、具体的な実装をイメージすることができたので、非常に読みやすかったです。
また、リーダブルコードのような、可読性の高いソースコードを書くためのテクニックも紹介されているので、何かしらのプログラミング言語の文法を一通り理解した後にこの本を読むととても勉強になるのではないかと思います。
特に気になった章の感想
個人的に勉強になる箇所は数多くあったのですが、その中でも特に勉強になった章を抜粋して感想を書こうかと思います。
内容に関しては詳細に触れない（つもり）ので、気になった方は本書を購入いただければと思います。
第３章 クラス設計
「第4章 不変の活用」や「第5章 低凝集」にも若干関連するところもありますが、
「完全コンストラクタ ＋ 値オブジェクト」 がこの章のキーワードであり、 「変更容易性」 を実現するための重要な考え方の一つだと理解しています。
完全コンストラクタ
本書における完全コンストラクタの定義を引用すると以下となります。
完全コンストラクタとは、不正状態から防護するための設計パターンです。1
完全コンストラクタの要点をまとめると以下となりますが、
- インスタンス変数をコンストラクタで全て初期化する
- コンストラクタ内で入力値チェックする
- インスタンス変数にfinal修飾子で不変とする
個人的には インスタンス変数にfinal修飾子で不変とする という点が勉強になりました。
確かに変数の値が処理の途中で変化するソースは処理を追うのが難しいな・・と思うことが多々あるので、不変であれば解析の負担はかなり楽になりそうです。
その反面、値を変更したい時はどうすれば良いのか？という疑問が湧きましたが、後述する値オブジェクトという考え方と変更する場合は新しくインスタンスを生成するというテクニックを使うことで値の変更を実現しています。
値オブジェクト
本書における値オブジェクトの定義を引用すると以下となります。
値オブジェクト（Value Object）とは、値をクラス（型）として表現する設計パターンです。2
データの格納のみのクラスが存在して、値の編集はUtilityクラスで行うソースは度々見たことがありますが、
それらはオブジェクト指向プログラミングの考え方を生かせておらず、
本書で取り上げられている「完全コンストラクタ ＋ 値オブジェクト」をセットで実装することで高凝集な構造になり、「変更容易性」が実現できると理解しました。
高凝集というキーワードは本書で頻繁に登場しており、非常に重要な考え方なのが伺えます。
第８章 密結合
自分が現場経験が浅かった頃、重複した処理をスーパークラスに集約することで、サブクラスの実装を完結にしている現場のソースを見て、継承の使い方について非常に勉強になりました。
その一方でスーパークラスを改修することによる影響が大きすぎて改修のハードルが上がるという経験をしたことがあるのですが、まさにこれが、本書で取り上げている密結合だったと思います。
本書ではそのような密結合クラスの対処法として以下のキーワードが挙げられています。
- 単一責任の原則
- DRYの原則
- 継承より委譲(コンポジション構造)
上記の中でも単一責任の原則の考え方に関しては本書で繰り返し登場しており、
次に紹介するクラスやメソッドの適切な命名、適切なモデリングにも関わってくる内容でした。
また、これまで、同じようなロジックは共通化するべきという考え方を持っていたのですが、本書で取り上げられているDRYの原則においては、
同じようなロジック、似ているロジックであっても、概念が違えばDRYにすべきではないのです。3
と記載があるように、同じような処理 = 共通化の対象ではなく、ビジネス概念が同じかどうかを見極めてから共通化を行うという点は非常に勉強になりました。
第１０章 名前設計 ／ 第１３章 モデリング
第8章で取り上げた、密結合を回避するためには各クラス、メソッドごとに適切に単一責任の原則を適用して、多くの責務を背負わないようにする必要がありますが、それらを実現するための手がかりとなる章だと思いました。
これらの章はまさに設計するといった章であり、個人的には難しかったですが、存在ベースではなく、目的ベースで考えることが適切な名前設計、モデリングにつながると理解しました。
実際に設計する機会があればこの章は何回も読み返したいところです。
おわりに
簡潔でしたが本書の感想は以上となります。
まだまだ私の技術力は未熟ですし、一回読んだだけで全てを理解できているわけではないので、
何回も繰り返し読んで自分のものにしていきたいと思います。
また、ここで出てきた設計のスキルは実際に手を動かしてこそ得られるものだと考えているので、
今回学んだ知識をベースに実際にコードを書くなどアウトプットしていきたいなと思います。