LorenLiu's mindview

设计模式学习笔记_C#面向对象设计模式纵横谈(15)：Command命令模式(行为型模式)

LorenLiu — Fri, 18 Jan 2008 09:49:00 GMT

耦合与变化

耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象之间存在耦合关系，实体对象与行为操作之间也存在耦合关系。

行为请求者à行为实现者

行为的请求者会调用行为实现者的实例，形成紧耦合。

动机：在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重做（undo/redo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的。

在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。

意图：

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化：对请求排队或记录请求日志，以及支持可撤销的操作。

代码展示：（部分代码，功能为用鼠标点击Panel画线，可以Undo/Redo）

ACommand.cs

public abstract class ACommand
{
public abstract void Execute();
}

AUndoableCommand.cs

public abstract class AUndoableCommand : ACommand
    {
        public abstract void Undo();
        public abstract void Redo();
    }

ADisplayCommand.cs

public abstract class ADisplayCommand : AUndoableCommand
    {
        public Graphics CurrrentGraphics
        {
            get { return mGraphics; }
            set { mGraphics = value; }
        }

        protected Graphics mGraphics;
    }

DrawLineCommand.cs（具体用来画线的Command）

public class DrawLineCommand : ADisplayCommand
    {
        public DrawLineCommand(AViewPort viewport, Color color, Point p1, Point p2)
        {
            // If g is null, we need throw exception here
            if (viewport == null) throw new ArgumentNullException();

            mViewPort = viewport;
            mColor = color;
            mStartPoint = p1;
            mEndPoint = p2;
        }

        public override void Execute()
        {
            using (Pen p = new Pen(mColor))
            {
                mGraphics.DrawLine(p, mStartPoint, mEndPoint);
            }
        }

        public override void Undo()
        {
            DisplayImp.DisplayManager.RemoveDisplayItem(this);
            mViewPort.Invalidate();
        }

        public override void Redo()
        {
            DisplayImp.DisplayManager.AddDisplayItem(this);
            mViewPort.Invalidate();
        }

        private AViewPort mViewPort;
        private Color mColor;
        private Point mStartPoint;
        private Point mEndPoint;
    }

ViewPort.cs(就是用来画图的Panel)

public class ViewPort : AViewPort
    {
        public ViewPort()
        {
            this.SetStyle(ControlStyles.AllPaintingInWmPaint, true);
            this.SetStyle(ControlStyles.UserPaint, true);
            this.SetStyle(ControlStyles.OptimizedDoubleBuffer, true);
        }

        protected override void OnPaint(PaintEventArgs e)
        {
            base.OnPaint(e);
            IEnumerator<ADisplayCommand> displayCommandsEnum = DisplayManager.DisplayItems;
            displayCommandsEnum.Reset();

            while (displayCommandsEnum.MoveNext())
            {
                ADisplayCommand command = displayCommandsEnum.Current;
                if (command == null) continue;

                command.CurrrentGraphics = e.Graphics;
                command.Execute();
            }
        }
    }

在viewport上鼠标点击生成Command，实现画图

void mViewPort_MouseClick(object sender, System.Windows.Forms.MouseEventArgs e)
        {
            mClickNum++;

            if (mClickNum % 2 == 0)
            {
                // Confirm drawing
                mSecondClickPoint = e.Location;
                try
                {
                    DrawLineCommand command = new DrawLineCommand(mViewPort, ColorManager.CurrentColor, mFirstClickPoint, mSecondClickPoint);
                    DisplayManager.AddDisplayItem(command);
                    LittlePainter.ICore.Core.UndoManager.Push(command);
                    ICore.Core.FileManager.IsDocumentDirty = true;
                    mViewPort.Invalidate();
                }
                finally
                {
                    mClickNum = 0;
                }
            }
            else
            {
                mFirstClickPoint = e.Location;
            }
        }

UndoManager.cs

public class UndoManager : IUndoManager
    {
        public UndoManager()
        {

        }

        public void Init()
        {
            mUndoStack = new Stack<AUndoableCommand>();
            mRedoStack = new Stack<AUndoableCommand>();
        }

        public void Push(AUndoableCommand undoableCommand)
        {
            mUndoStack.Push(undoableCommand);
            OnUndoChanged(EventArgs.Empty);
        }

        public Boolean CanUndo
        {
            get { return mUndoStack.Count > 0; }
        }

        public Boolean CanRedo
        {
            get { return mRedoStack.Count > 0; }
        }

        public void Undo()
        {
            AUndoableCommand undoableCommand = mUndoStack.Pop();
            undoableCommand.Undo();
            mRedoStack.Push(undoableCommand);
            OnUndoChanged(EventArgs.Empty);
        }

        public void Redo()
        {
            AUndoableCommand undoableCommand = mRedoStack.Pop();
            undoableCommand.Redo();
            mUndoStack.Push(undoableCommand);
            OnUndoChanged(EventArgs.Empty);
        }

        public event EventHandler<EventArgs> UndoChanged;

        private void OnUndoChanged(EventArgs e)
        {
            if (UndoChanged != null)
            {
                UndoChanged(this, e);
            }
        }

        private Stack<AUndoableCommand> mUndoStack;
        private Stack<AUndoableCommand> mRedoStack;
    }

解释一下，这里用UndoManager来管理这些Undoable的Command（DrawLineCommand），使用了一个undo stack 和redo stack 我们可以看到，当鼠标点击到Panel上时，生成了一个DrawLineCommand，并push到UndoManager中，同时，我们会吧它添加到DisplayManager（对其中的display command逐一执行，在panel中画出）中。这样，当我们undo的时候，我们会从display manager中删除掉该command并重画view port，redo是把它加回去，这样就实现了undo 和redo。

Command模式的几个要点

Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。

实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个“命令”封装为一个“复合命令”MacroCommand。

Command模式与C#中的Delegate有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口—实现”来定义行为接口规范，更严格，更符合抽象原则；Delegate以函数签名来定义行为接口规范，更灵活，但抽象能力比较弱。

设计模式学习笔记_C#面向对象设计模式纵横谈(14)：Template Method模板方法模式(行为型模式)

LorenLiu — Mon, 16 Apr 2007 10:56:00 GMT

动机：

在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架于应用之间的关系）而无法和任务的整体结构同时实现。

如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？

意图：

定义一个操作的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构可重定义该算法的某些特定步骤。

结构图

// 框架开发者
    public abstract class Vehical // 表示汽车
    {
        protected abstract void StartUp();

        protected abstract void Run();

        protected abstract void Turn(Int32 degree);

        protected abstract void Stop();

        public void Test()
        {
            // 测试数据记录
            StartUp(); // 晚绑定－留给应用程序开发人员，扩展点

            // 测试数据记录
            Run();

            // 测试数据记录
            Turn(45);

            // 测试数据记录
            Stop();

            // 生成测试报表
        }
    }

    class VehicalTestFramework
    {
        public static void DoTest(Vehical vehical)
        {
            vehical.Test();
        }
    }

    // 应用程序开发人员
    public class HongQiCar : Vehical
    {
        protected override void StartUp()
        {
            // 子步骤扩展
        }

        protected override void Run()
        {

        }

        protected override void Turn(int degree)
        {

        }

        protected override void Stop()
        {

        }
    }

    class App
    {
        public static void Main()
        {
            VehicalTestFramework.DoTest(new HongQiCar());
        }
    }

Template Method模式的几个要点：

Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构。

除了可以灵活应对子步骤的变化外，“不要调用我，让我来调用你”的反向控制结构是Template Method的典型应用。

在具体实现方面，被Template Method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法，纯虚方法），但一般推荐将它们设置为protected方法。

设计模式学习笔记_C#面向对象设计模式纵横谈(13)：Proxy代理模式(结构型模式)

LorenLiu — Thu, 12 Apr 2007 11:34:00 GMT

直接和间接：

人们对于复杂的软件系统常常有一种处理手法，即增加一层间接层，从而对系统获得一种更为灵活、满足特定需求的解决方案。

AàB 转变为 AàCàB

比如A调用B三次，转换为A调用C三次，C调用B一次，类似于缓存。这里C就相当于B的一个代理

动机：

在面向对象系统中，有些对象由于某些原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。

如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。

意图：

为其他对象提供一种代理以控制对这个对象的访问

结构图

class Employee
    {
        public void GetSalary()
        { }

        public void Report()
        { }

        public void ApplyVacation()
        { }
    }

    class HRSystem
    {
        // 这里隐含了Employee必须和HRSystem在同一个地址空间
        public void Process(Employee employee)
        {
            employee.Report();

            employee.ApplyVacation();
        }
    }

// 现在的需求是，做一个远程WebService的功能

    // 运行在internet远端的一台机器上
    interface IEmployee
    {
        void GetSalary();
        void Report();
        void ApplyVacation();
    }

    class Employee : IEmployee
    {
        IEmployee Members
    }

    // 运行在本地的一台机器上
    class EmployeeProxy : IEmployee
    {
        public EmployeeProxy()
        {
            // 对对象创建的一种SOAP封装
        }

        IEmployee Members
    }

    class HRSystem
    {
        public void Process()
        {
            IEmployee employeeProxy = new EmployeeProxy();

            employeeProxy.GetSalary();
            employeeProxy.Report();
            employeeProxy.ApplyVacation();
        }
    }

Proxy模式的几个要点：

“增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的proxy对象便是解决这一问题的常用手段。

具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供抽象代理层，在架构层次对对象做proxy。

Proxy并不一定要求保持接口的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。

设计模式学习笔记_C#面向对象设计模式纵横谈(12)：Flyweight享元模式(结构型模式)

LorenLiu — Tue, 10 Apr 2007 12:14:00 GMT

面向对象的代价：

面向对象很好的解决了系统抽象性的问题，同时在大多数情况下，也不会损及系统的性能。但是，在某些特殊的应用中，由于对象的数量太大，采用面向对象会给系统带来难以承受的内存开销。比如图形应用中的图元等对象、字处理应用中的字符对象等。

动机：

采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。

如何避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明的使用面向对象的方式来进行操作？

意图：

运用共享技术有效的支持大量细粒度的对象

public class Font // （12B ＋ 8B） × n
    {
        public Font(String name, Int32 size, Color color)
        {
            this.fontName = name;
            this.size = size;
            this.color = color;
        }

        String fontName; // 4B
        Int32 size; // 4B
        Color color; // 4B

        // 重写Font.Equals()
    }

    public class Charactor // （2＋2＋4＋20＋8）B
    {
        Char c; // 2B，使用享元模式不能节省空间，因为指针的大小就有4B

        Font f; // 12B＋8B，使用享元模式可以节省空间
    }

    public class System
    {
        public static void Main()
        {
            ArrayList list = new ArrayList(100000);

            for (Int32 i = 0; i < list.Count; i++)
            {
                Charactor c = new Charactor(); // 大约3M的数据，如果有10000000个数据，就有大约300M的数据

                list.Add(c);
            }
        }
    }

解决办法：

public class Charactor
    {
        public Char chr;

        Font f;

        private static Hashtable fontTable;

        public Font CFont
        {
            get { return f; }
            set
            {
                Font f = new Font(name, size, color);

                if (fontTable.ContainsKey(f))
                {
                    this.f = fontTable.Keys[f];
                }
                else
                {
                    fontTable.Add(f, this.f);
                }
            }
        }
    }

public class System
    {
        public static void Main()
        {
            ArrayList list = new ArrayList(100000);

            Font f1 = new Font("宋体", 5, Color.Red);
            Font f2 = new Font("宋体", 5, Color.Red);

            Charactor c1 = new Charactor();
            c1.chr = "a";
            c1.CFont = f1;

            Charactor c2 = new Charactor();
            c2.chr = "a";
            c2.CFont = f2; // 这里c1和c2的CFont都是指向同一个对象，这样就节省了内存成本
        }
    }

Flyweight模式的几个要点：

面向对象很好的解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。

Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。

对象的数量太大从而导致对象内存开销加大——什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断。

设计模式学习笔记_C#面向对象设计模式纵横谈(11)：Façade外观模式(结构型模式)

LorenLiu — Thu, 05 Apr 2007 11:53:00 GMT

系统的复杂度：

假设我们需要开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为，其中坦克系统由引擎，控制器，车轮车身等各子系统构成

public class Wheel
    {
        public void WAction1()
        {
        }

        public void WAction2()
        {
        }
    }

    public class Engine
    {
        public void EAction1()
        {
        }

        public void EAction2()
        {
        }
    }

    public class Bodywork
    {
        public void BAction1()
        {
        }

        public void BAction2()
        {
        }
    }

    public class Controller
    {
        public void CAction1()
        {
        }

        public void CAction2()
        {
        }
    }

当客户程序需要对这个系统进行访问时，就必须对子系统的接口有一定的了解，并对子系统的对象进行直接访问。

这种方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。

如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？

意图：

为子系统中的一组接口提供一个一致的界面，Façade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

public class TankFacade
    {
        // 使用组合方式
        private Wheel[] mWheels = new Wheel[4];
        private Engine[] mEngines = new Engine[4];
        private Bodywork mBodywork = new Bodywork();
        private Controller controller = new Controller();

        // 下面的接口是对客户程序暴露的，
        // 这样就定义了一个高层接口，使子系统
        // 更加好用
        public void Start()
        {
        }

        public void Stop()
        {
        }

        public void Run()
        {
        }

        public void Shot()
        {
        }
    }

Façade模式的几个要点：

从客户程序的角度看，Façade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到一种“解耦”的效果——内部子系统的任何变化不会影响到Façade接口的变化。

Façade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Façade很多时候更是一种架构设计模式。

注意区分Façade模式、Adapter模式、Bridge模式与Decorator模式。Façade模式注重简化接口，Adapter模式注重转换接口，Bridge模式注重分离接口（抽象）与其实现，Decorator模式注重稳定接口的前提下为对象扩展功能。