私は 2 冊の HEAD ファースト ブック、OOAD と Design Patterns を手に取りました。デザインパターンを読み始めたとき、私はとても混乱しました。ここに私の基本的な疑問があります：
設計パターンはオブジェクト指向設計にのみ適用できますか? 私には、DPはOOADでのみ適用できるようです
設計パターンはオブジェクト指向設計 (で使用する一連のツール) の一部ですか? 具体的に私が尋ねようとしているのは、OOAD がより大きな目的であり、設計パターンが目的の達成に役立つかどうかです。
最初の 4 つまたは 5 つのパターンを読んだ後、誰かが優れた OO デザイナーであれば、これらのパターンを使用して自動的にデザインしたように見えます。
私は本当にとても混乱しています
問題の再利用可能なソリューションとしてのパターンは、多くの分野で見られます。これらのソリューションを伝達するためにパターン言語を使用するというアイデアは、アーキテクチャの分野に由来しますが ( A Pattern Languageを参照)、後にソフトウェア エンジニアリングにうまく適用されています。ソフトウェア エンジニアリングの分野でも、エンタープライズ アプリケーションの実装パターンやアーキテクチャ パターンなど、さまざまなレベルでパターンが存在します。
ソフトウェア設計パターンの概念を広めた重要な本のタイトルであるDesign Patterns - Elements of Reusable Object-Oriented Softwareは、記述されているパターンがオブジェクト指向設計にのみ適用されることを示唆しています (これは著者の意図ではなかったと思います) 。 . いくつかの作成パターンは特にオブジェクトを扱いますが、他のほとんどすべてのパターンは、オブジェクト指向でない言語で実装できます。C の例については、状態パターン、戦略パターン、オブザーバー パターンを参照してください。
デザイン パターンは、問題に対する再利用可能なソリューションです。元のデザイン パターンの本自体は、特定の言語やパラダイムに固有のものではないと非常に明確に述べています。
たとえば、OOP の外部にある宣言型言語である SQL のデザイン パターン ブックさえあります。
設計パターンは、1 つのクラスよりも高いレベルの設計になる傾向があります。それらは、特定の設計目標を一緒に達成する関連する多数のクラスになる傾向があります。そのため (および再利用可能なソリューションとして)、それらは間違いなく優れたツールです。それらから得られる価値は、それらを念頭に置いて設計を作成することでは少なくなります (パターンはコード化されたものではなく、コードから出現する必要があります)。コミュニケーションを容易にします。シングルトンやファサードについて誰かと話している場合、その人がデザインパターンに精通していれば、あなたが話していること、デザインとその目標についてよく理解してくれるでしょう。