アルゴリズム、フレームワーク、パターンの関係について

パターンは孤立して存在するのではなく、相互に関連しています。関係とは、それらが互いに対照的であること、接続されていること、一連のパターンを構築していること、パターンのリポジトリを構築していること、さらにはパターン言語であることを意味します。これらの関係をさらに掘り下げてみましょう。

デザインパターン、アルゴリズム、フレームワークという用語には共通点があります。それらを区別しましょう。

デザイン パターン、アルゴリズム、フレームワークについて

これら 3 つの用語の違いについて説明する前に、簡潔な定義を次に示します。

  • デザイン パターン :"各パターンは 3 つの部分からなるルールであり、特定のコンテキスト、問題、および解決策の間の関係を表します ." (クリストファー・アレクサンダー)
  • アルゴリズム :"数学とコンピュータ サイエンスでは、アルゴリズムは厳密な命令の有限シーケンスであり、通常、特定の問題のクラスを解決したり、計算を実行したりするために使用されます。 " (https://en.wikipedia.org/wiki/アルゴリズム)
  • フレームワーク :"コンピュータ プログラミングでは、ソフトウェア フレームワークは抽象化されたものであり、一般的な機能を提供するソフトウェアは、追加のユーザー作成コードによって選択的に変更できるため、アプリケーション固有のソフトウェアを提供します ." (https://en.wikipedia.org/wiki/Software_framework)

よし、もっと深く掘り下げよう。

設計パターンとアルゴリズム

定義に基づくと、アルゴリズムは特定の問題を解決するための一連のステップですが、設計パターンは特定のコンテキストで問題を解決するための一般的なソリューションです。

デザイン パターンとフレームワーク

まず、フレームワークはハリウッドの原則 (「私たちに電話しないで、私たちはあなたに電話します」) に基づいています。 Hollywood Principe は、制御フローがフレームワークによって決定されるが、呼び出し元がライブラリを使用する場合には決定されないことを意味します。このフレームワークは、特定のメソッドをオーバーライドすることによってユーザーのみが拡張できる最小限のアプリケーションを提供します。

最後に、本「デザイン パターン:再利用可能なオブジェクト指向ソフトウェアの要素」(デザイン パターン) からのデザイン パターンとフレームワークの違いを次に示します。

パターンとフレームワークにはいくつかの類似点があるため、人々はそれらがどのように異なるのか、あるいは異なるのかさえ疑問に思うことがよくあります。これらは主に 3 つの点で異なります:

<オール>
  • デザイン パターンは、フレームワークよりも抽象的です。フレームワークはコードで具現化できますが、コードで具現化できるのはパターンの例だけです。フレームワークの強みは、それらをプログラミング言語で書き留めて、学習するだけでなく、直接実行して再利用できることです。対照的に、この本の設計パターンは、使用するたびに実装する必要があります。デザイン パターンは、デザインの意図、トレードオフ、および結果についても説明します。
  • デザイン パターンは、フレームワークよりも小さなアーキテクチャ要素です。典型的なフレームワークにはいくつかのデザイン パターンが含まれていますが、その逆は決してありません。
  • デザイン パターンは、フレームワークほど専門的ではありません。フレームワークには常に特定のアプリケーション ドメインがあります。ファクトリ シミュレーションではグラフィカル エディター フレームワークが使用される場合がありますが、シミュレーション フレームワークと間違われることはありません。対照的に、このカタログのデザイン パターンは、ほぼすべての種類のアプリケーションで使用できます。私たちのものよりも専門的な設計パターン (たとえば、分散システムや並行プログラミングの設計パターン) は確かに可能ですが、それらでさえ、フレームワークのようにアプリケーション アーキテクチャを決定することはありません.
  • パターンの関係に関する次のより理論的な考察は、書籍「パターン指向ソフトウェア アーキテクチャ、第 5 巻」(POSA 5) に基づいています。この本の著者は、Frank Buschmann、Kevlin Henny、Douglas C. Schmidt です。

    パターン関係

    パターンは島ではありません。それらはしばしば互いに関連しています。したがって、それらの関係を説明するにはさまざまな方法があります。

    パターン補完

    通常、パターンは互いに補完します。 1 つのパターンは、別のパターンで開始された設計プロセスをより完全なものにします。このプロセスには、同様の設計課題を解決するパターンも含まれています。

    ストラテジー パターンとテンプレート メソッドはパターン補完です。どちらも古典的な「デザイン パターン」の本からの行動パターンです。それらは同様の目的を果たします。アルゴリズムのバリエーションは、統一された方法で処理する必要があります。主な違いは、戦略パターンがオブジェクト レベルで実装を提供し、オブジェクトの構成と委任を使用することです。テンプレート メソッドは、仮想性に基づいてクラス レベルでその実装を提供します。

    パターン コンパウンド

    多くの場合、複合パターンは新しいパターンを構築します。

    パターン複合の典型的な例は、アーキテクチャ パターンの Model-View-Controller (MVC) です。 POSA 1 の MVC は、ユーザー インターフェイスのプログラム ロジックを個別のコンポーネント モデル、ビュー、およびコントローラーに分割します。モデルは、アプリケーションのデータとルールを管理します。ビューはデータを表し、コントローラーはユーザーと対話します。

    MVC で使用される「デザイン パターン」本からいくつかのパターンを以下に示します。

    • ビューはモデルの変化を観察します (オブザーバー パターン)。
    • コントローラーは、ユーザー入力を処理するための戦略です (戦略パターン)。
    • ビューはサブビューを持つことができるため、複合パターンのコンポーネントです。

    パターン シーケンス

    パターン シーケンスは、別の設計課題に適用できる典型的なパターン シーケンスです。

    ツリーを反復処理し、 show などのリーフ ノードでさまざまな操作を実行するとします。 または count .

    まず、このツリーを通る反復子が必要です (反復子パターン)。もちろん、ノードに子があるかどうかを区別する必要があります。子を持つノードは操作 を委任します 彼らの子供たちだけに。子を持たないノード自体が表示されます (複合パターン)。訪問者パターンは、ツリーでのさまざまな操作をサポートするために使用されます。多くの場合、3 つのパターンはすべて順番に使用されます。

    パターン コレクション

    パターン コレクションは、パターンの整理されたリポジトリです。

    最終的には何千ものパターンがあり、必要に応じてそれらを収集して検索する必要が生じます。

    パターンを整理するにはさまざまな方法があります。たとえば、レベル別 (アーキテクチャ パターン、デザイン パターン、イディオム)、ドメイン別 (アビオニクス、金融、ヘルスケアなど)、または目的別に収集できます。 デザイン パターンの本と POSA の本は、意図。たとえば、パターン言語に関する次の段落は、POSA 4 の順序を示しています。

    パターン言語

    パターン言語は、特定のドメインのパターンの完全なセットを記述します。その意図は、この特定のドメインにおける設計上の課題を解決することです。 Frank Buschmann、Kevlin Henney、および Douglas C. Schmidt による本 Pattern-Oriented Software Architecture, Volume 4:A Pattern Language for Distributed Programming は、そのようなパターン言語を提示しています。簡単に言うと、この本は次のようにグループ化された 120 を超えるパターンを示しています。

    • 泥から構造物まで
    • 分散インフラストラクチャ
    • イベントの逆多重化とディスパッチ
    • インターフェースの分割
    • コンポーネントのパーティショニング
    • アプリケーション コントロール
    • 同時実行
    • 同期
    • オブジェクトの相互作用
    • 適応と拡張
    • モーダル動作
    • リソース管理
    • データベースへのアクセス

    これらのパターンの多くについては、今後の投稿で書きます。

    次は?

    アンチパターンは、自分の足を撃つための実証済みの方法です。アンチパターンという用語は、Andrew Koenig によって造られたもので、パターンに関する次の投稿のトピックです。