彼の投稿SOLID: the next step is Functionalで、Mark Seemann は次のように述べています。
ますます小さなインターフェイスに向かって設計を進めていくと、最終的には究極の役割インターフェイスに到達します。つまり、単一のメソッドを持つインターフェイスです [...] そのように SRP と ISP を適用すると、進化する可能性が高くなります。それぞれが単一のメソッドを持つ多くのきめ細かいクラスを持つコード ベース。それは私に何度も起こりました。
私の懸念は、そのようなクラスの結束についてです。このアプローチは機能的結束を促進しますか? それらのクラスはまとまりがありませんか？コードの一貫性に悪影響はありますか?
テストに導かれたオブジェクト指向ソフトウェアの成長という本に示されている結束の優れた定義があり、次のように述べています。
要素の凝集度は、その責任が意味のある単位を形成しているかどうかの尺度です。たとえば、日付と URL の両方を解析するクラスは、それらが無関係な概念であるため、一貫性がありません。衣服と皿の両方を洗う機械を考えてみてください。両方をうまく行うことはまずありません。反対に、URL の句読点のみを解析するクラスは、概念全体を表していないため、一貫性がありません。何かを成し遂げるには、プログラマーはプロトコル、ホスト、リソースなどの他のパーサーを見つける必要があります。「高い」コヒーレンスを持つ機能は、保守が容易です。
これはおそらくすぐに主観的な領域に入りますが、SRP と結束力は直接関連する概念であり、時には直交する概念でもあると私は主張します。メソッドが 1 つしかないクラスがある場合は、確かに、1 つのことだけを行うという意味でまとまりがあります。しかしまた、あなたは何かを失います。このクラスは、粒度が細かすぎて、それ自体では役に立ちません。
機能的なスタイルでは、そのようなクラスを持つことは非常に理にかなっています。結果を達成するために関数を構成することがすべてです。C# はこのスタイルを可能にしますが、かなり冗長でもあります。そのため、とにかくそのような方法でコードベースを設計している場合に F# を主張する Seemann に完全に同意します。
このデザインの良し悪しは主観的なものですが、客観的に言えることはいくつかあると思います。1 つのメソッド クラスは、その性質上、SRP を尊重することがほぼ保証されています (もちろん、要点を見逃して、すべてが強力なメソッドで神のクラスを作成することもできます)。したがって、そのような方法で書かれたコードには、私たちが期待するすべての利点があります。疎結合、構成可能、保守可能であること。しかし、そのようなコードの全体像を失うことについても言いたいことがあります。
ほとんどの場合、2 つの組み合わせが必要であり、ほとんどのコードベースで単一のメソッドを持つクラスに傾いていると私は主張します。たとえば、そのようなクラスを持つ再利用可能なライブラリのコレクションのような低レベル コードのほとんどを記述することができます。API レベルに近づくと、そのようなクラスを構成して必要なロジックを取得し、そのようなロジックをよりまとまりのある機能のチャンクとしてクライアントに公開します。クライアントは、従うべきよりまとまりのある高レベル コード パスを持つことの利点を得ることができ、ライブラリがサポートする機能のより便利な使用と発見可能性の向上につながります。保守可能で柔軟に変更できます。