【C#】どれくらいの規模からデザインパターンを適用するか

Question

以下の記事を読み、判断に迷ったので質問させてください。

参照記事
なんちゃってデザインパターンで条件分岐をなくす
https://blog.jnito.com/entry/20100717/1279321664

私はC#でプログラミングをしておりますが、対象の規模が小さい時にデザインパターンを適用するか迷うことがあります。

上記の記事で、

「条件分岐はなくなったけどめちゃくちゃコード長くなってるじゃん！」とか「元の方がはるかにわかりやすい！」と思われるかもしれません。
簡単なプログラムであれば従来の構造化プログラミングで十分です

と触れられている部分になります。

例えば、5つ程度の機能を追加実装する必要があった時、
上記の記事のようにデザインパターンなどを適用すると、オブジェクト指向らしいコードができあがります。

ただし、テストの負担は構造化プログラミングよりも少し増えると思われます(自動UTの追加など)。

今後この機能が拡充される見込みが少なければ、構造化プログラミングをするべきなのでしょうか？

個人的に、あまりオブジェクト指向らしくないプログラミングに抵抗があり、いつも迷ってしまいます。

しかし、これで時間がかかっていたらコスパもよくありませんし、手段と目的がひっくり返ってしまっているようです。

みなさんは、規模によってオブジェクト指向らしくない設計を選択することはありますか？
また、その場合の判断基準はどのようなものでしょうか？

ご意見伺えますようお願いします。

Answer 1

こんにちは。

規模によってオブジェクト指向らしくない設計を選択することはありますか？

オブジェクト指向らしくないコードもそれなりに使います。といいますか、「オブジェクト指向はかなり便利ですのでよく使います」という感じですね。
永続的なデータとアルゴリズムがセットになるようなものはオブジェクト指向が便利です。そして、そのようなケースは非常にたくさんあります。
しかし、（引数を受け取って副作用なしに結果を出力する）関数もよく使います。こちらはオブジェクト指向とは無関係です。

また、その場合の判断基準はどのようなものでしょうか？

つまり、規模は無関係です。
判断基準としては関数が終了した後も保持しておきたいデータがあるかないかですね。
そのようなデータが不要なら大抵の場合、関数を使います。（C++erなのでテンプレート・メタ・プログラミングする際にクラスもよく使いますが、これはオブジェクト指向プログラミングではないです。）

構造化プログラミングは単に関数を記述する際の記述方式のひとつですので、当然ですがオブジェクト指向プログラミングする際にも使います。メンバ関数を書く時に構造化しないなんて正直ありえないですよ。

ご提示のようなswitch-caseを動的ポリモーフィズムで処理するデザインパターンはよく解説をみますよね。
私自身はswitch-caseをなくすために動的ポリモーフィズム化するということは私は皆無です。
「派生クラス is_a 基底クラス」的な関係にある時に動的ポリモーフィズムを使うことが多いです。
しかし、もちろんswitch-caseを減らすために動的ポリモーフィズムを多用するのもありと思います。メンテナンス性が良くなる使い方であれば、それは好ましい設計と思います。（逆に、ただ一箇所のswitch-caseを削減するために使うとメンテナンス性は明らかに劣化するので、将来的に拡張するのが確実というわけでないなら、それはあまり褒められない使い方のように感じます。）