http://www.cppblog.com/mzty/archive/2007/03/02/19109.html  C++基础

http://www.cppblog.com/mzty/archive/2007/04/16/22064.html  C#界面，C++核心算法

http://www.cppblog.com/mzty/archive/2007/03/04/19163.html  设计模式

http://www.cppblog.com/mzty/archive/2007/03/29/20893.html  64bit，FW3.0随笔分类

http://www.cppblog.com/mzty/archive/2007/03/29/20892.html  windows脚本技术

http://www.cppblog.com/mzty/archive/2007/03/04/19167.html  C#基础

Creational : Singleton Pattern

First step in any MFC application is the creation of application object (object of class derived from CWinApp). There should be only one application object in an instance of MFC application. CWinApp is designed to make sure that only application object is present in a given instance. CWinApp and its descendants are called Singleton Classes. A class (CWinApp or its descendant) that assures a maximum of ONE object of its type at a given time and provides a global access point (AfxGetApp() method) to this object is a Singleton class.

As this principle is applied over and over again to solve recurring object "creational" problems, this becomes a pattern. Singleton Pattern ensures that a class only has one instance and provides a global access point it. The article Creating Singleton Objects using Visual C++ talks about different approaches for implementing Singletons.

Structural : Bridge Pattern

Bridge Pattern is all about decoupling an abstraction (interface) from its implementation so that the two can vary independently. In MFC, the process of storing/retrieving an object to/from a persistence mechanism (like a file) is called Serialization. MFC uses the Bridge Pattern to implement Serialization. CArchive and CFile classes implement object Serialization. CArchive class provides the interface for writing/reading an object to/from a persistence mechanism whereas the CFile and its sub classes provides implementation for different persistence mechanisms such as memory, disk file, sockets etc.

A CArchive object is configured with an object of class CFile (or a derived class) during its construction, from which it obtains the necessary information for serialization, including the filename and type of the requested operation (a read or write). Client performing the Serialization operation can use CArchive object without regarding the persistence mechanism implemented by CFile classes.

The article Bridge Pattern - Bridging the gap between Interface and Implementation talks about Bridge pattern in detail.

Behavioral : Observer Pattern

The Observer Pattern is intended to "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically". An object that is subjected to change is called a Subject and an object that depends on the Subject's state is called an Observer.

MFC uses a Document/View variant of the Observer Pattern. MFC's famous Document/View architecture uses this variant. A document contains the data object and acts as a Subject. A view is a window object through which the user updates the document and it acts as an Observer. A document can have multiple views. Whenever the data in the document is changed by one of the views, it updates the document by calling UpdateAllViews method, with optional hint about the modification. To inform about the change to other views, the document object calls OnUpdate method for each view attached to it (except the view that called UpdateAllViews). Derived view classes can override the OnUpdate method and update themselves by querying the data from the document.

The article Applying Observer Pattern in C++ Applications talks about Observer pattern in detail.

Summary

Design Pattern provides a common language for designers and helps them to decompose systems into a set of cooperating classes and objects. They provide proven design solution to recurring problems. In this article, I have introduced the design pattern and how MFC is using some of the patterns in its design. We can easily find more and more patterns when we dig into MFC and its classes.

• 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。
• 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Vi s i t o r 使得你可以将相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时，用Vi s i t o r 模式让每个应用仅包含需要用到的操作。
• 定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。

// Visitor pattern -- Structural example

using System; using System.Collections; namespace DoFactory.GangOfFour.Visitor.Structural {      // MainApp test application   class MainApp   {     staticvoid Main()     {       // Setup structure       ObjectStructure o = new ObjectStructure();       o.Attach(new ConcreteElementA());       o.Attach(new ConcreteElementB());       // Create visitor objects       ConcreteVisitor1 v1 = new ConcreteVisitor1();       ConcreteVisitor2 v2 = new ConcreteVisitor2();       // Structure accepting visitors       o.Accept(v1);       o.Accept(v2);       // Wait for user       Console.Read();     }   }   // "Visitor"   abstractclass Visitor   {     publicabstractvoid VisitConcreteElementA(       ConcreteElementA concreteElementA);     publicabstractvoid VisitConcreteElementB(       ConcreteElementB concreteElementB);   }   // "ConcreteVisitor1"   class ConcreteVisitor1 : Visitor   {     publicoverridevoid VisitConcreteElementA(       ConcreteElementA concreteElementA)     {       Console.WriteLine("{0} visited by {1}",         concreteElementA.GetType().Name, this.GetType().Name);     }     publicoverridevoid VisitConcreteElementB(       ConcreteElementB concreteElementB)     {       Console.WriteLine("{0} visited by {1}",         concreteElementB.GetType().Name, this.GetType().Name);     }   }   // "ConcreteVisitor2"   class ConcreteVisitor2 : Visitor   {     publicoverridevoid VisitConcreteElementA(       ConcreteElementA concreteElementA)     {       Console.WriteLine("{0} visited by {1}",         concreteElementA.GetType().Name, this.GetType().Name);     }     publicoverridevoid VisitConcreteElementB(       ConcreteElementB concreteElementB)     {       Console.WriteLine("{0} visited by {1}",         concreteElementB.GetType().Name, this.GetType().Name);     }   }   // "Element"   abstractclass Element   {     publicabstractvoid Accept(Visitor visitor);   }   // "ConcreteElementA"   class ConcreteElementA : Element   {     publicoverridevoid Accept(Visitor visitor)     {       visitor.VisitConcreteElementA(this);     }     publicvoid OperationA()     {     }   }   // "ConcreteElementB"   class ConcreteElementB : Element   {     publicoverridevoid Accept(Visitor visitor)     {       visitor.VisitConcreteElementB(this);     }     publicvoid OperationB()     {     }   }   // "ObjectStructure"   class ObjectStructure   {     private ArrayList elements = new ArrayList();     publicvoid Attach(Element element)     {       elements.Add(element);     }     publicvoid Detach(Element element)     {       elements.Remove(element);     }     publicvoid Accept(Visitor visitor)     {       foreach (Element e in elements)       {         e.Accept(visitor);       }     }   } }

• 访问一个聚合对象的内容而无需暴露它的内部表示。
• 支持对聚合对象的多种遍历。
• 为遍历不同的聚合结构提供一个统一的接口(即, 支持多态迭代)。

namespace Iterator_DesignPattern
{
    using System;
    using System.Collections;

    class Node 
    {
        private string name;
        public string Name 
        {
            get 
            {
                return name;    
            }
        }
        public Node(string s)
        {
            name = s;
        }
    }
    
    class NodeCollection 
    {
        private ArrayList list = new ArrayList();
        private int nodeMax = 0;
        
        // left as a student exercise - implement collection
        // functions to remove and edit entries also
        public void AddNode(Node n)
        {
            list.Add(n); 
            nodeMax++;            
        }        
        public Node GetNode(int i)
        {
            return ((Node) list[i]);
        }

        public int NodeMax 
        {            
            get 
            {
                return nodeMax;
            }
        }
    }

    /**//*
     * The iterator needs to understand how to traverse the collection 
     * It can do that as way it pleases - forward, reverse, depth-first, 
     */
    abstract class Iterator 
    {
        abstract public Node Next();        
    }

    class ReverseIterator : Iterator
    {
        private NodeCollection nodeCollection;
        private int currentIndex;

        public ReverseIterator (NodeCollection c)
        {
            nodeCollection = c;            
            currentIndex = c.NodeMax -1; // array index starts at 0!
        }

        // note: as the code stands, if the collection changes,
        // the iterator needs to be restarted 
        override public Node Next()
        {
            if (currentIndex == -1)
                return null;
            else 
                return(nodeCollection.GetNode(currentIndex--));
        }
    }
    
    /**//// <summary>
    ///    Summary description for Client.
    /// </summary>
    public class Client
    {
        public static int Main(string[] args)
        {   
            NodeCollection c = new NodeCollection();
            c.AddNode(new Node("first"));
            c.AddNode(new Node("second"));
            c.AddNode(new Node("third"));

            // now use iterator to traverse this
            ReverseIterator i = new ReverseIterator(c);

            // the code below will work with any iterator type
            Node n;
            do 
            {
                n = i.Next();
                if (n != null) 
                    Console.WriteLine("{0}", n.Name);
            } while (n != null);
                
            return 0;
        }
    }
}

• 抽象出待执行的动作以参数化某对象，你可用过程语言中的回调（c a l l b a c k ）函数表达这种参数化机制。所谓回调函数是指函数先在某处注册，而它将在稍后某个需要的时候被调用。C o m m a n d 模式是回调机制的一个面向对象的替代品。
• 在不同的时刻指定、排列和执行请求。一个C o m m a n d 对象可以有一个与初始请求无关的生存期。如果一个请求的接收者可用一种与地址空间无关的方式表达，那么就可将负责该请求的命令对象传送给另一个不同的进程并在那儿实现该请求。
• 支持取消操作。C o m m a n d 的E x c u t e 操作可在实施操作前将状态存储起来，在取消操作时这个状态用来消除该操作的影响。C o m m a n d 接口必须添加一个U n e x e c u t e 操作，该操作取消上一次E x e c u t e 调用的效果。执行的命令被存储在一个历史列表中。可通过向后和向前遍历这一列表并分别调用U n e x e c u t e 和E x e c u t e 来实现重数不限的“取消”和“重做”。
• 支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。在C o m m a n d 接口中添加装载操作和存储操作，可以用来保持变动的一个一致的修改日志。从崩溃中恢复的过程包括从磁盘中重新读入记录下来的命令并用E x e c u t e 操作重新执行它们。
• 用构建在原语操作上的高层操作构造一个系统。这样一种结构在支持事务( t r a n s a c t i o n )的信息系统中很常见。一个事务封装了对数据的一组变动。C o m m a n d 模式提供了对事务进行建模的方法。C o m m a n d 有一个公共的接口，使得你可以用同一种方式调用所有的事务。同时使用该模式也易于添加新事务以扩展系统。

namespace Command_DesignPattern
{
    using System;

    abstract class Command 
    {
        abstract public void Execute();
        protected Receiver r;
        public Receiver R
        {
            set 
            {
                r = value; 
            }
        }
    }

    class ConcreteCommand : Command
    {
        override public void Execute()
        {
            Console.WriteLine("Command executed");
            r.InformAboutCommand();
        }
    }

    class Receiver 
    {
        public void InformAboutCommand()
        {
            Console.WriteLine("Receiver informed about command");
        }
        
    }

    class Invoker 
    {
        private Command command;
        public void StoreCommand(Command c)
        {
            command = c;
        }
        public void ExecuteCommand()
        {
            command.Execute();
        }        
    }

    /**//// <summary>
    ///    Summary description for Client.
    /// </summary>
    public class Client
    {
        public static int Main(string[] args)
        {        
            // Set up everything
            Command c = new ConcreteCommand();
            Receiver r = new Receiver();
            c.R = r;
            Invoker i = new Invoker();
            i.StoreCommand(c);

            // now let application run

            // the invoker is how the command is exposed for the end-user 
            // (or a client) initiates the command, 
            // (e.g. toolbar button, menu item)

            i.ExecuteCommand();

            return 0;
        }
    }
}

• 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。
• 各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。这是O p d y k e 和J o h n s o n 所描述过的“重分解以一般化”的一个很好的例子[ O J 9 3 ]。首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
• 控制子类扩展。模板方法只在特定点调用“h o o k ”操作（参见效果一节），这样就只允许在这些点进行扩展。

namespace TemplateMethod_DesignPattern
{
    using System;

    class Algorithm 
    {
        public void DoAlgorithm() 
        {
            Console.WriteLine("In DoAlgorithm");
            
            // do some part of the algorithm here
            
            // step1 goes here
            Console.WriteLine("In Algorithm - DoAlgoStep1");            
            // . . . 

            // step 2 goes here
            Console.WriteLine("In Algorithm - DoAlgoStep2");            
            // . . . 

            // Now call configurable/replacable part
            DoAlgoStep3();

            // step 4 goes here
            Console.WriteLine("In Algorithm - DoAlgoStep4");            
            // . . . 

            // Now call next configurable part
            DoAlgoStep5();
        }

        virtual public void DoAlgoStep3()
        {
            Console.WriteLine("In Algorithm - DoAlgoStep3");        
        }

        virtual public void DoAlgoStep5()
        {
            Console.WriteLine("In Algorithm - DoAlgoStep5");            
        }
    }

    class CustomAlgorithm : Algorithm
    {
        public override void DoAlgoStep3()
        {
            Console.WriteLine("In CustomAlgorithm - DoAlgoStep3");
        }

        public override void DoAlgoStep5()
        {
            Console.WriteLine("In CustomAlgorithm - DoAlgoStep5");
        }
    }

    /**//// <summary>
    ///    Summary description for Client.
    /// </summary>
    public class Client
    {
        public static int Main(string[] args)
        {
            CustomAlgorithm c = new CustomAlgorithm();

            c.DoAlgorithm();

            return 0;
        }
    }
}

准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。这就是模版方法模式的用意。

很多人可能没有想到，模版方法模式实际上是所有模式中最为常见的几个模式之一，而且很多人可能使用过模版方法模式而没有意识到自己已经使用了这个模式。模版方法模式是基于继承的代码复用的基本技术，模版方法模式的结构和用法也是面向对象设计的核心。

模版方法模式需要开发抽象类和具体子类的设计师之间的协作。一个设计师负责给出一个算法的轮廓和骨架，另一些设计师则负责给出这个算法的各个逻辑步骤。代表这些具体逻辑步骤的方法称做基本方法（primitive method）；而将这些基本法方法总汇起来的方法叫做模版方法（template method），这个设计模式的名字就是从此而来。
 模版方法模式中的方法

模版方法中的方法可以分为两大类：模版方法（Template Method）和基本方法（Primitive Method)。

模版方法

一个模版方法是定义在抽象类中的，把基本操作方法组合在一起形成一个总算法或一个总行为的方法。这个模版方法一般会在抽象类中定义，并由子类不加以修改地完全继承下来。

基本方法

基本方法又可以分为三种：抽象方法（Abstract Method）、具体方法（Concrete Method）和钩子方法（Hook Method）。

抽象方法：一个抽象方法由抽象类声明，由具体子类实现。在C#语言里一个抽象方法以abstract关键字标示出来。

具体方法：一个具体方法由抽象类声明并实现，而子类并不实现或置换。在C#语言里面，一个具体方法没有abstract关键字。

钩子方法：一个钩子方法由抽象类声明并实现，而子类会加以扩展。通常抽象类给出的实现是一个空实现，作为方法的默认实现。（Visual FoxPro中项目向导建立的项目会使用一个AppHook类实现监视项目成员变化，调整系统结构的工作。）钩子方法的名字通常以do开始。

• 你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为，在程序运行时刻实现部分应可以被选择或者切换。
• 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时B r i d g e 模式使你可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。
• 对一个抽象的实现部分的修改应对客户不产生影响，即客户的代码不必重新编译。
• （C + +）你想对客户完全隐藏抽象的实现部分。在C + +中，类的表示在类接口中是可见的。
• 有许多类要生成。这样一种类层次结构说明你必须将一个对象分解成两个部分。R u m b a u g h 称这种类层次结构为“嵌套的普化”（nested generalizations ）。
• 你想在多个对象间共享实现（可能使用引用计数），但同时要求客户并不知道这一点。一个简单的例子便是C o p l i e n 的S t r i n g 类[ C o p 9 2 ]，在这个类中多个对象可以共享同一个字符串表示（S t r i n g R e p ）。

namespace Bridge_DesignPattern
{
    using System;

    class Abstraction 
    {
        protected Implementation impToUse;

        public void SetImplementation(Implementation i)
        {
            impToUse = i;
        }

        virtual public void DumpString(string str)
        {
            impToUse.DoStringOp(str);                   
        }
    }

    class DerivedAbstraction_One : Abstraction 
    {
        override public void DumpString(string str)
        {
            str += ".com";
            impToUse.DoStringOp(str);            
        }        
    }

    class Implementation 
    {
        public virtual void DoStringOp(string str)
        {
            Console.WriteLine("Standard implementation - print string as is");
            Console.WriteLine("string = {0}", str);
        }        
    }

    class DerivedImplementation_One : Implementation 
    {
        override public void DoStringOp(string str)
        {
            Console.WriteLine("DerivedImplementation_One - don't print string");
        }    
    }

    class DerivedImplementation_Two : Implementation 
    {
        override public void DoStringOp(string str)
        {
            Console.WriteLine("DerivedImplementation_Two - print string twice");
            Console.WriteLine("string = {0}", str);
            Console.WriteLine("string = {0}", str);
        }    
    }
    
    /**//// <summary>
    ///    Summary description for Client.
    /// </summary>
    public class Client
    {
        Abstraction SetupMyParticularAbstraction() 
        {
            // we localize to this method the decision which abstraction and
            // which implementation to use. These need to be decided 
            // somewhere and we do it here. All teh rest of the client 
            // code can work against the abstraction object. 
            Abstraction a = new DerivedAbstraction_One();
            a.SetImplementation(new DerivedImplementation_Two());
            return a;
        }

        public static int Main(string[] args)
        {         
            Client c = new Client();
            Abstraction a = c.SetupMyParticularAbstraction();
                
            // From here on client code thinks it is talking to the 
            // abstraction, and will not need to be changed as 
            // derived abstractions are changed. 

            // more client code using the abstraction goes here 
            // . . . 
            a.DumpString("Clipcode");

            return 0;
        }
    }
}