hujianglang / blog Goto Github PK

    动机（Motivation)
    在软件系统中，经常面临着“某个对象”的创建工作；由于需求的变化，这个对象经常面临着剧烈的变化，但是它
    却拥有比较稳定的接口；
     
    如何应对这种变化？如何提供一种“封装机制”来隔离出“这个易变对象的”变化，从而保持系统中“其他依赖对象的对象”
    不随着需求的改变而改变呢？

    备注：设计模式一定有稳定的/不变的部分，还有变化多的部分，着重解决变化多的部分。
     
    意图：（Intent)
    定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使得一个类的实例化延迟到子类。（设计模式）
    
    Factory Method模式的几个要点：
    1，Factory Method模式主要用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，
    紧耦合关系会导致软件的脆弱。

    2，Factory Method 模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非
    更改）的策略，较好地解决了这种紧耦合的关系；

    3，Factory Method模式解决单个对象的需求变化，Abstract Factory模式解决系列对象的需求变化，
    Builder模式解决对象部分的需求变化；
     */


class Program
{
    static void Main(string[] args)
    {
        CarTestFramework carTestFramework = new CarTestFramework();
        //也可以根据配置文件来设置传递进去的参数
        carTestFramework.BuildTestContext(new DongfengCarFactory());

    }
}

public class DongfengCarFactory : CarFactory
{
    public override Car CreateCar()
    {
        return new DongfengCar();
    }
}


abstract class Car
{
    public void Stop();
    public void Run();
    public void Turn(Direction direction);
}

class ACar
{
    //Enigee engiee;
    public void Turn(Direction direction)
    {

    }

    public void Stop()
    {

    }

    public void Run()
    {

    }

}

abstract class AbstractCarFactory
{
    public abstract Car CreateCar();
}


class CarFactory
{
    public Car CreateCar() {
        return new HongiCar();
    }

    
}

class CarTestFramework
{
    public  void BuildTestContext(CarFactory carFactory)
    {
        AbstractCar c1 = carFactory.createCar();
        AbstractCar c2 = carFactory.createCar();
        AbstractCar c3 = carFactory.createCar();
    }



    public void DoTest(Abstract car)
    {
        car.Run();

    }
}

    /*
    OOP关键： 寻找变化点
    new的问题
    常规的对象创建方法：
    //创建一个Road对象
    Road road = new Road();
    //new 的问题:实现依赖，不能应对具体实例化类型的变化。
    解决思路：
    封装变化点：哪里变化，封装哪里
    潜台词：如果没有变化，，当然不需要额外的封装；

    工厂模式的缘起：
    变化点在“对象创建”，因此就封装对象创建
    面向接口编程-依赖接口，而非依赖实现
    最简单的解决方法：
    class RoadFactor
    {
        public static Road CreateRoad()
        {
            return new Road();
        }
        
    }
    //创建一个Road对象
    Road road = RoadFactor.CreateRoad();
    简单工厂问题：
    不能应对不同系列对象的变化，比如有不同风格的游戏场景--对应不同风格的道路、房屋、地道..
    如何解决：
    使用面向对象的技术来封装变化点。 
    动机（Motivation)
    在软件系统中，经常面临着一系列相互依赖的对象的创建工作，同时，由于需求的变化，往往存在着更多系列对象的创建工作；
    如何应对这种变化？
    如何绕过常规的对象创建方法（new）提供一种封装机制，来避免客户程序和这种“多系列具体对象创建工作的”紧耦合？
    意图（Intent)
    提供一个接口，让该接口负责创建一系列相关或者相互依赖的对象，无需指定它们具体的类。
    */

    public abstract class Road
    {

    }
    public abstract class Building
    {

    }
    public abstract class Tunnel
    {

    }
    public abstract class Jungle
    {

    }
    public abstract class FacilitiesFactory
    {
        public abstract Road CreateRoad();
        public abstract Tunnel CreateTunnel();
        public abstract Building CreateBuilding();
        public abstract Jungle CreateJungle();
    }

    public class ModernRoad : Road
    {

    }

    public class ModernBuilding : Building
    {

    }

    public class ModernFacilitiesFactory : FacilitiesFactory
    {
        public override Road CreateRoad()
        {
            return new ModernRoad();
        }

        public override Building CreateBuilding()
        {
            return new ModernBuilding();
        }

        public override Tunnel CreateTunnel()
        {
            throw new NotImplementedException();
        }

        public override Jungle CreateJungle()
        {
            throw new NotImplementedException();
        }
    }
    /*
    Abstract Factory 模式的几个要点：
    1，如果没有应对多系列对象构建的需求变化，则没有必要使用Abstract Factory模式，这时候只需要简单的静态工厂模式就完全可以。
    2，系列对象指的是对象之间有相互依赖或者作用的关系，例如游戏开发场景中的道路和房屋的依赖，道路与地道的依赖。
    3，Abstract Factory模式主要在于应对新系列的变动，其缺点在于难以应对新对象的需求变动。（产品吧）
    4，Abstract Factory模式经常和Factory Method模式共同组合来应对对象创建的需求变化。
    */

constexpr int a = (0+2)*3;
constexpr int b = a+2;

return -1;

        //Builder模式的缘起
        /*
         * 假设创建游戏中的一个房屋House设施，该房屋的构建由几个部分组成，且
         * 各个部分要富于变化。
         * 
         * 如果使用最直观的设计方法，每一个房屋部分的变化，都将导致房屋构建的重新修正...
         动机：
         在软件系统中，有时候面临着一种复杂对象的创建工作，其通常由各个部分的子对象用一定的
         算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将他们
         组合在一起的算法却相对稳定。

         如何应对这种变化？如何提供一种封装机制来隔离出复杂对象的各个部分的变化，从而保持系统中
         的稳定构建算法不随着需求改变而改变？

        意图：将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。（GOF设计模式）

         */

        public abstract class House {

        }

        public abstract class Builder
        {
            public abstract void BuildDoor();
            public abstract void BuildWall();
            public abstract void BuildWindows();
            public abstract void BuildFloor();
            public abstract void BuildHouseCeiling();

            public abstract House GetHouse();

        }

        public class GameManager
        {
            public static House CreateHouse(Builder builder)
            {
                //此处代码可以根据需求变化，从数据库，配置文件读取信息来根据需要构建
                //以下过程是相对稳定的部分，相比buildDoor/floor/houseCeiling/wall等，这些是变化的。
                //而整个流程是相对稳定不变的
                builder.BuildDoor();
                builder.BuildDoor();
                builder.BuildFloor();
                builder.BuildFloor();
                builder.BuildHouseCeiling();
                builder.BuildWall();
                builder.BuildWall();
                return builder.GetHouse();
            }
        }
        //example1:
        public class RomanHouse : House
        {

        }

        //抽象类
        public abstract class Windows
        {

        }

        public abstract class Door
        {

        }

        public class RomanDoor : Door
        {

        }
        public class RomanWindows : Windows
        {

        }



        //其他抽象类，具体类可自行定义

        public class RomainHouseBuilder : Builder
        {
            public override void BuildDoor()
            {

            }

            public override void BuildFloor()
            {

            }

            public override void BuildHouseCeiling()
            {
                throw new NotImplementedException();
            }

            public override void BuildWall()
            {
                throw new NotImplementedException();
            }

            public override void BuildWindows()
            {
                throw new NotImplementedException();
            }

            public override House GetHouse()
            {
                throw new NotImplementedException();
            }

        }

        //使用过程
        class APP
        {
            public static void Main()
            {
                House house = GameManager.CreateHouse(new RomainHouseBuilder());

                //也可以从配置文件中读取相关的builder信息
                string assemblyName = ConfigurationSettings["BuilderAssembly"];
                string buildName = ConfigurationSettings["BuilderClass"];
                Assembly assembly = Assembly.Load(assemblyName);
                Type t = assembly.GetType("builderName");
                Builder builder = Activator.CreateInstance(t);
                House house1 = GameManager.CreateHouse(builder);
            }
        }
        /*

        抽象工厂解决系列对象的变化情况，Builder模式解决部分变化的需求情况；
        Builder模式的几个要点：
        1，Builder模式主要用于“分步骤构建一个复杂的对象"。在这其中”分步骤“是一个稳定的算法，而复杂对象的
        各个部分则经常变化。
        
        2，变化点在哪里，封装就在哪里。Builder模式主要在于应对“复杂对象各个部分"的频繁需求变动。其缺点在于
        难以 应对分步骤构建算法的需求变动。

        3，Abstract Factory模式解决系列对象的需求变化，Builder模式解决对象部分的需求变化。Builder模式通常和
        Composite模式组合使用。

        */

    /*
    C#  面向对象设计模式纵横谈
    Adapter适配器（结构性模式）
    适配，即在不改变原有实现的基础上，将原先不兼容的接口转换为兼容的接口。 
    动机（Motivation)
    在软件系统中，由于应对环境的变化，常常需要将一些现存的对象放在新的环境中应用，但是新环境要求的接口是这些
    现存对象所不能满足的。
    如何应对这种迁移的变化呢?如何既能够利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？

    意图（Intent)
    将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。（设计模式）
    备注：继承是紧耦合，父类的改变很容易影响到子类，相比来说，组合就是松耦合的。

    Adapter模式的几个要点：
    1，Adapter模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况，在遗留代码复用、类库迁移等方面
    非常有用。
    2，GoF23定义了两种Adapter模式的实现结构，对象适配器和类适配器，但类适配器采用多继承的方式，带来了不良的高耦合，
    所以一般不推荐使用。对象适配器采用对象组合的模式，更符合松耦合精神。
    3，Adapter模式 可以实现的非常灵活，不必拘泥于Gof23种定义的两种结构。例如，完全可以将Adapter模式中的现存对象
    作为新的接口方法参数，来达到适配的目的。
    4，Adapter模式本身要求我们尽可能地使用面向接口编程风格，这样才能在后期很方便地进行适配。
     */


    interface IStack
        {
            void Push(object item);
            object Pop();
            object Peek();
        }
        class Adapter : IStack
        {
            ArrayList adaptee;
            //ArrayList adaptee2;
            public Adapter()
            {

            }
            public void Push(object item)
            {

            }

            public object Pop() { }
            public object Peek() { }
        }

        class EmployeeSortAdapter : IComparer
        {
            public int Compare(object obj1, object obj2)
            {
                if (obj1.GetType() != typeof(Employee)
                    || obj2.GetType() != typeof(Employee))
                    return new Exception();


                Employee e1 = (Employee)obj1;
                Employee e2 = (Employee)obj2;

                if (e1.Age == e2.Age)
                    return 0;

                else if (e1.Age > e2.Age)
                    return 1;
                else if (e1.Age < e2.Age)
                    return 2;
            }
        }
        //Employee [] employees = new Employee[100];
        //Array.Sort(employees,new EmployeeSortAdapter());

    模式分类
    从目的来看：
    创建型模式：负责对象创建
    结构型模式：处理类与对象的组合
    行为型模式：类与对象交互中的职责分配

    从范围来看：
    类模式处理类与子类的静态关系
    对象模式处理对象间的动态关系

    动机：
    在软件系统中，经常有这样的一些特殊的类，必须保证它们在系统中只存在一个实例，才能
    确保它们的逻辑正确性、以及良好的效率。

    如何绕过常规的构造器，提供 一种机制来保证一个类只有一个实例？

    这应该是类设计者的责任，而不是使用者的责任。

    意图：
    保证一个类仅有一个实例，并提供一个该实例的全局访问点。-GOF


    单线程模式Singleton的几个要点：
    1，Singleton模式中的实例构造器可以设置为protected以允许子类派生
    2，Singleton模式一般不要支持ICloneable接口，因为这可能会导致多个对象实例，与
    Singleton模式的初衷违背；
    3,Singleton模式一般不要支持序列化，因为这也有可能导致多个对象，同样与Singleton模式的
    初衷相违背；
    4，Singleton模式只考虑了对象创建的管理，没有考虑对象销毁的管理。就支持垃圾回收的
    平台和对象的开销来讲，我们一般没有必要对其销毁进行特殊的管理。
    5，不能应对多线程环境：在多线程环境下，使用Singleton模式仍然有可能得到Singleton
    类的多个实例对象。
 * 
 */
//单线程Singleton模式实现

public class Singleton
{
    private static Singleton instance;
    private Singleton() { }
    public static Singleton Instance
    {
        get
        {
            if(instance == null)
            {
                instance = new Singleton();
            }
            return instance;
        }
    }
}

//method 2
public class Singleton1
{
    private static Singleton1 instance = new Singleton1();
    private Singleton1() { }

    public static Singleton1 Instance
    {
        get
        {
            return instance;
        }
    }
}


class Test
{
    public static void Main()
    {
        Singleton t1 = Singleton.Instance;
        Singleton t2 = Singleton.Instance;
        Console.WriteLine(object.ReferenceEquals(t1,t2) == true);
    }
}

//多线程Singleton模式实现

public class Singleton3
{
    private static volatile Singleton3 instance = null;
    private static object lockHelper = new object();
    
    private Singleton3() { }
    public static Singleton3 Instance
    {
        get
        {
            if(instance == null)
            {
                lock(lockHelper)
                {
                    if(instance == null)
                    {
                        instance = new Singleton3();
                    }
                }
            }
            return instance;
        }
    }
}

//多线程其他写法
//method 3
public class Singleton4
{
    public static readonly Singleton4 Instance = new Singleton4();//（1）
    private Singleton4() { }
}

//method 4
public class Singleton5
{
    public static readonly Singleton5 Instance;
    static Singleton5()//（2）
    {
        Instance = new Singleton5();
    }
    private Singleton5() { }
}

//备注：(1)(2)等价

/*
Singleton模式扩展
1，将一个实例扩展到n个实例，例如对象池的实现；
2，将new构造器的调用转移到其他类中，例如多个类协同工作环境中，某个局部环境只需要拥有某个类的一个实例。
3，理解和扩展Singleton模式的核心是“如何控制用户使用new对一个类的实例构造器的任意调用”


 */
//C# 框架中的应用
/*
MyClass c1 = new MyClass();
MyClass c2 = new MyClass();
Type t1 = c1.GetType();
Type t2 = c2.GetType();
 */

    /*
    C# 面向对象设计模式  ProtoType原型（创建型模式）
    依赖关系的倒置：
    1，抽象不应该依赖于实现细节，实现细节应该依赖于抽象。
    动机（Motivation)
    1,在软件系统中，经常面临着“某些结构复杂的对象”的创建工作，由于需求的变化，
    这些对象经常面临着剧烈的变化，但是他们却拥有比较稳定一致的接口；
    2，如何应对这种变化？如何向客户程序（使用这些对象的程序）“隔离出”这些易变对象，
    从而使得依赖这些易变的客户程序不随着需求改变而改变？

    意图：（intent）
    使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。

    Prototype模式的几个要点：
    1，Prototype模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，
    它同样要求这些易变类拥有稳定的接口；
    2，Prototype模式对于如何创建易变类的实体对象采用原型克隆的方法来做，它使得我们可以非常灵活地动态创建
    拥有某些稳定接口的新对象，所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方不断地Clone.
    3,Prototye模式中的Clone方法可以利用.NET中的Object类的MemberwiseClone()方法或序列化来实现深拷贝。
    */

    public abstract class NormalActor{
        public abstract NormalActor Clone();
    }

    public class NormalActorA : NormalActor
    {
        public override NormalActor Clone()
        {
            return (NormalActorA)this.MemberwiseClone();//浅拷贝
        }
    }

    public class NormalActorB : NormalActor
    {
        public override NormalActor Clone()
        {
            return (NormalActorB)this.MemberwiseClone();
        }
    }

各种面向对象编程语言相互有别，但都能看到它们对面向对象三大机制的支持，即：封装，继承，多态
封装：隐藏内部实现
继承：复用现有代码
多态：改写对象行为

重新认识面向对象：
1，对于前面的例子，从宏观层面上看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小。
2，从微观层面来看，面向对象的方式更强调各个类的“责任”，新增类型不会影响原来类型的代码实现。

对象是什么？
1，从概念层面讲，对象是某种拥有责任的抽象；
2，从规格层面讲，对象是一系列可以被其他对象使用的公共接口；
3，从语言实现层面讲，对象封装了代码和数据。

有了这些认识后，怎样才能设计”好的面向对象“
1，遵循一定的面向对象设计原则
2，熟悉一些典型的面向对象设计模式

从设计原则到设计模式：
1，针对接口编程，而不是针对实现编程
客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口；

2，首先使用对象组合，而不是类继承
类继承通常为“白箱复用”，对象组合通常为黑箱复用。继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象
具有良好定义的接口，耦合度低。

3，封装变化点
使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间松耦合。

4，使用重构得到模式
设计模式的使用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的
Refactoring to Patterns是目前普遍公认的最好的使用设计模式的方法。

几条更具体的设计原则：
1，单一职责原则
一个类应该仅有一个引起它变化的原因

2，开放封闭原则
类模块应该是可扩展的，但是不可修改（对扩展开放，对更改封闭）

3，Liskov替换原则
子类必须能够替换它们的基类

4，依赖倒置原则
高层模块不应该依赖低层模块，二者都应该依赖于抽象。
抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

5，接口隔离原则
不应该强迫客户程序依赖于它们不用的方法

总结：
设计模式描述了软件设计过程中某一类常见问题的一般性解决方案。面向对象设计模式描述了面向对象设计过程中，
特定场景下，类与相互通信的对象之间常见的组织关系。

深刻理解面向对象是学好设计模式的基础，掌握一定的面向对象设计原则才能把握面向对象设计模式的精髓，从而实现
灵活运用设计模式。

使用重构得到模式，敏捷软件开发提倡的Refactoring to pattern 是目前普遍公认的最好的使用设计模式的方法。