インターネットでデザインパターンについて読むと、3つのカテゴリがあることに注意してください。
しかし、ソフトウェアのアーキテクチャを作成するときは、MVP、MVC、またはMVVMについて考えます。
たとえば、創造的なパターンの中でシングルトンパターンを見つけましたが、MPVでもシングルトンを使用しました。
だから私の質問は次のとおりです。設計パターンは製品のすべての構造を超えていますか?
はいの場合、シングルトンはどのように設計パターンになりますか?アプリケーションのどこでも使用できるからです。基本的に、メモリ内に一度に1つのインスタンスのみを作成するように制限されていますが、この概念はソフトウェアの設計方法を定義しませんか?
そうでない場合、MVP、MVC、MVVMはパターンの3つのカテゴリのどこにありますか?そして、ソフトウェアの設計とアーキテクチャの違いは何ですか?
詳細な説明が必要ですが、私の知る限りでは違いをスケッチしてみます。
パターンは、プログラムに見られる蒸留された共通性です。大規模で複雑な構造を解体し、単純な部品を使用して構築することができます。問題のクラスに対する一般的な解決策を提供します。
大規模で複雑なソフトウェアは、さまざまなレベルで一連の分解を経ます。大まかに言って、アーキテクチャパターンはツールです。より小さなレベルでは、設計パターンがツールであり、実装レベルでは、プログラミングパラダイムがツールです。
パターンは非常に異なるレベルで発生する可能性があります。 フラクタル を参照してください。クイックソート、マージソートはすべて、要素のグループを順番に整理するためのアルゴリズムパターンです。
最も単純なビューの場合:
Programming paradigms Specific to programming language
......................
Design patterns Solves reoccurring problems in software construction
......................
Architectural patterns Fundamental structural organization for software systems
......................
Idiomsは、低レベルの詳細を埋める、パラダイム固有および言語固有のプログラミング手法です。
設計パターンは通常、コードレベルの共通性に関連付けられています。より小さなサブシステムを改良および構築するためのさまざまなスキームを提供します。通常、プログラミング言語の影響を受けます。 言語パラダイム が原因で、一部のパターンは意味のないものになります。デザインパターンは、エンティティとそれらの関係の構造と動作の一部を具体化する中規模の戦術です。
アーキテクチャパターンは、デザインパターンよりも高いレベルで共通性と見なされます。アーキテクチャパターンは、大規模なコンポーネント、システムのグローバルプロパティおよびメカニズムに関する高レベルの戦略です。
パターンはどのように取得されますか?を通して:
上記の考えに従っている場合。シングルトンは「設計パターン」であり、MVCは関心の分離に対処する「アーキテクチャ」パターンの1つであることがわかります。
読んでみてください:
デザインパターンは、何度も証明されている方法で技術的な問題を解決するためのよく知られたパターンです。デザインパターンは、再利用可能なオブジェクト指向ソフトウェアを作成するための一般的なデザイン構造とプラクティスです。デザインパターンの例は、ファクトリパターン、シングルトン、ファサード、状態などです。デザインパターンは、アプリケーション全体の小さな問題を解決するために使用でき、アーキテクチャ全体よりも簡単に挿入、変更、追加できます。
アーキテクチャパターンは、ソフトウェアアプリケーションアーキテクチャの問題を解決するためのよく知られたパターンです。ソフトウェアアプリケーションアーキテクチャは、技術的および運用上のすべての要件を満たす構造化ソリューションを定義するプロセスです。アプリケーションのアーキテクチャは、コードの全体的な「組織」です。さまざまなアーキテクチャの例としては、MVC、MVVM、MVP、nレイヤー(つまり、UI-BLL-DAL)などがあります。通常、アーキテクチャは事前に決定する必要があり、アプリケーションの構築後に変更することは困難です。
アーキテクチャ要素は、一般にボックスとして表されるクラスまたはモジュールのコレクションに向かう傾向があります。アーキテクチャに関する図は、見下ろす最も高いレベルを表しますが、クラス図は最も原子レベルです。アーキテクチャパターンの目的は、システムの主要部分がどのように組み合わされるか、メッセージとデータがシステムをどのように流れるか、およびその他の構造的な問題を理解することです。アーキテクチャパターンはさまざまなコンポーネントタイプを利用します。各タイプは、通常、連続した小さなモジュールで構成されます。各コンポーネントは、アーキテクチャ内で責任を負います。デザインパターンは、アプリケーションの小さな粒子に対する低レベルまたはクラスレベルのデザインパターンです。
詳細: https://www.oreilly.com/ideas/contrasting-architecture-patterns-with-design-patterns
デザインパターンスコープはアーキテクチャパターンと異なり、よりローカライズされており、コードベースへの影響は小さく、コードベースの特定のセクションへの影響は次のようになります。
How to instantiate an object when we only know what type needs to be instantiated at run time (maybe a Factory Class?)
How to make an object behave differently according to its state (maybe a state machine, or a Strategy Pattern?)
アーキテクチャパターンはコードベースに大きな影響を与え、ほとんどの場合、アプリケーション全体に水平(レイヤー内のコードの構成方法)または垂直(つまり、外部レイヤーから内部レイヤーへのリクエストの処理方法)に影響を与えます。バック)。アーキテクチャパターンの例:Model-View-Controller、Model-View-ViewModel
まあ、主な部分はそれは言語の問題です。私の経験によると、ソフトウェアに関する限り、設計とアーキテクチャの境界線は広い川であり、その幅は主にマーケティングの季節に影響される水位に起因します。一般に、「設計」という用語は、エンドユーザーに認識されるソフトウェア製品の動作の強力な側面で使用されますが、「アーキテクチャ」はソフトウェアの技術的構造を表します。 e。コンポーネント、ライブラリ、プロトコル、および設計を満たすために必要なもの。 「設計パターン」には2つの役割があります。1つ目は、製品ではなく(多かれ少なかれ)標準問題のカテゴリを解決するためのベストプラクティスと見なされます。 2つ目は、開発者のコミュニケーションを支援することです。シングルトンの例にとどまると、毎回説明するのではなく、Wordを使用するだけで、指定されたデータスペース(変数など)を使用して単一のインスタンスを作成したことにより、メカニクスが何であるかを知ることができます制御された方法であり、クラスのコンストラクタなどを保護しているため、唯一のものであることが保証されています。したがって、あなたの質問に対する短い答えは次のとおりです。それは理にかなっていますか?