釣りキチプログラマー翔平の備忘録 
はじめに
良いコード/悪いコードで学ぶ設計入門第３章 クラス設計ーすべてにつながる設計の基盤ーを読んで、
８年間現場で設計をしたり、設計に関する勉強会への参加や技術書を読んできた自分の観点で、
特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。
良いコード/悪いコードで学ぶ設計入門を読んでのまとめ記事も作ってみたので
こちらも是非みてください！！
良いコード/悪いコードで学ぶ設計入門を読んでみて(まとめ記事)｜気付きと現場で取り入れたいことについて
良いコード/悪いコードで学ぶ設計入門第３章を読んでの気付きなど
３章ではオブジェクト指向で設計する際の基本的な考え方を、
データクラス(getterとsetterメソッドのみのクラス)と比較して解説されていました。
なぜJavaでオブジェクト指向でプログラムを書いているのか？？
オブジェクト指向で設計する目的は？？
というところから理解できるような章かなと思います。
インスタンス変数を不正な状態に陥らせないための仕組みづくりがクラス設計
良いコード/悪いコードで学ぶ設計入門第３章にはこのようなことが書かれていました。
「クラス設計とはインスタンス変数を不正状態に陥らせないためのしくみ作り」
自分はドメイン駆動設計の勉強をしていく中で学びましたが、
この意識は大事にしています。
データクラスなどは、
とりあえずnewでインスタンス変数を全てnullでインスタンス化して
その後クラスを使う側が値をsetterでセットしたり、
共通チェッククラスなどをかましてチェックして・・・
などなどやっているのを現場でよく見かけます。
データクラスはgetterとsetterしか持たないのでそうなるでしょうが、、
こうしてしまうと・・・・
そもそもクラスを使う側が複雑になるのと、
至る所にあるこのデータクラスを使う側が同じように複雑になり、
複雑な判断、加工などのビジネスロジックが至る所に散らばります。
これが悪いコードの設計とそのせいで起きる悪いことだと僕は考えています。
逆に良いコードの設計の場合、
データとそれと強く関係する判断、加工ロジックを１つのクラスにする。
これは２章であった話(ここでは触れない)
良いコード/悪いコードで学ぶ設計入門第２章を読んで｜気付きや今後参考にしたいことなどをまとめてみました
不正な状態でインスタンス化ができないようにチェックする。(完全コンストラクタ)
本で述べられているのはここ
インスタンス後にインスタンス化変数を外から書き換えられなくする。
次章で詳しく解説されてる(ここでは触れない)
だと僕は考えて設計しています。
不正な状態でインスタンス化できないので、
インスタンスを使う側は正しく初期化されたものしか扱うことがなくなり、
使う側がシンプルになります。
また、これは本でも触れられていましたが、
インスタンス化の際の制約や意図をコードで表現することになるので、
(サンプルコードで言うコンストラクタの部分)
コードが仕様を語るようになります。って表現してる方がいました・・・
また、これは自分の考え方ですが、
値オブジェクトを作るかどうかの基準はここにしています。
制約や意図がある概念であればわざわざ値オブジェクトにする価値があると考え、
逆にとにかく〇〇IDだからという理由だけでは値オブジェクトを作る価値はないと考えています。
(ドメイン駆動設計でとにかく値オブジェクトだ！！ってやる人もいますが、、、)
自分の身はクラス自身で守る(自己防衛責務)｜クラスを使う側がシンプルになるように
良いコード/悪いコードで学ぶ設計入門第３章にはこのようなことが書かれていました。
「他のクラスで初期化してもらったりバリデーションチェックしてもらったりしている未熟なクラスは使う側が複雑になる。」
「構成部品であるクラス１つ１つが品質的に完結していることがソフトウェアの品質を向上させる。」
「クラス単体で正常に動作するように」
先ほども少し触れましたが、
クラスは使う側がシンプルに使えるように設計する必要があります。
(でないと至る所にある使う側が全部複雑になる)
そのためには、本で述べられているような考え方が重要だと思います。
近い考え方は僕も以前から持っていましたが、
改めて文字にしたものを読むと確かにそうだよなと改めて気付かされました・・・
クラスを使う側がシンプルな状態とは、
使う側がごちゃごちゃした初期化をしたり、
正しい値で今初期化できているのかをチェックしたり、
いろんなフラグを引数に渡したり(使う側が使うためのいろんな知識を持つ状態)・・・・
をしないことです。これが悪いコードの設計かなと僕は考えています。
逆に、良いコードの設計では
本ではドライヤーを例に説明されていましたが、
コンセントを差してボタンを押すだけで使える。
(使う人間ドライヤーを使うまでに複雑なことをしない。)
そういうクラス設計をし、
それぞれのクラスで動作が完結し、
それぞれのクラスで動作を保証できた
これらを組み合わせて１つのシステムになっている状態だというのが、
この章を読んでの僕の解釈です。
そういう良いコードの設計できれば、
インスタンス化の時にかけたい複雑なチェック系のビジネスロジックが１箇所にまとまり、
使う側は正しい状態で初期化されたインスタンス化されたモノを使うだけで済むのでシンプルになり、
テストもクラス単位に行いやすくなり(動作保証もクラス単位にしやすい)、
バグの切り分けもしやすくなり・・・・
などなどのメリットを今までの設計や実装の経験から感じています。
これはおまけですが、
現場で役立つ設計原則という本でもクラスを使う側が複雑になってきたら、
そのクラスを見直すべきタイミングであり、
クラスを使う側はシンプルであり続けられるようにすべき。
と言うようなことが書かれていました。
現場で役立つシステム設計の原則第４章を読んで｜気付きや今後参考にしたいことなどをまとめてみました
まとめ
良いコード/悪いコードで学ぶ設計入門第３章 クラス設計ーすべてにつながる設計の基盤ーでは、
なぜJavaでオブジェクト指向でプログラムを書いているのか？？
オブジェクト指向で設計する目的は？？
という基本的なところから理解できるので、
Javaなどのプログラミング言語を習得した直後に読んでもかなり勉強になると思いました。
以前、良いコード/悪いコードで学ぶ設計入門の著者のトークでもありましたが、
ビジネスのスピードが速い現代では、
ビジネスの要求を分析して保守しやすく成長し続けるコードに落とし込めるスキルは
githubを使えたりAWSを使えるのと同じくらい必須のスキルだという話がありました。
設計のスキルはそれほど重要だと僕も考えています。
こういった本を通じてプログラマーやエンジニアの設計スキルが上がり、
現場で変更が危険なシステムと出会す機会が減り、
設計についていろいろ語り合えるプログラマーやエンジニアが増え、
そういう方と一緒に仕事ができることを期待しています！！！
