デザインパターンが正しく実装されているかどうかを確認する方法

文書化されたデザインパターンを使用していなかったすべての古いアプリケーションを正常にスケーリングできます。どのようなパターンであれ、私は知りません。大部分は、単純なOOPコンセプトを使用する必要があると感じただけです。

デザインパターンの概念は複雑で理解しにくいものです。実装時に、実装が正しく、アプリケーションが実際の疎結合を持っているかどうかを判断する方法は？

答えを簡潔に保つために、コードに次の特性が表示されていれば、意図的な努力（問題ではない）を行っていない場合でも、パターンが適切に配置されていると確信できます。

望ましい特性：

1. コードベースはユニットレベルでテスト可能です
2. 変更要求を実装するときは常に、ドメイン内で相互に関連する関連クラスのみに変更を加えます。
3. あなたのコードベースはソフトウェアエントロピーを示していません。

まだコードを特定して実際のパターン名でタグ付けしたい場合は、次のアクションを実行してボールを転がすことをお勧めします。

1. コードベースをリバースエンジニアリングして、いくつかのUMLダイグラムを生成します。
2. ダイアグラムをパターン参照資料の既製の参照と視覚的に比較します。

これにより、公正なアイデアが得られます。

デザインパターンと結合の両方に言及します。これらは個別の概念なので、個別に扱います。唯一の本当のつながりは、設計パターンが疎結合を促進する傾向があるということです（それは優れた設計の主要な側面だからです）。

デザインパターン

デザインパターンの概念は実際には非常に単純です。これは、さまざまな一般的な問題に対処するためのテンプレートのセットにすぎません。人気がある主な理由は2つあります。

1. それらは「実証済み」です：それらは何度も使用されており、それぞれの利点/欠点は一般的に知られており、特に大きな問題を引き起こす可能性のある微妙な問題は知られています。
2. これらは共通の用語集を提供するため、コミュニケーションが容易になります。「クラスXがオブザーバーパターンでオブザーバーの役割を果たしている」と誰かが言った場合、そのパターンに精通している開発者は、何が起こっているかをすぐに把握できます。

正しく実装したことをどのように知っていますか？それは難しいものです。ほとんどのパターンについては簡単です-あなたはそれを盗んでいるか、そうでないかのどちらかです。一部のパターンは、他のパターンよりも明確に定義されていません-例えば、model-view-controller。そのようなパターンは、一般的なガイドラインとしてよりよく使用されます。パターンの実装方法の詳細は、パターンが存在する理由とそれが何を達成するのかを理解することほど重要ではありません。

デザインパターンは「唯一の真の方法」ではありません。多くの場合、特定の目的に合わせて調整する必要があるか、要件に合ったパターンがまったくない場合があります。適合しないデザインパターンを強制するのは悪い考えです。実際にドライバーが欲しいときに本当に良いハンマーを使うようなものです。

カップリング

これは、コンピューターサイエンスにおいて非常に重要なアイデアです。ほとんどのソフトウェアプロジェクトの要件は時間とともに（時には大幅に）変化するため、設計が変化に対応できるかどうかが重要です。カップリングは、基本的に「このコンポーネントを別のコンポーネントに交換するのがどれほど難しいか」の尺度です。「コンポーネント」には、メソッド、クラス、パッケージ、ライブラリなどがあります。

このウィキペディアの記事には、さまざまなタイプのカップリングがリストされています。

答えは、実際には最初から設計パターンを作成する目的です。なぜ柔軟性が必要なのですか？

それは変化です。要件が変更されます。コード変更に反映される要件内の何かを変更し、それを行うことがいかに簡単/難しいかを確認してください。

設計パターンの使用は予防措置です。後でアプリケーションをスケーリングするときに、設計パターンを使用して作業を容易にします。もちろん、後で作業を容易にするために、もう少し作業を行う必要があります。本当の問題は、将来どのくらいの変化を期待できるか、そしてこの変化が何であるかです。スケーラビリティと柔軟性が必要ない場合は、デザインパターンを廃止できます。

デザインパターン自体は、オブジェクト指向デザインの原則の実装です。これらの原則に従う限り、アプリケーションは柔軟でスケーラブルになります。実際に実際のデザインパターンを持っていなくても。ヨアヒム・ザウアーが上でコメントしたように、彼らは一般的な問題に対する一般的な解決策です。