こちらの記事の続きです。
8章 密結合
この章では密結合になるとどのような問題があるか、どのようにして密結合を解消するかが記述されていました。
結合度・・・クラス間の依存を表す指標
密結合の問題点
- 処理の一部を変更した時に密結合しているクラスの挙動に影響を与える可能性がある。
- 単一責任の原則を外れてしまう。
どのようにして密結合を解消するか
- 責務が単一になるようにクラスを設計する
「クラスが担う責任はたった一つに限定すべき」という設計原則に基づきクラスを設計することで密結合を解消する手法が記載されていました。
感想
結構このあたりからボリュームが増えてきて紹介しきれなかったのですが、DRYにしすぎて異なった概念の処理を共通処理で書いたりすると、密結合に陥りやすいという内容の記述があり結構目からウロコでした。
9章 設計の健全性をそこなうさまざまな悪魔たち
この章ではよくある悪い設計を紹介していました。
-
デッドコード
どんな条件でも決して実行されることがないコード -
YAGNI原則
You aren't going to need it
明確に言語化されていない仕様を先回りして実装すること -
マジックナンバー
コード内に出てくる30や66などの特定の数字。実装者以外がなぜその数字になっているか分からず可読性低下を招く危険性がある。(時間が立つと実装者ですらなぜその数字にしたかわからなくなる事が多い） -
文字列型執着
異なる種類のデータを1つの文字列として保持すること。 -
グローバル変数
どこからでも参照可能な変数。 -
null問題
返り値がnullであることを想定できていなかったときに、エラーが発生する問題。 -
例外の握り潰し
例外がthrowされたときに、その例外をcatchしたにもかかわらず何もしないこと。 -
設計秩序を破壊するメタプログラミング
プログラミングの構造自体をプログラミングすること。黒魔術と呼ばれることもあり、使い方を誤ると非常に危険。 -
技術駆動パッケージング
model, view, controllerなど記述単位でフォルダを分類すること。理想は関心事ごとにフォルダ分けすること。 -
サンプルコードのコピペ
タイトルの通り。 -
銀の弾丸
難しい問題が特定の新しい技術１つですべて解決する、とういうことは無いということ。
感想
知っているものも多くありましたが、技術駆動パッケージングがあまり良くない構造で紹介されていたのは結構驚きでした。