そして、インタフェースフレームワークのデザインパターン

デザインパターン

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

1. デザインパターンは、開発中に遭遇した人々が提案した一般的な問題を解決します
2. たとえば：戦争の芸術における様々な戦略は、実際に特定の状況のた​​めに学んだ教訓であります
3. プログラム開発のデザインパターンは、静的ではなく、あくまでも参考であり、

一般的なデザインパターン

1. シンプルなファクトリパターン（代表的なアプリケーション：単一のオブジェクトが作成した問題を解決するための拡張）
2. 抽象ファクトリー（代表的なアプリケーション：データベース・アクセスの問題やビジネスロジックの様々な異なるタイプのを解決するために）
3. シングルトン（代表的なアプリケーション：WEB開発で、カートの設計時間をショッピング）

現実の開発の問題点

1. このプロジェクトは、レポートを印刷するためのプログラムが必要ですが、ユーザーは、いくつかの企業は、他のレポートコンポーネントを使用することができ、いくつかの企業は、Wordのレポートを使用し、例えば、一部の企業は、いくつかの企業が直接デザインレポートを使用するExcelのレポートを使用するプロジェクト報告書の様々なを使用することができます
2. プロジェクトでは、モジュール設計は、プロジェクトが異なるだけで、ユーザーのレポートのニーズを満たすために設定を変更する必要が解放され、少なくとも3つのレポートが必要です

ソリューション

1. システムの問題へのデザインは、レポートモジュールのインターフェイスのデザインを使用することを検討しているので
2. 同じ要件の異なる症状は多状態アプリケーションの条件に沿ったものでありますが、

シンプルなファクトリパターン

原理は簡単ファクトリパターンであります

1. 「インタフェースオブジェクトクラス」を作成すべきかを指定するには、「選択」メソッドを介してプラント
2. 「工場」は実際にオブジェクトを作成する方法、いわゆる「の作成延期」オブジェクトであります

シンプルな工場の問題

ユーザーは、レポートの他の新しいタイプを追加することを提案し、再び更新する必要がある場合、我々は、オブジェクト指向に違反して、工場内のコードを変更する必要がある「オープン - 。クローズドの原則」

簡単な工場に反映

リフレクトメトリ

コンセプト

レフレックス（反射）.NETは重要な技術である、あなたはなど反射、メソッド、プロパティ、イベント、およびコンストラクタを介して、実行時に情報をさまざまな種類のを得ることができている、あなたはまた、各メンバーの名前を取得することができますその他の情報

機能

プログラムは完全に、動的に作成されたオブジェクト、コール・メソッド、プロパティセット、火災のイベントではなく、コンパイル時に実行されています

反射したアプリケーション

1. VSは、反射技術を使用しているMSIL ILコードを表示するには、抗コンパイルツールの使用を提案することができます
2. Java開発ツールを使用してEclipseプラグインも技術に反映されています

開発アプリケーション

1. システムがベースとするプラグインの開発を必要とするとき、反射使用することが必要です
2. 単純な反射技術は、植物の使用を必要とし、抽象的な工場の設計パターンのとき
3. 一般反射界面と一緒に使用しています
4. 反射技術は、それが必要でない限り、やや減少し、システムのパフォーマンスを可能にし、またはあまり使用しません

インタフェースフレームワーク

3層アーキテクチャに基づいて、インターフェイスのデザイン

チームワークの保証を開発

1. プロジェクト名、モジュール名、要求仕様のクラスの準備、要件のコメント...
2. データベースの設計仕様：命名テーブル、エンティティの属性、制約の名前...
3. 垂直分割、並行開発：共同プロジェクト開発の形で。

労働の縦割り：

1. タスクの区分：その機能に応じて
2. 技術要件：開発者がプロ​​ジェクトのモジュール（DAL / BLL / UI）書き込みに精通している必要があり必要です
3. 用途：中小プロジェクト、および開発チームの強さは比較的小さいです
4. より現実的な：中小企業と同様に、「ワークショップ」の生産

並行開発：

1. タスクの区分：に従い、ソフトウェア・モジュールの実装（一般的なビジネス・ロジック、データ・アクセス、ビュー、...）
2. 技術要件：法律は、独自の対応するモジュール技術を習得する必要がある開発者が必要です

ハードウェアインタフェースアプリケーション

インタフェースの設計と製造

1. ハードウェアのアプリケーションインタフェース異なるベンダーは、彼らが製品の最高の生産を何に焦点を当てることができるように
2. インターフェイス製品インターフェイス製品+ =異なるハードウェアの組成

製品を保つために、すべての製品メーカーを制御するタスクのインターフェースは、メーカーが自社製品の品質に集中できるようにする統一されたインタフェースで、何のもつれの共通の問題ありません

界面層

利点：

1. 並行開発の問題を解決するには良いチームワーク
2. システムのスケーラビリティはさらに新しい特徴点を追加するとき、界面層と層が容易に互いに独立して、各作業の完全に独立した変更の同期を達成することができる強化され
3. プロジェクト開発者のためのより大きく、より適したを使用している場合

短所：

1. 増加にフレームワークを設計し、開発することは困難ワークロード
2. プロジェクトが小さい場合には使用すべきではありません

インターフェイスの設計のベースとなる、他の3層アーキテクチャアーキテクチャに加えても使用することができます

インタフェースおよびインタフェースの導入を使用するのではなく、開発チームとプロジェクトの実際のニーズに応じて、インターフェイスを使用するかどうか

開発のフレームを選択

基本的なフレームワーク

小規模プロジェクトでは、簡単な、個人的な開発、短いプロジェクトサイクルを備え

2層のフレームワーク

小規模プロジェクト、もう少し機能的、個人的な開発やチーム開発、適度なプロジェクトサイクル

3層アーキテクチャ

大・中規模のプロジェクト、多機能、プロチーム開発、長いプロジェクトサイクル

界面層

大・中規模のプロジェクト、多くの機能、専門家チーム並行開発、長いプロジェクトサイクル