単一責任の原則

■所感
前章が嘘のようにすんなり読める内容だった。Facade(※1)ってどんなデザインパターンだっけ？と一瞬迷ったが、例を読んでいたらいつの間にか思い出していた。

※1 自分が良く使うあんちょこ

例も全体的にわかりやすい。クリーンアーキテクチャといえばあの図形、というくらいに有名な絵が頭に浮かんだ。

■内容について
自分が開発を行うときは、いつも基本的にテスト駆動（TDD）になる。それは、TDDを採用しているかどうかにかかわらず、設計の時点でテストをどう行うかをベースに組み立てている。なので、単一責任に関しては、理解しやすい土壌があったと思う。アクター(※1)の異なるコードは分割するべき、その通りだと思う。呼び出し元によって変化しない普遍的な内容を返却するメソッドにするか、インターフェイスで処理そのものの実装は呼び出し元に任せるなり、継承するなりして単一性は保ちたい。
呼び出し先の内部で、アクターによって条件分岐が発生するプログラムを見ると、ぐぬぬってなる。
この辺は、やっぱり設計の問題だと思う。とりあえず動けばいいや、的な作り方になってしまったんだろう。メンテナンスが入ったときに大変な思いをするので、単一性は極力保ちたい。

※1 ユースケースの棒人間。登場人物のこと。

余談だが、最近デザインパターンの話を聞く機会が増えた。ここ数年、ほとんど耳にすることがなかったのに、なぜか急に見聞きするようになったのはなぜだろう？？クリーンアーキテクチャの本を買うくらいに、アンテナを張る方向が変わったからだろうか？.netの環境から、javaの環境に変わったことが要因になっているんだろうか？
不思議なこともあるもんだ。