責務と層の分離
設計の話
設計の話です。
責務
責務、誰がその仕事を行うかということを考えましょうというのはまぁさんざん言われていることだけど実際大事だと思う。
テクニックとしては委譲だのなんだのとあるけど、結局は「その仕事はその人に任せて本当にいいの？」にYesと答えられる場合にのみその作業をそのモジュールなり関数なりクラスなりに任せましょうという話ですね。
層の分離
プログラムが行う仕事は通常いくつかのオペレーションを組み合わせて実現されるわけだけど、それらの重要度というのは普通は一様ではない。
仕事によってはドメインレベルにしっかり固定されそれ以外のオペレーションがあり得ないものもあるし、今は一旦こうして実装しておくがあとで高確率で置き換える必要があるとかそういうやつ。
例えば今はハードコードしているが設定ファイルから読み込んだ値にしたい、DBを切り替えたい、データの中身が変更したいとかそういう感じのやつ。
そういうときに、それが所属する層を分離するという手法がたまに取られる。 DIが必要になる設計手法とかだとおなじみだけど、後から値を切り替えたいものはより外側の"層"にそれを押し出し、逆に変更が発生しないところに関してはより内側の層にそれを閉じ込めるというやつ。
責務と層の分離
なんでわざわざこういうタイトルをつけたかと言うとこの2つの意識が一番大事かなと最近思うようになったから
責務をはっきりさせることと層を分離するってことをひたすら繰り返すだけで大抵の設計手法はやっていけるような気がするなぁと思ったりした
GoFのデザインパターンをチラ見して
本は読んでないのだけど、最近GoFのデザインパターンについてどういうものかを調べたりしていた。
一応目的としてはデザインパターンが解決しようとしている問題を明らかにしてモダンな解決策を探りたいというのが動機としてあった。
感想を正直に書くとまぁ基本的には内容が古い上にまとまってないしこれは名前つけるようなものじゃないだろというのが多い感じで2018年にわざわざ勉強する必要があるようなものではないなと思ったりしたという感じにはなるが、それはおいておいて デザパタのあれこれを調べていくうちに、上のような2つの点の大切さを認識したりした。
デザパタの多くは現代的な言語なら責務と層の分離がちゃんとできてたらほぼ問題にはならない気もする(こういう話も具体的な言語を固定して考えたりしてみる記事を書いてみるべきかもしれない)。
オブジェクト指向/DDDとか
「オブジェクト指向は設計ではない」と繰り返して言っていたら何かの折にDDDに触れる機会があり、「これは良いものだ」と思ったりしたことがあった。
[追記]DDDのlayerに関して適当言ってたので消しました。[/追記]
実際にDDDはドメイン駆動〜みたいなことを言っているが自分はそこで初めて層の分離の概念を得た。
DDDではドメイン層と〜 DDDのことはよく知らないんだけど例えばClean ArchitectureではEntity層, UseCase層, Adapter層, Driver層のように中にあるべきものと外に置くべきものをはっきり区別していたのが、オブジェクト指向でスパゲッティ設計を生み出し続けていた自分にはとても素晴らしいものに見えたというのがあった。
オブジェクト指向がなぜ設計ではないかということは、今にして思えばオブジェクト指向は責務については問題にするものの(あるメソッドをどのクラスに入れるべきかという話はよく問題に上がるが)層の概念がないので縦方向への広がりがないというのが大きな問題としてあったのだろうということが分かったりした。
終わりに
内容がない