こちらの記事の続きです。
https://qiita.com/yuma_akita/items/fbe1aca566d7da335905

4章不変の活用

この章では不変の有用さ、可変にしたときの悪影響が紹介されていました。

可変の悪影響

同じ変数を参照していたとき、変数に代入されると両方ともに影響が出てしまう
予期していなかった動作になってしまう

→ 不変はこれらの悪影響がない

不変の有用性

不変にすると可変のときと比べて考慮すべきことが減るため、変数名を固定できる。

どんなときに可変にするべきか

スコープ内で代入されることが決まっている時
スコープが収束可能な時
ループ文のカウント
リソース制約の厳しい組み込みソフトウェア
パフォーマンス要件が満たせない時

感想

私はプログラミングを始めた頃、「不変ってなんで存在するんやろ？? 柔軟性のある可変のほうがええやん」と思っていましたが、あの頃は型もしかり、縛るということの大切さをしらなかったんですよね、、。

5章低凝縮

低凝縮・・・クラス内におけるデータとロジックの関係性が弱い状態
この章では低凝縮になりやすいパターンとその修正方法が紹介されていた。

この章に関しては、読んでいるときにわからなかったこと、理解したこともまとめていこうと思います。

低凝縮になりやすいパターンと解消法

Commom,Utilなどの共通処理クラス
→ object指向の基本に立ち返える。
引き数が多すぎるパターン
→ データをインスタンス変数として持つ１つのクラスとして切り出してみる。

わからなかったこと①

object指向の基本に立ち返るとなぜ共通化の「雑多にロジックがある状態」が解消されるのか?

答え
データとロジックをひとまとめにしてクラスを作るという考え方がobject指向の基本としてあるから。

詳細
ここでいう共通化で雑多にロジックがある状態とは、関連のないデータと処理をUtilやCommonといった共通ファイルにまとめること。

これらはデータとロジックがひとまとめになっていない状態なので、object指向の基本としては元のデータがあるファイルにロジックを戻してあげる必要がある。

なのでobject指向の基本に立ち返ると「雑多にロジックがある状態」が解消される。

わからなかったこと②

尋ねるな、命じろ？ってそもそもどういう意味？

答え
メソッドを繋げて「状況を尋ねる」ことではなく、「メソッドにやらせる」こと。

詳細
ここを理解するのには様々なブログ記事を参考にさせて頂きました。[1,2,3]
ちなみに完全に理解はできていませんが理解できたところまで。。。

ここでいう尋ねるというのは以下のような状況。

user.info.service.active?
→ ture

このような状況だと、例えばServiceクラスの修正があったとしたら、Userクラスの内容まで確認しながら修正する必要がある。他のクラスのことも考えながらとなると、改修範囲の見積もりに時間が取られたり、見落としが合った際にデグレが起こったりと様々な悪影響があるのでNG。

逆に、ここでいう「命じる」メソッドチェーンを続けるというのは避け、それぞれのクラスが持つべき情報だけを持たせたメソッドにすると、改修範囲はそのクラスだけとなり余計なコストが掛からずに済む。
(「命じる」の例については参考にしたブログ記事の出来が良すぎるためここでは割愛します。）

感想

尋ねるな命じろの章を読む際、まずSOLID原則から理解するところから始めたのでかなり理解に時間を要しました。あまり意識はできていませんでしたが、私もRubyというオブジェクト指向の言語で開発しているのでこのような原理原則やベストプラクティスを使いこなして、可読性、保守性の高いコードが書けるようになりてぇなぁ。。。。と日々思う次第です。

参考

[1]お前のデメテルの法則は間違っている～getter/setterの必要性～

[2]コードを複雑化させないために意識したいパターン集

[3]デメテルの法則を厳密に守るにはどうすればいいの？