Design Pattern and FTPC

宣言:rockwell社のmes製品コードに基づく設計モデル分析です.
    Design Patternについては多重化から話さなければなりません.私たち一人一人が経験、公式、ツールを使っても、他の人が設計し、発見したものを使ってから始まります.これは私たちの生活の中で多重化された具体的な表現です.ソフトウェア開発においてDesign Patternは,先人の成功した設計を将来多重化(直接または少し変更して使用する)しやすくするために抽出された再経験(経験から共有部分を発見して分類定義する)である.Design Patternという名詞は、Christopher Alexanderの建築学名著『A Pattern Language』から最初に導入された.Christopher Alexanderが言ったように、「各モデルは、私たちの周りで繰り返される問題と、この問題の解決策の核心を説明しています.これにより、繰り返し労働をする必要がなく、何度もこの案を使用することができます」.このような目的に基づいてGOFはその本の中で23個のDesign Patternを対象設計を背景にまとめている.その各モード組織テンプレートは、モード名と分類、意図、別名、動機、適用性、構造、参加者、コラボレーション、効果、実装、コード例、既知の応用、関連モードである.GOFの本から読み始めました.オブジェクト向けのデザインを背景にしているからです.したがって,オブジェクト向けのいくつかの基本概念について説明する必要がある.≪クラス|Class|ldap≫:アクティブなオブジェクトの動作、プロパティのテンプレートを定義します.オブジェクト:ステータスと動作をカプセル化した静的エンティティ.インタフェース:特定のインプリメンテーションが必要なルールのセットのみを定義し、外部が直接使用して特定のインプリメンテーション部分を遮断し、最終的に使用とインプリメンテーションの分離を実現します.抽象クラス:そのサブクラスに共通インタフェースを定義し、その実装の一部またはすべてをサブクラスに遅延します.インスタンス化できません.動的バインド:オブジェクトが送信するリクエストによって引き起こされる特定のアクションは、リクエスト自体と受信オブジェクトとに関係し、同じリクエストをサポートする異なるオブジェクトがリクエストによって励起されるアクションに異なる実装をもたらす可能性があります.オブジェクトに送信されたリクエストとその対応するアクションは、実行時まで接続されません.≪マルチステート|Multi-State|emdw≫:実行時に同じインタフェースを持つオブジェクトを互いに置換できます.この置換性をマルチステートと呼びます.継承(正規化):クラス間で部分的な操作を共有するために実現される「is a kind of」関係.組合せ:クラス間で部分的な操作を共有するために実装される「use a/has a」関係.(具体的には、「has a」を関連付け/集約し、「usea」に依存する)ことができます.     正式にテーマに入る前に、オブジェクト向けの設計を使用する重要な原則をいくつか提案する必要があります. 実装プログラミングではなく、インタフェースに対してプログラミングを行います.(実際のオブジェクトではなくインタフェースをできるだけ使用)② クラス継承ではなく、オブジェクトの組合せを優先的に使用します.(オブジェクトの組み合わせに依存する設計がより多重化されている)③ インタフェースは抽象クラスより優先されます.(インタフェースにより非階層的なフレームワークを構築できる)④ できるだけ高集約、低結合をします.⑤ 設計は変化をサポートする必要がありますが、私はよく次のような問題に直面して再設計せざるを得ません.1． クラスを明示的に指定してオブジェクトを作成します.2． 特殊な操作への依存.3． ハードウェアとソフトウェアプラットフォームに依存します.4． オブジェクトに依存して表示または実装されます.5． アルゴリズム依存.6． 緊密に結合する.7． サブクラスを生成することで機能を拡張します.8． クラスを簡単に修正することはできません.     現在ではデザインモードを適用するツール(Eclipse,など)、言語(Smalltalk,Java,C++STL,Python,Rubyなど)、フレームワーク(Structs,Spring,MFCなど)が数多く登場している.Cのような構造化言語でも,その中の関数ポインタ,パラメトリック関数,構造体,マクロ定義など,ある程度設計モードの影がある.
   以下、いくつかの非常に一般的な設計モードの使用例についてFTPCと組み合わせて検討する.モードの基本概念:抽象層を追加します.いつでも、何かを抽象化したいとき、実際には特定の細部を分離しています.このような説得力のある動機は、変化したものを不変のものから分離することです.     たとえ:具体的なことが多ければ多いほど、间违いを犯しやすいということです.これは具体的な仕事をした人一人一人が深く体得しています.逆に、官が高ければ高いほど、抽象的に言えば抽象的になるほど、间违いを犯す可能性は少なくなります.
今、私たちのFTPCコードの中のモードの応用と結びつけて、まず前菜から始めます.
まず簡単な工場モデルを見てみましょう
単純ファクトリ・モードの本質は、ファクトリ・クラスが受信したパラメータに基づいて、親またはインタフェースから継承されたどの製品クラスを作成すべきかを動的に決定するインスタンスです. 
 
(com.datasweep.compatibility.manager.ServerImpl):
 
public final ObjectManager getObjectManager(Class type, Keyed definition) {//8.0 Access Control if (type==RTBom.class) return getTBomManager(); if (type == AccessPrivilege.class) return getAccessPrivilegeManager(); else if (type == Account.class) return getAccountManager(); else if (type == ActivitySet.class) return getActivitySetManager(); else if (type == RuntimeActivitySet.class) return getRuntimeActivitySetManager(); else if (type == Application.class) ..... }

 
 
 
 
 
优缺点  
 
 
　　优点 
 
　　工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。 
 
　　缺点 
 
　　由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先教考虑到的，如果需要添加新的类，则就需要改变工厂类了。 
 
　　当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利； 
 
 
　　这些缺点在
 
 
 
 
 
 
 
工厂方法模式中得到了一定的克服。 
 
模板模式
1 定义
 
准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。这就是模版方法模式的用意。
 
模版方法模式需要开发抽象类和具体子类的设计师之间的协作。一个设计师负责给出一个算法的轮廓和骨架，另一些设计师则负责给出这个算法的各个逻辑步骤。代表这些具体逻辑步骤的方法称做基本方法（primitive method）；而将这些基本法方法总汇起来的方法叫做模版方法（template method），这个设计模式的名字就是从此而来。
 

二、 模版方法模式的结构
这里涉及到两个角色：
 
抽象模版（AbstractClass）角色有如下的责任： 
定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤。
 
定义并实现了一个模版方法。这个模版方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。
 
具体模版（ConcreteClass）角色有如下的责任： 
实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤。
 
每一个抽象模版角色都可以有任意多个具体模版角色与之对应，而每一个具体模版角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。
 
可以看看，FTPC的模板模式的实现，具体看com.datasweep.compatibility.client。Categorical。java类
 
public abstract class Categorical extends Keyed implements IAuditInfo 
{
private void initialize(){ 
// perform any data object related initialization/refreshing here.
}
            。
        。
 protected abstract void refresh_() 

            。
        。
        。
 protected abstract void save_(Time time, String comment, AccessPrivilege accessPrivilege) 
throws DatasweepException; 

            。
        。
        。
}

  
  
 
     
   
  
CategoricalクラスはFTPCで多くのクラスに継承されている.例えばaccount,activitysetである.これらのクラスは前述したテンプレートモードの具体的なテンプレートであるが、実はこのクラスは典型的なテンプレートモードの応用であり、Categoricalクラスのこの3つの方法の1つは空で実現され、2つは抽象的な方法であり、サブクラスの実現を強制する必要がある.Account,activitysetでは空実装のinitialize()メソッドはすべて布団クラスに書き換えられているが,実際には実装しなくてもよい.このテンプレートクラスの空実装方法をフックと呼ぶのが一般的ですが、フックとは何ですか.必要に応じて空の実装を書き直すことも、空の実装を維持し続け、無視することもできます.これにより、いくつかの方法が必ず実行されるか、または実現されるかを比較的柔軟に決定することができる.残りの2つの方法refresh_(),save_(....)はテンプレートメソッドの抽象メソッドであり,サブクラス実装に延期され,比較フックの違いは,すべてのテンプレートクラスCategorical.javaのサブクラスがこの2つのメソッドを実装しなければならないことであり,この2つのメソッド,すなわちテンプレートメソッドのスケルトンである.フックと抽象的な方法は共にテンプレートモードの応用を実現し,struts,serveltにおけるinit(),destory(),execute()などの方法のそれぞれのフレームワークにおけるテンプレートモードに基づく応用を比較することにも興味があり,テンプレートモードの規則的約束に対する重要な役割を体得できるに違いない.
  
  
  
  
未完待機