『良いコード/悪いコードで学ぶ設計入門』を読んだので良い設計への意識を高める

書店でもピックアップされ、Twitterでもかなり話題になっていた『良いコード/悪いコードで学ぶ設計入門』を読みました。

最近仕事で、設計についてコメントをもらうことが多くあり、動くコードから一歩進んで、良い設計のコードを書きたいなーと思ったためです。

本書はサンプルコードを使いながら解説がされていますが、サンプルコードの言語はJavaです。

私はJavaをやったことがなく、理解できるか不安でしたが、文章中にコードの意味を説明してくれているのと、簡単なサンプルコードなので問題なく読み進められました。

以下、本書を読んで気をつけなきゃなーと思った点を今後の自分のチェックリストを兼ねて記載していきます。

連続する処理をいくつか書いていくと、途中結果を同じ変数を変化させながら使ってしまっていたことがありました。

ただ、途中経過で変数の意味が変わってきたら、その都度別の変数に代入してあげないと後から読みづらくなるので目的ごとに変数を用意することに気を付ける必要があります。

例えばMoneyクラスのaddメソッドで、Moneyクラスの別のインスタンスのcurrencyを足し算をしたいとなった場合、引数を単に数値にすると、想定外の数値をミスでいれてしまうかもしれません。

しかし、Moneyクラスのインスタンス（moneyとします）を受け取るようにし、メソッドの中でmoney.currencyを足すようにすれば、想定外の引数が渡されることを防ぐことができます。

私が機能追加をする場合、ついつい使えそうなクラスにメソッドを追加するなどしてしまうのですが、この章を読んで考えを改めようと思いました。

本書内では価格の例を用いて、割引でも１つのクラスにまとめず、割引の種類によってクラスを分けるべきという話が例として出されています。

「クラスが担う責任は１つだけ」になっているかをチェックしながら実装していく必要があります。

継承をするとスーパークラスが共有ロジックの置き場となっていき、結果単一責任が守られず、密結合になっていくリスクがあるという内容が書かれていました。

実装時点では継承で追加コードを省略して書けそうでも、一度止まって考えることが大切になりそうです。

可能な限り具体的で、意味範囲が狭い、目的に特化した名前を選ぶ

『良いコード/悪いコードで学ぶ設計入門』p.211 より

具体的にするというのは意識しなきゃと思っていましたが、目的に特化というのはあまり意識できていなかったです。

本書では単に「商品」といった存在ベースでの命名ではなく、「予約品」「注文品」etcといった目的ベースで命名をすると曖昧にならず混乱を避けられると紹介されています。

実務経験1年がたって、動くコードだけではなくきちんと設計されたコードを書きたいと思ったので手に取ってみたのですが、とても勉強になりました。