[解決済み] 避けるべきデザインパターン【終了

質問

多くの人が、Singletonパターンには多くの欠点があることに同意しているようで、このパターンを完全に避けることを提案する人さえいます。ある 優れた議論があります。 . Singletonパターンに関するコメントは、その質問に直接お願いします。

私の質問 : 他のデザインパターンで、避けるべきもの、あるいは細心の注意を払って使用すべきものはありますか？

どのように解決するのですか？

パターンが複雑

すべてのデザインパターンは、注意して使用する必要があります。私の意見では パターンに向かってリファクタリングすべきです。 というのは、パターンをすぐに実装するのではなく、そうする正当な理由があるときです。パターンを使うことの一般的な問題は、パターンが複雑さを増してしまうことです。パターンを使いすぎると、与えられたアプリケーションやシステムをさらに開発し維持するのが面倒になります。

ほとんどの場合、簡単な解決策があり、特定のパターンを適用する必要はありません。経験則としては、コードの断片が頻繁に置き換えられる傾向があるか、または変更する必要があるときはいつでもパターンを使用し、パターンを使用するときは複雑なコードという注意点を引き受ける覚悟をすることです。

次のことを忘れないでください。 の目標はシンプルであるべきだということです。 を念頭に置き、コードの変更をサポートする実用的な必要性がある場合は、パターンを採用します。

パターンよりも原則

パターンが明らかに過剰設計で複雑なソリューションにつながるのであれば、パターンを使用するのは無意味に思えるかもしれません。しかし、プログラマにとって、このようなパターンよりも 設計技法と原則 について読み解くことは、プログラマーにとってはるかに興味深いことです。実際、私の デザインパターン」についての私のお気に入りの本の1冊は、このことを強調しています。 は、問題のパターンにどのような原則が適用されるかを繰り返し説明することによって、これを強調しています。これらの原則は、関連性という点ではパターンよりも有用であるほど単純です。原則の中には、オブジェクト指向プログラミング (OOP) 以外を包含するほど一般的なものもあります。 リスコフ代入原理 のように、コードのモジュールを構築することができる限り、オブジェクト指向プログラミング（OOP）以外も包含します。

設計の原則は数多くありますが、その中で説明されているのは GoFの本の最初の章 で説明されているものは、手始めとして非常に有用です。

• 実装」ではなく「インターフェース」へのプログラム。 (ギャング・オブ・フォー 1995:18)
• クラス継承」よりも「オブジェクトの構成」を支持します。 (四人組 1995:20)

しばらくは、これらを身にしみて感じてください。なお、GoFが書かれた当時は インターフェース は抽象化されたもの（スーパークラスも含む）を意味し、Java や C# の型としてのインターフェースと混同されないようにするためです。2つ目の原則は継承の多用から来るもので、それは 悲しいことに、今日でも一般的な .

そこから、あなたは SOLIDの原則 は、ロバート・セシル・マーティンによって知られるようになりました。 (別名：アンクル・ボブ） . スコット・ハンセルマンがアンクル・ボブにインタビューしたのは ポッドキャストで、これらの原則について :

• S 単一責任原則
• O ペンクローズド原理
• L イスコフ代用原理
• I インターフェイス分離の原則
• D エペンデンシー逆転原理

これらの原則は、読み物として読んだり、仲間と話し合ったりするのに良いスタート地点です。これらの原則は、互いに、また次のような他のプロセスと絡み合っていることがわかるかもしれません。 懸念の分離 と 依存性注入 . を行った後 TDD をしばらくやっていると、これらの原則が実践の中で自然に身につくことがわかるかもしれません。 孤立した と 反復可能 ユニットテストがあります。