初心者のためのデザインのモデル

公開: 2016-01-13

大小を問わず、製品またはソフトウェアアプリケーション用のプログラムを既に作成している場合は、多くのデザインパターンを使用している可能性があります。ただし、最も使用されている/標準のデザインパターンの1つではない可能性があります。

しかし、はい、デザインパターンを実装することとデザインパターンを「使用する」ことには明らかな違いがあります…いずれにせよ、デザインパターンを扱う人はそれを理解するか、簡単に理解します。

重要なのは、デザインパターンはプログラマーにとって目新しいものではないということです。

以下の記事では、デザインパターンの基本を説明しようとしていますが、別の記事でさまざまなパターンや例などの詳細を検討します。

デザインパターンとは何ですか?

始める…

デザインパターンを理解することから始める最良の方法は、私たちが日常生活で故意に/無意識にたどる非技術的なパターンを理解することだと思います。

たとえば、求人のために提出された履歴書をたくさん見てみましょう。 全員の履歴書は同じようには見えません…全員が同じことをする傾向がありますが、それは読者に彼らが何に熟練しているのか、または彼/彼女がどのように仕事に適しているのかを伝えることです。

履歴書を仕事に提出する彼らの大多数は、フォーマットされたWord文書の特定の情報セットを含む履歴書を提出する必要があることを知っています。

これは…パターンであり、誰もが特定の情報セットを表現した履歴書を提出します。

気になる場合は…パターンではなくテンプレートと呼んでください。 デザインテンプレート。

実生活にはパターンというものがたくさんあります。 以下の例が好きな人もいます。

世界中のすべてのシェフが同じ方法でピザやフライドポテトを調理します。 彼らはそれを上回ったり、味を変えたりするかもしれませんが。 それがパターンです。

すべての車のデザインは、基本的なデザインパターン、4つのホイール、ステアリングホイール、アクセルブレーキクラッチなどのコアドライブシステムに従います。

繰り返し製造/生産されるすべてのものは、必然的にその設計のパターンに従うものとします…それが車、ピザ、ATMマシン、何であれ…歯ブラシでさえ。

ソフトウェアでいくつかのロジック/メカニズム/テクニックをコーディングする標準的な方法になりつつあるデザインは、ソフトウェアデザインパターンとして知られるようになり、したがって研究されるようになります。

デザインパターンが重要なのはなぜですか?

基本的に2つの理由で:

  1. 標準に固執する
  2. 開発を固定するには

詳しく説明します。

まず、標準パターンに固執することが興味深い理由を理解します。

前に説明した履歴書の例のリストを見てみましょう。

適切なフォーマットやメールの添付ファイルなどを使用せずに、メールテキストで求人応募を送信する応募者が1人または2人いる可能性があります。これらの応募者は、パターンに従わず、最終的には発生しない可能性があります。仕事で…。 なぜ? 彼らは確立されたパターンから逸脱しているので、それは仕事の履歴書をショートリストに載せる人々には好まれないかもしれません。

パターンから外れて「かっこいい」人はいないのでしょうか? それはイノベーションではありませんか?

はい、非常に異なって提示された履歴書が他とは異なるために仕事を得る時があります。 普段は、自分の作品のCDムービーを編集して上映したり、自分の作品を説明するアニメキャラクターを作ったり、ブログに載せたりして、一流の仕事に就いたウェブデザイナーのことを聞いたことがあります。

しかし..これは実験です(イノベーションは成功した実験から生まれます)。

ほとんどの場合、ソフトウェア開発では、タイムラインのプレッシャーや期待などのために実験する余裕はありませんが、いくつかの興味深いプロジェクトでは、いくつかの実験が可能になる場合があります。

ソフトウェアでは、銀行預金のような基本的なことを行うことはできません…101の方法で…銀行預金を処理する方法はいくつかあります。したがって、確立されテストされたパターンに従うことは理にかなっています。

また、ほとんどのデザインパターンにはバリエーションがあります…一部のバリエーションは非常に人気があるため、バリエーションも新しい標準タイプのパターンになります。

最近のソフトウェアプロジェクトは、(少なくとも暗黙のうちに)市場ですでに確立されている同様の製品/ソフトウェアの設計に従うことが期待されています。

これは、標準的なスタイルのコーディングまたはデザインパターンに固執することが、ソフトウェア開発に役立つ場合です。開発を強化し、テストされていない新しい実装について心配するオーバーヘッドを取り除きます。

開発時間の短縮

標準のデザインパターンに従うことには、ソフトウェアアーキテクト、モジュールリード、チームリード、開発者などのツリー/階層を介して、「何」だけでなく、「どのように」何かを開発する必要があるかについて簡単に通信できるという利点もあります。発展した。

テスターは、特定のデザインパターンに従ったコードが、特定の期間に一連のテストツールを使用して特定の方法でテストできる可能性があり、そのような既知のデザインには欠陥がない可能性があることを経験から知っているため、テストチームに役立つこともあります。またはいくつかの「既知の」欠陥があります。

デザインパターンを使用すると、個人的な感触が失われませんか?

いいえ。第一に、デザインパターンに従っていると言っているのではなく、他に何も起こらないからです。 ほとんどのプロジェクトの実装は、他のプロジェクトと基本的な要件を共有するだけであり、逸脱している可能性があります。 これらの偏差を構築するには、実装で使用される標準パターンを曲げたり伸ばしたりする必要があります。

これは、ピザを標準的な方法で作成し、フレーバーを付けたり、フルパイピザやカットパイなどのさまざまな要件に合わせて提示したりするようなものです。

デザインパターンの重要性を理解する上で、1つのことが非常に**重要です:

デザインパターンは、特定の企業やプログラミング言語が私たちに強制するテクノロジーやフレームワークではありません。 つまり、それはオープンコンセプトのようなものです。あなたはそれを自由に取り、それを使用し、あなたのニーズに合わせて修正し、そして重要なことに…それをあなた自身のものと感じます。

すべての標準または人気のあるデザインパターンは、実際にはかなり拡張可能です。まず、多くの人がそれを使用するという理由だけで人気が出てきました。多くの人は、要件に柔軟であるという理由だけでそれを使用します。

または、標準のデザインパターンが、ある会社のニュージャージー州のプロジェクトや、別の会社や別のタイプのプロジェクトのバンガロールのプロジェクトにどのように適合すると思いますか。

これにより、「ほとんどのデザインパターンは汎用的」になります。つまり、同じタイプのソフトウェアを構築するために常に使用されるとは限りません。 一般的な議論で使用される「銀行のソフトウェアデザインパターン」や「ソーシャルネットワーキングソフトウェアのデザインパターン」のようなものは聞こえないかもしれませんが、「デザインパターン」だけが聞こえます。

デザインパターンについて誰が気にする必要がありますか?

  1. 優れた建築家が建物を設計するスキルを伸ばすのと同じように、ソフトウェアアーキテクトは、生涯を通じて多くの建物や形状の建築と設計を研究することにより、世界中のさまざまなソフトウェア/テクノロジーシステムがどのように設計されているかを研究して視覚化する必要があります。設計されました。
  2. そして、建物の建設作業員が、自分の経験から、または建物の建築家からそれを理解することによって、建物の設計を実装するさまざまな方法をどのように認識すべきかと同じように。

ソフトウェア開発者/プログラマーは、基本的なソフトウェアデザインパターンとその実装コードを理解する必要があります…自分自身または特定のパターンに従って開発するようにチームに指示するソフトウェアアーキテクトから。

基本的なコードパターン

この記事の冒頭で、プログラマーなら誰でもデザインパターンを使用するだろうと述べました。 パターンに従ったコードの非常に基本的な例を次に示します。

  1. 以下は、基本的なインターセプトフィルターのデザインパターンです。
  2. コピーコードを非表示
  3. [コード]
    スイッチ(条件){
    ケース値1:
    ケース値2:
    ディフォルト:
    }
    [/コード]
  4. イベントトリガー、イベントハンドラーは、基本的なサブジェクトオブザーバーデザインパターンに分類されます。 それぞれのパターンの標準、人気のあるバリエーションについて、例を挙げて説明します。
  5. C#のArraylistなど、ある種のコレクションを使用し、配列を反復処理した場合は、基本的なIteratorデザインパターンを使用したことになります。
  6. 以下のコードは、基本的な例外処理/責任の連鎖パターンの例です。
  7. コピーコードを非表示
  8. [コード]
    試す{
    } catch(Exception ex){
    }
    最後に{
    }
    [/コード]

デザインパターンのさまざまな領域

ソフトウェアには、デザインパターン以外のさまざまな用語があります。それらのいくつかは、これまでに説明したデザインパターンに関連していることが多く、完全に無関係なものもあります。

これまでに説明したことは、「実装デザインパターン」と呼ばれることもあります。

アーキテクチャパターン、フレームワークパターン、言語パターン(主に言語構造と呼ばれる)のような他のものがあります。

それらはさまざまなレベルで配置されたパターンです…言語パターンは、言語の機能/構成として、C#/ Javaのようなプログラミング言語の一部として実装されたパターンです。それらのいくつかはすでに見ました。

上記の主語オブザーバー、インターセプトフィルターなどの例はすべて、Cの後に続くすべての一般的な高級プログラミング言語の言語構造として吸収されます。

アーキテクチャパターンは、ソフトウェアアーキテクチャの標準モデルであり、通常、モジュール、レイヤー、または層を配置またはリンクして、完全なアプリケーションを構成するさまざまな方法を指します。

これは、コーディング/プログラミングの意味でのデザインパターンとはまったく関係ありませんが、この記事で説明したように、Why's / What'sと同じ答えを共有しています。

フレームワークパターンも、デザインパターンの説明とは関係ありません。 .NETのようなフレームワークが、エラーをログに記録したり、フレームワークの組み込みメソッドまたはオブジェクトを介してコード実行ルートを簡単にトレースしたりするための特別な手段を実装する場合、そのようなメカニズムはフレームワークパターンと呼ばれます。

.NET Frameworkの例としては、stackTrace機能、クラス/メソッド定義の上に[]角括弧が付いたクラス属性機能などがあります。このような機能を使用する場合は、Frameworkの組み込みパターンを使用してコーディングします。

この記事がデザインパターンと関連用語の概要を提供するのに役立つことを願っています。

これまでのところ、標準とは何か、そしてそれらがどれほど重要であるかについてのみ説明しましたが、標準パターン自体については説明しませんでした。

ライセンス

この記事は、関連するソースコードおよびファイルとともに、The Code Project Open License(CPOL)の下でライセンスされています。