大家遥远的榨油坊

Unity脚本编程

众所周知,unity的编程属于脚本化,脚本没有一个实际的定义跟架构,
导致在品种进度中,常常现身哪个地方需求贯彻怎么样作用,就不管添加脚本,
结果,就招致了一片散乱,不好管理。

更有甚者,自己的写的代码闲置一段时间后,再去想找某个意义的落实,都要在视图中频仍找半天。
哎!请容许自己在此惊叹一声,那仍然您写的东西么?图片 1
故此,一个好的设计方式是何等的首要呀,

虽说青海是多民族地区,文物苑里大多都是哈尼族木营造筑,卢沟桥、木楼、凉亭、戏台、钟楼,全都清一色的侗寨木匠文章。

何以写脚本架构

这就是说,大家在使用unity3d开发东西的时候,脚本架构到底应该什么来写?
呵呵…

实际上,我也给不了你们切实答案,因为每个人的支出习惯,每个团队的付出格局也各有千秋,
so,在此我只做两种设计形式的下结论,

就是就是榨油坊,也是严峻根据侗寨传统建筑情势修建,丰裕浮现壮族人的驾驭和木打造筑的逆天技巧。

参考书籍

驷不及舌参考书籍有《设计情势》《设计形式之禅》《大话设计形式》以及网上一些零星的作品,
但根本内容如故自己自己的一对经历以及清醒。
写出来的目的一方面是系统地整理一下,一方面也与常见的网友享受,
至于你们到底什么样使用,
望君探究啊!图片 2

不晓得是汪涵仍然什么人,在他的人文怀旧种类里,提到一些观念的工艺活,其中浓墨重彩的讲述传统榨油坊。差不离他来看的是苏南苗族人家的村寨,图片里的榨油坊,令人感到越发熟谙,温馨。

设计方式

设计方式对编程人士来说,的确相当紧要。
本来,如若大家的知道跟我有所差异,欢迎留言,大家一齐探索。

  • 标准化1:单一义务
  • 标准2:里氏替换原则(子类伸张但不改变父类功效)
  • 规则3:信赖倒置原则
  • 条件4:接口隔离原则
  • 原则5:迪米特法则(最少知道原则)
  • 规格6:开闭原则

    基准1:单一义务规范

    说到单一任务规范,很几人都会瞧不起。
    因为它太简单了,稍有经历的程序员即便一向没有读过设计方式、一直不曾耳闻过单一职责规范,在统筹软件时也会自觉的坚守这一第一尺度,因为这是常识。
    在软件编程中,何人也不期待因为修改了一个效应造成其余的效率发生故障。
    而防止出现这一标题的法子便是绳趋尺步单一义务规范。
    尽管单一职责规范如此不难,并且被认为是常识,可是尽管是经验充足的程序员写出的先后,也会有违反这一原则的代码存在。
    为啥会油可是生这种景色吧?因为有职分扩散。所谓职务扩散,就是因为某种原因,职责被分化成了更细的职务。

    ### 用一个类描述动物呼吸这些境况

    class Animal
    {
    
        public void breathe(string animal)
        {
            Debug.Log(animal + "呼吸空气");
        }
    }
    
    public class Client
    {
        Animal animal = new Animal();
    
        void Start()
        {
    
            animal.breathe("牛");
            animal.breathe("羊");
            animal.breathe("猪");
        }
    }
    
    //运行结果:
        //牛呼吸空气
        //羊呼吸空气
        //猪呼吸空气
    

    ### 当须要变动

    先后上线后,发现难题了,并不是具备的动物都呼吸空气的,比如鱼就是呼吸水的。

    修改时如果根据单一义务规范,须要将Animal类细分为陆生动物类Terrestrial,水生动物Aquatic,代码如下:

    class Terrestrial
    {
        public void breathe(String animal)
        {
            Debug.Log(animal + "呼吸空气");
        }
    }
    
    class Aquatic
    {
        public void breathe(String animal)
        {
            Debug.Log(animal + "呼吸水");
        }
    }
    
    public class Client
    {
        public static void main(String[] args)
        {
            Terrestrial terrestrial = new Terrestrial();
            terrestrial.breathe("牛");
            terrestrial.breathe("羊");
            terrestrial.breathe("猪");
    
            Aquatic aquatic = new Aquatic();
            aquatic.breathe("鱼");
        }
    }
    
    //运行结果:
        //牛呼吸空气
        //羊呼吸空气
        //猪呼吸空气
        //鱼呼吸水
    

    ### 改动量小的主意

    咱俩会发觉只要那样修改资费是很大的,除了将本来的类分解之外,还亟需修改客户端。
    而从来修改类Animal来达到目的纵然违背了单纯职责规范,但开支却小的多,代码如下:

    class Animal
    {
        public void breathe(String animal)
        {
            if ("鱼" == animal)
            {
                Debug.Log((animal + "呼吸水"));
            }
            else
            {
                Debug.Log((animal + "呼吸空气"));
            }
        }
    }
    
    public class Client
    {
        public static void main(String[] args)
        {
            Animal animal = new Animal();
            animal.breathe("牛");
            animal.breathe("羊");
            animal.breathe("猪");
            animal.breathe("鱼");
        }
    }
    

    ### 隐患

    可以看看,那种修改章程要简单的多。
    然则却存在着隐患:有一天内需将鱼分为呼吸淡水的鱼和呼吸海水的鱼,
    则又要求修改Animal类的breathe方法,而对原本代码的修改会对调用“猪”“牛”“羊”等有关职能带来危害,
    兴许某一天你会发觉程序运行的结果变成“牛呼吸水”了。
    那种修改章程直接在代码级别上违反了单一职务规范,尽管修改起来最简便易行,但隐患却是最大的。

    ### 另一种修改章程

    class Animal
    {
        public void breathe(String animal)
        {
            Debug.Log(animal + "呼吸空气");
        }
    
        public void breathe2(String animal)
        {
            Debug.Log(animal + "呼吸水");
        }
    }
    
    public class Client
    {
        public static void main(String[] args)
        {
            Animal animal = new Animal();
            animal.breathe("牛");
            animal.breathe("羊");
            animal.breathe("猪");
            animal.breathe2("鱼");
        }
    }
    

    可以见到,那种修改章程没有改观原来的措施,而是在类中新加了一个办法,那样尽管也违反了单纯性职务规范,
    但在艺术级别上却是符合单一职务规范的,因为它并没有动原来方式的代码。那三种格局各有利害,
    那就是说在实质上编程中,选择哪一中呢?
    实际上那实在比较难说,须要依照实际情形来确定。
    自我的尺度是:只有逻辑充裕简单,才得以在代码级别上违反单一职务规范;唯有类中方法数量丰富少,才方可在措施级别上违反单一义务规范。

    ### 听从单一职分原的长处有

  • 可以降低类的复杂度,一个类只承担一项义务,其逻辑肯定要比负责多项任务不难的多;

  • 升高类的可读性,提高系统的可维护性;

  • 改变引起的风险下降,变更是必然的,假如纯粹任务规范遵从的好,当修改一个效应时,可以肯定下降对其它职能的震慑。

    急需表明的某些是纯粹职责规范不只是面向对象编程思想所特有的,只如果模块化的主次设计,都适用单一职分规范。

    规范2:里氏替换原则

    ### 名字的由来

    毫无疑问有为数不少人跟自己刚看到那项条件的时候同样,对那个条件的名字充满疑心。
    实际上原因就是那项条件最早是在1988年,由新加坡国立大学的一位姓里的女郎(BarbaraLiskov)指出来的。
    概括的话的话,就是当大家接纳持续时,遵守里氏替换原则。

    ### 定义

    注:类B继承类A时,除添加新的办法成功新增功外,尽量不要重写父类A的点子,也硬着头皮不要重载父类A的主意。
    一连包涵那样一层意思:父类中凡是已经落到实处好的艺术(相对于肤浅方法而言),实际上是在设定一多级的业内和契约,
    纵然它不强制须要拥有的子类必须信守那么些契约,可是倘诺子类对那一个非抽象方法任意修改,
    就会对一切继承体系造成破坏。而里氏替换原则就是抒发了这一层意思。
    接二连三作为面向对象三大特征之一,在给程序设计带来巨大便利的同时,也推动了弊端。
    譬如动用持续会给程序带来侵入性,程序的可移植性下落,伸张了目的间的耦合性,如果一个类被其余的类所继承,
    则当以此类必要修改时,必须考虑到具有的子类,并且父类修改后,
    持有关乎到子类的法力都有可能会生出故障。

    ### 继承的高危机

    那就让我们一道看看继承的高危机,如下:

    class A
    {
        public int func1(int a, int b)
        {
            return a - b;
        }
    }
    
    public class Client
    {
        void Start()
        {
            A a = new A();
            Debug.Log("100-50=" + a.func1(100, 50));
            Debug.Log("100-80=" + a.func1(100, 80));
        }
    }
    

    #### 运行结果

    100-50=50
    100-80=20

    ### 需要变动

    新生,大家必要增添一个新的作用:落成两数相加,然后再与100求和,由类B来担负。
    即类B要求形成七个职能:
    两数相减。
    两数相加,然后再加100。
    由于类A已经实现了第三个功用,所以类B继承类A后,只须求再形成第四个职能就可以了,代码如下

    class B:A
    {
        public int func1(int a, int b)
        {
            return a + b;
        }
    
        public int func2(int a, int b)
        {
            return func1(a, b) + 100;
        }
    }
    
    public class Client
    {
        private void Start()
        {
            B b = new B();
            Debug.Log("100-50=" + b.func1(100, 50));
            Debug.Log("100-80=" + b.func1(100, 80));
            Debug.Log("100+20+100=" + b.func2(100, 20));
        }
    }
    

    #### 类B运行结果

    100-50=150
    100-80=180
    100+20+100=220

    ### 影响了正常的效应

    大家发现原先运行正常化的相减成效发生了错误。
    缘由就是类B在给艺术起名时无意中重写了父类的法门,造成所有运行相减功能的代码全部调用了类B重写后的措施,造成原本运行如常的效率出现了不当。
    在本例中,引用基类A完结的效果,换成子类B之后,暴发了越发。
    在实际上编程中,大家日常会经过重写父类的章程来成功新的法力,那样写起来纵然简易,
    只是凡事继承种类的可复用性会相比差,越发是选取多态比较频仍时,程序运行出错的几率非常大。
    一经非要重写父类的措施,相比较通用的做法是:原来的父类和子类都继承一个更易懂的基类,原有的接续关系去掉,选择看重、聚合,组合等关联代替。

    ### 里氏替换原则通俗的来讲就是

    子类可以扩大父类的职能,但不可以改变父类原有的功用。它富含以下4层意思:
    1.子类可以完毕父类的架空方法,但不能够掩盖父类的非抽象方法。
    2.子类中得以追加和谐有意的点子。
    3.当子类的法门重载父类的章程时,方法的放到条件(即方法的形参)要比父类方法的输入参数更宽松。
    4.当子类的方法完结父类的空洞方法时,方法的前置条件(即方法的再次来到值)要比父类更严刻。

看上去很不可思议,因为我们会发现在自己编程中常常会违反里氏替换原则,程序照样跑的好好的。  
所以大家都会产生这样的疑问,假如我非要不遵循里氏替换原则会有什么后果?  
后果就是:你写的代码出问题的几率将会大大增加。

**原则3:依赖倒置原则**
-----------------------

### 定义

高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。  
抽象指的是接口或者抽象类,细节就是具体的实现类,使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。

### 依赖倒置原则核心思想

依赖倒置原则的核心思想是面向接口编程,我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。

### 情景举例

场景是这样的,母亲给孩子讲故事,只要给她一本书,她就可以照着书给孩子讲故事了。代码如下:

    class Book
    {
        public String getContent()
        {
            return "很久很久以前有一个阿拉伯的故事……";
        }
    }

    class Mother
    {
        public void narrate(Book book)
        {
            Debug.Log("妈妈开始讲故事");
            Debug.Log(book.getContent());
        }
    }

    public class Client
    {
        void Start()
        {
            Mother mother = new Mother();
            mother.narrate(new Book());
        }
    }

#### 运行结果:

妈妈开始讲故事  
很久很久以前有一个阿拉伯的故事……

### 需求变动

运行良好,假如有一天,需求变成这样:不是给书而是给一份报纸,让这位母亲讲一下报纸上的故事,报纸的代码如下:

    class Newspaper
    {
        public String getContent()
        {
            return "林书豪38+7领导尼克斯击败湖人……";
        }
    }

这位母亲却办不到,因为她居然不会读报纸上的故事,这太荒唐了,只是将书换成报纸,居然必须要修改Mother才能读。  
假如以后需求换成杂志呢?换成网页呢?  
还要不断地修改Mother,这显然不是好的设计。  
原因就是Mother与Book之间的耦合性太高了,必须降低他们之间的耦合度才行。

### 抽象的接口

我们引入一个抽象的接口IReader。  
读物,只要是带字的都属于读物:

    interface IReader
    {
        String getContent();
    }

Mother类与接口IReader发生依赖关系,而Book和Newspaper都属于读物的范畴,  
他们各自都去实现IReader接口,这样就符合依赖倒置原则了,代码修改为:

    interface IReader
    {
        String getContent();
    }

    class Newspaper : IReader
    {
        public String getContent()
        {
            return "林书豪17+9助尼克斯击败老鹰……";
        }
    }
    class Book : IReader
    {
        public String getContent()
        {
            return "很久很久以前有一个阿拉伯的故事……";
        }
    }

    class Mother
    {
        public void narrate(IReader reader)
        {
            Debug.Log("妈妈开始讲故事");
            Debug.Log(reader.getContent());
        }
    }

    public class Client
    {
        public static void main(String[] args)
        {
            Mother mother = new Mother();
            mother.narrate(new Book());
            mother.narrate(new Newspaper());
        }
    }

#### *运行结果*

*妈妈开始讲故事  
很久很久以前有一个阿拉伯的故事……  
妈妈开始讲故事  
林书豪17+9助尼克斯击败老鹰……*


这样修改后,无论以后怎样扩展Client类,都不需要再修改Mother类了。  
这只是一个简单的例子,实际情况中,代表高层模块的Mother类将负责完成主要的业务逻辑,一旦需要对它进行修改,引入错误的风险极大。  
所以遵循依赖倒置原则可以降低类之间的耦合性,提高系统的稳定性,降低修改程序造成的风险。  
采用依赖倒置原则给多人并行开发带来了极大的便利,


比如上例中,原本Mother类与Book类直接耦合时,Mother类必须等Book类编码完成后才可以进行编码,因为Mother类依赖于Book类。  
修改后的程序则可以同时开工,互不影响,因为Mother与Book类一点关系也没有。  
参与协作开发的人越多、项目越庞大,采用依赖导致原则的意义就越重大。  
现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。

### 在实际编程中,我们一般需要做到如下3点

1.低层模块尽量都要有抽象类或接口,或者两者都有。  
2.变量的声明类型尽量是抽象类或接口。使用继承时遵循里氏替换原则。  
3.依赖倒置原则的核心就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。

原则4:接口隔离原则
-------------------

### 定义

客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。  
将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。  
举例来说明接口隔离原则:

### 未遵循接口隔离原则的设计

[![](https://images0.cnblogs.com/blog/363476/201502/121642263862512.jpg)](https://images0.cnblogs.com/blog/363476/201502/121642244953356.jpg)   
这个图的意思是:类A依赖接口I中的方法1、方法2、方法3,类B是对类A依赖的实现。  
类C依赖接口I中的方法1、方法4、方法5,类D是对类C依赖的实现。  
对于类B和类D来说,虽然他们都存在着用不到的方法(也就是图中红色字体标记的方法),但由于实现了接口I,所以也必须要实现这些用不到的方法。

### 示例代码

对类图不熟悉的可以参照程序代码来理解,代码如下:

    //接口
    interface I
    {
        void method1();
        void method2();
        void method3();
        void method4();
        void method5();
    }

    class A
    {
        public void depend1(I i)
        {
            i.method1();
        }
        public void depend2(I i)
        {
            i.method2();
        }
        public void depend3(I i)
        {
            i.method3();
        }
    }

    class B : I
    {
        public void method1()
        {
            Debug.Log("类B实现接口I的方法1");
        }
        public void method2()
        {
            Debug.Log("类B实现接口I的方法2");
        }
        public void method3()
        {
            Debug.Log("类B实现接口I的方法3");
        }
        //对于类B来说,method4和method5不是必需的,但是由于接口A中有这两个方法,
        //所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。
        public void method4() { }
        public void method5() { }
    }

    class C
    {
        public void depend1(I i)
        {
            i.method1();
        }
        public void depend2(I i)
        {
            i.method4();
        }
        public void depend3(I i)
        {
            i.method5();
        }
    }

    class D : I
    {
        public void method1()
        {
            Debug.Log("类D实现接口I的方法1");
        }
        //对于类D来说,method2和method3不是必需的,但是由于接口A中有这两个方法,
        //所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。
        public void method2() { }
        public void method3() { }

        public void method4()
        {
            Debug.Log("类D实现接口I的方法4");
        }
        public void method5()
        {
            Debug.Log("类D实现接口I的方法5");
        }
    }

    public class Client
    {
        void Start()
        {
            A a = new A();
            a.depend1(new B());
           a.depend2(new B());
           a.depend3(new B());

            C c = new C();
          c.depend1(new D()));
            c.depend2(new D());
            c.depend3(new D());
        }
    }

可以看到,如果接口过于臃肿,只要接口中出现的方法,不管对依赖于它的类有没有用处,实现类中都必须去实现这些方法,这显然不是好的设计。  
如果将这个设计修改为符合接口隔离原则,就必须对接口I进行拆分。

### 遵循接口隔离原则的设计

在这里我们将原有的接口I拆分为三个接口,拆分后的设计如图2所示:

[![](https://images0.cnblogs.com/blog/363476/201502/121642286981139.jpg)](https://images0.cnblogs.com/blog/363476/201502/121642275421825.jpg)

### 示例代码

照例贴出程序的代码,供不熟悉类图的朋友参考:

    interface I1
    {
         void method1();
    }

    interface I2
    {
         void method2();
         void method3();
    }

    interface I3
    {
         void method4();
         void method5();
    }

    class A
    {
        public void depend1(I1 i)
        {
            i.method1();
        }
        public void depend2(I2 i)
        {
            i.method2();
        }
        public void depend3(I2 i)
        {
            i.method3();
        }
    }

    class B : I1, I2
    {
        public void method1()
        {
            Debug.Log("类B实现接口I1的方法1");
        }
        public void method2()
        {
            Debug.Log("类B实现接口I2的方法2");
        }
        public void method3()
        {
            Debug.Log("类B实现接口I2的方法3");
        }
    }

    class C
    {
        public void depend1(I1 i)
        {
            i.method1();
        }
        public void depend2(I3 i)
        {
            i.method4();
        }
        public void depend3(I3 i)
        {
            i.method5();
        }
    }

    class D : I1, I3
    {
        public void method1()
        {
            Debug.Log("类D实现接口I1的方法1");
        }
        public void method4()
        {
            Debug.Log("类D实现接口I3的方法4");
        }
        public void method5()
        {
            Debug.Log("类D实现接口I3的方法5");
        }
    }

接口隔离原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。  
也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。  
本文例子中,将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。


在程序设计中,依赖几个专用的接口要比依赖一个综合的接口更灵活。  
接口是设计时对外部设定的“契约”,通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。  
说到这里,很多人会觉的接口隔离原则跟之前的单一职责原则很相似,其实不然。  
其一,单一职责原则原注重的是职责;而接口隔离原则注重对接口依赖的隔离。  
其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;

而接口隔离原则主要约束接口,主要针对抽象,针对程序整体框架的构建。

### 注意几点

采用接口隔离原则对接口进行约束时,要注意以下几点:  
1.接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。  
2.为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。  
3.提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。  
运用接口隔离原则,一定要适度,接口设计的过大或过小都不好。设计接口的时候,只有多花些时间去思考和筹划,才能准确地实践这一原则。

 

原则5:迪米特法则
-----------------

### 定义

**一个对象应该对其他对象保持最少的了解**  
类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。  
因此,尽量降低类与类之间的耦合。  
自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚。  
无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。  
低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的。

### 最少知道原则

迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern
University的Ian Holland提出。  
通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。  
迪米特法则还有一个更简单的定义:只与直接的朋友通信。首先来解释一下什么是直接的朋友:  
每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。  
耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,  
而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。

### 违反迪米特法则的设计

举一个例子:有一个集团公司,下属单位有分公司和直属部门,现在要求打印出所有下属单位的员工ID。  
先来看一下违反迪米特法则的设计。

    //总公司员工
    class Employee
    {
        private String id;
        public void setId(String id)
        {
            this.id = id;
        }
        public String getId()
        {
            return id;
        }
    }

    //分公司员工
    class SubEmployee
    {
        private String id;
        public void setId(String id)
        {
            this.id = id;
        }
        public String getId()
        {
            return id;
        }
    }

    class SubCompanyManager
    {
        public List<SubEmployee> getAllEmployee()
        {
            List<SubEmployee> list = new List<SubEmployee>();
            for (int i = 0; i < 100; i++)
            {
                SubEmployee emp = new SubEmployee();
                //为分公司人员按顺序分配一个ID
                emp.setId("分公司" + i);
                list.Add(emp);
            }
            return list;
        }
    }

    class CompanyManager
    {

        public List<Employee> getAllEmployee()
        {
            List<Employee> list = new List<Employee>();
            for (int i = 0; i < 30; i++)
            {
                Employee emp = new Employee();
                //为总公司人员按顺序分配一个ID
                emp.setId("总公司" + i);
                list.Add(emp);
            }
            return list;
        }

        public void printAllEmployee(SubCompanyManager sub)
        {
            List<SubEmployee> list1 = sub.getAllEmployee();
            foreach (SubEmployee e in list1)
            {
                Debug.Log(e.getId());
            }


            List<Employee> list2 = this.getAllEmployee();
            foreach (Employee e in list2)
            {
                Debug.Log(e.getId());
            }
        }
    }

    public class Client
    {
        void Start()
        {
            CompanyManager e = new CompanyManager();
            e.printAllEmployee(new SubCompanyManager());
        }
    }

现在这个设计的主要问题出在CompanyManager中,根据迪米特法则,只与直接的朋友发生通信,  
而SubEmployee类并不是CompanyManager类的直接朋友(以局部变量出现的耦合不属于直接朋友),从逻辑上讲总公司只与他的分公司耦合就行了,  
与分公司的员工并没有任何联系,这样设计显然是增加了不必要的耦合。

### 修改后的代码

按照迪米特法则,应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:

    class SubCompanyManager
    {
        public List<SubEmployee> getAllEmployee()
        {
            List<SubEmployee> list = new List<SubEmployee>();
            for (int i = 0; i < 100; i++)
            {
                SubEmployee emp = new SubEmployee();
                //为分公司人员按顺序分配一个ID
                emp.setId("分公司" + i);
                list.Add(emp);
            }
            return list;
        }
        public void printEmployee()
        {
            List<SubEmployee> list = this.getAllEmployee();
            foreach (SubEmployee e in list)
            {
                Debug.Log(e.getId());
            }
        }
    }

    class CompanyManager
    {
        public List<Employee> getAllEmployee()
        {
            List<Employee> list = new List<Employee>();
            for (int i = 0; i < 30; i++)
            {
                Employee emp = new Employee();
                //为总公司人员按顺序分配一个ID
                emp.setId("总公司" + i);
                list.Add(emp);
            }
            return list;
        }

        public void printAllEmployee(SubCompanyManager sub)
        {
            sub.printEmployee();
            List<Employee> list2 = this.getAllEmployee();
            foreach (Employee e in list2)
            {
                Debug.Log(e.getId());
            }
        }
    }

### 主要的变化

[![](https://images0.cnblogs.com/blog/363476/201502/121653292296877.png)](https://images0.cnblogs.com/blog/363476/201502/121653282293049.png)

修改后,为分公司增加了打印人员ID的方法,总公司直接调用来打印,从而避免了与分公司的员工发生耦合。

### 总结

迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。  
但是凡事都有度,虽然可以避免与非直接的类通信,但是要通信,必然会通过一个“中介”来发生联系,例如本例中,  
总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。  
过分的使用迪米特原则,会产生大量这样的中介和传递类,导致系统复杂度变大。  
所以在采用迪米特法则时要反复权衡,既做到结构清晰,又要高内聚低耦合。

 

原则6:开闭原则
---------------

### 定义

**一个软件实体如类、模块和函数应该对扩展开放,对修改关闭**

在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,  
可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试。  
因此,当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。  
闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统。开闭原则可能是设计模式六项原则中定义最模糊的一个了,

它只告诉我们对扩展开放,对修改关闭,可是到底如何才能做到对扩展开放,对修改关闭,并没有明确的告诉我们。  
以前,如果有人告诉我“你进行设计的时候一定要遵守开闭原则”,我会觉的他什么都没说,但貌似又什么都说了。因为开闭原则真的太虚了。  
在仔细思考以及仔细阅读很多设计模式的文章后,终于对开闭原则有了一点认识。  
其实,我们遵循设计模式前面5大原则,以及使用23种设计模式的目的就是遵循开闭原则。

### 如何遵守

也就是说,只要我们对前面5项原则遵守的好了,设计出的软件自然是符合开闭原则的,这个开闭原则更像是前面五项原则遵守程度的“平均得分”,  
前面5项原则遵守的好,平均分自然就高,说明软件设计开闭原则遵守的好;  
如果前面5项原则遵守的不好,则说明开闭原则遵守的不好。  
其实,开闭原则无非就是想表达这样一层意思:用抽象构建框架,用实现扩展细节。  
因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定。  
而软件中易变的细节,我们用从抽象派生的实现类来进行扩展,当软件需要发生变化时,我们只需要根据需求重新派生一个实现类来扩展就可以了。  
当然前提是我们的抽象要合理,要对需求的变更有前瞻性和预见性才行。

 

**如何去遵守这六个原则**
------------------------

对这六个原则的遵守并不是
**是和否**的问题,而是**多和少**的问题,也就是说,我们一般不会说有没有遵守,而是说遵守程度的多少。  
任何事都是过犹不及,设计模式的六个设计原则也是一样,制定这六个原则的目的并不是要我们刻板的遵守他们,而需要根据实际情况灵活运用。  
对他们的遵守程度只要在一个合理的范围内,就算是良好的设计。  
如果大家对这六项原则的理解跟我有所不同,欢迎指正![](http://www.unitymanual.com/static/image/smiley/default/20119000.gif)

### 说明

本文转载自并对其整理目录[:\[ζއ随风去旅行\] Unity3d
一个优秀的程序必备的几种设计模式](http://www.unitymanual.com/thread-22531-1-1.html)

奇怪的是,以前独立寨子边上、再平凡不过的榨油坊,近期大家想看一眼,居然要跑到文物苑里,或者是体育场馆里翻书过眼瘾。

本条才叫云谲波诡呢。

往常寨子里的小溪,隔着一段就会建筑一道小水坝,密度等同梯级。水坝引流的渠道,上游地区全都是用以水田灌溉和鱼塘,靠近寨子附近的,基本上都是用来榨油坊的水力。

渠道里的水冲到榨油坊,因为落差,水流万分匆忙,望着令人眩晕。冲击力万分可观,一路冲刷着水车,发出一阵阵拍击声。

水车转动,通过动力方向转换装置——请小心,那里跟小车传动轴道理一样,所以说,我们怎么就没研商出小车吗——推动槽沟里硕大的一块圆形巨石做成的巨轮,石轮一路碾过去,槽沟里的茶籽极度热闹的追赶,噼噼啪啪一路被碾碎。

那么些茶籽放进槽沟之前,还在蒸笼里分享一段时间水疗,为的是去掉水分。碾碎以后的茶籽,犹如煮籼米饭一般,在蒸锅中修炼,然后倒进一圈圈的铁箍里。

铁箍里还一不可多得加放糯玉蜀黍的禾秆,大致可以凝结茶籽粉末。使劲砸,把铁箍里的茶籽粉末砸成饼状,放进一个圆形的横放的木筒。木筒中间挖空,尺寸和铁箍相仿,刚好能放进茶饼。

成排的铁箍一头加塞,一根从梁上悬挂下来的缆索绑住的木料,也是横放,一头是一个圆形铁套紧箍,不停的叮叮当当捶打茶饼铁箍之间的盖子,声音响彻山谷。

那种节奏,浓郁着农村野味,犹如遥远的天籁。更加是加班加点的夜景,融合了无限的幽静,恍若世外之音。近日认知,遥远得好像隔世。

浓厚的茶籽油,就那样从木筒的一头悄悄流出来,起始是一滴一滴的,后来成线成流,最终又是一滴一滴,这意味哪个人家的茶籽油已经出锅啦!

原汁原味的茶籽油,没有丝毫废物,那种纯正和纯粹,李玄都自愧不如。

年年岁岁入冬以后,茶籽采集一过,榨油坊就日以继夜的动工。家家户户到那边点卯、挂号排队,轮到自家时,挑了茶籽就堆放在蒸笼里。

榨好之后,抬着油罐,还挑着团团的里边掺杂了糯谷禾秆的茶麸,春风得意的返乡。一家子一年的用油,就是那样规定了。

此前走亲戚,或者外地过来探亲准备重临的亲戚,拿出最好的礼金,基本上都是一瓶浓郁的茶籽油。家底的界别,只不过是瓶子容量大小之不一样而已。

很有可能,某有些一代,茶籽油依旧侗寨的硬通货,毕竟,那个大家都认,而且质量都好像。外出讨饭的时候,我们接受的布施紧如若三种,茶籽油和黑米,或者饭团。

有关茶籽油兼具流通作用,成为民间货币,这一块没有商讨过史料,只好留个念想,以备来日求证。

有关茶麸,这是上好的燃料,扔一块进土灶里,可以煮好一大锅猪食,就可见慰问猪圈里的兄弟姐妹——也有些住户养母猪的。

茶麸烧完将来变成炭,孩子们拿着火盆去高校,里边就是放的茶麸炭,发热持续时间格外可观。小火盆放在凳子上边烤,一个清晨的课,暖融融的很不难打瞌睡。

纵然如此可能会迎来老师的粉笔头,或者抓着耳朵扯到发红,如故没几个不带火盆的。不管怎样,都比冻着强很多。

不知底干什么,之前俺们学习都带火盆,如今的孩子完全不领会那是何许玩意儿,难不成这就是所谓的温室效应?

有一些无法忽视,现在的子女有丰饶棉鞋、跑鞋、衬衫,从前俺们全都是单层布的解放鞋或者千层底布鞋——不降雨的时候。

纵使没有温室效应,小火盆注定依旧要流失的,那只然则是阶段性的产物而已,完成职责,退出舞台。这是好事,孩子们不要再受冻。

茶籽油榨季截止未来,已经是新春了,随地桃红李太白、恍然大悟。那些季节,最美好的可是尽管到河里闹鱼。

闹鱼用的主要材料就是茶麸和雷王根,砸碎的茶麸跟雷王根一起离碎成粉状,团起来。到了上游,往水里一撒,立刻间,整段水道都是浑的。

鱼类晕过去,但没死,只分外麻醉,捡回家之后,放清水爱护,不一会又是精神。就如具有的子女都爱不释手抓鱼,大致那跟生命从水里爬上岸有关吗。

价值观压榨工艺产出的茶籽油,非凡尊重,纯正到没有简单杂味。

而是几人说,城里人不习惯这种味道,觉得多少涩。据说有些人还为此搞了茶籽油再加工,为的就是去掉那股纯正的茶籽味道。

假定您生平习惯吃梅菜扣肉,哪怕就是去了意大利共和国进了西餐馆,劈头盖脸嚷嚷,要服务生给您上水煮肉。

在您那是一种习惯使然,在服务生就觉得多少出乎预料,此人究竟是出去旅游的,仍然换一个地点享受他的水煮肉吗?

听讲很多人出国观光,都欢悦带着方便面,大约是国外的饭食不合他们的食量。假诺是这么,那就大大下跌旅游的童趣。

美食美景美丽的女生,这是自家直接为旅游业鼓吹的三美主义,真是缺一不可。缺了美食这一道,再怎么完美的旅程,说不出所以然来。

在这些含义上,传统压榨的茶籽油就是最正派的茶籽油味道。有人不习惯,甚至不爱好,那都很健康嘛。

为了迁就你的习惯,你要求橄榄油跟你家的菜籽油味道一致,那就不要买橄榄油,菜籽油多好啊!近日科技(science and technology)进步,地沟油完全能够迁就任何人的口感,想要什么味道就能弄出如何来。

那多少个出门不欣赏三美的人,指出她们关在家里泡方便面,顺便看旅游TV节目就可以啊,何必浪费那笔钱吗!

为了大力发展鄂温克族原生态旅游业,相信有一天,寨子里也会重建榨油坊,当作一个园中园的景象,可以独自卖票的。

正是令人鼓舞。

理所当然也令人寒心,因为,属于大家的榨油坊,再也不会现身。即使重建了一座又一座,那可是就是为着旅游门票罢了,跟我们的平常生活,居然隔了一山又一山。

只得比影片里的生存就算也是生活,可是,跟大家的柴米油盐酱醋茶,毕竟依然没有半毛钱关系。

现在寨子里也应运而生有的依赖电力系统的榨油坊,工艺跟传统的所有出入,利润几何,那就说不准了。不过,相信榨油依然一笔不错的生意。

有个小妹半辈子都做榨油坊,后来攒了一部分钱,于是就去做旅游。租了好大一片地,起名石门冲景区,劳累辗转,拼命坚定不移。

有一年春季,在石门冲水塘边的木屋里借住,一夜潺潺水声,送来好梦,感觉很有意思。几乎那跟二嫂更加酒坛子不非亲非故系。近期连年不去,也不知晓,她这边工作怎么了。听说近期已名声在外,真是百二秦关终属楚。

游览固然不是一个表演行业,只可是,很五人都把旅游作为演艺界对待。所以,你一点一滴弄不知情,横店影视城到底是一个游历景区呢,仍然一个粉丝找偶像讨签名的影片基地?

唯独,仍然盼望传统榨油坊的产出,最好横空出世。哪怕就是表演,至少也比一贯不的好。因为我们的满贯,迟早都会成为别人进账门票的演出。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图