总结经验

近期自学Unity引擎，学到了关于设计模式这一块，以前学习Java多次接触设计模式，也在应用的开发过程中频繁使用。虽然开发过程中没有特意去强调使用设计模式，但设计模式的使用总是潜移默化的，现在回头再复习下设计模式具体实现，才发现自己在开发过程中自然而然的就运用到了。总之做任何事都是靠经验积累的，设计模式的出现也是靠实践总结出来的，虽然是做游戏开发，但逻辑依旧是相同的，看了几篇Blog觉得受益匪浅，在这里总结下再次学习的感悟。

接口隔离原则总结：

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

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

依赖倒置原则的核心思想是面向接口编程，我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。
场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了。代码如下：

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();
                Debug.Log(mother.narrate(new Book()));
        }
}

运行结果：
妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
运行良好，假如有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事，报纸的代码如下：

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

这位母亲却办不到，因为她居然不会读报纸上的故事，这太荒唐了，只是将书换成报纸，居然必须要修改Mother才能读。
假如以后需求换成杂志呢？换成网页呢？
还要不断地修改Mother，这显然不是好的设计。
原因就是Mother与Book之间的耦合性太高了，必须降低他们之间的耦合度才行。
我们引入一个抽象的接口IReader。
读物，只要是带字的都属于读物：

interface IReader{
        public String getContent();
}

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

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();
                Debug.Log(mother.narrate(new Book()));
                Debug.Log(mother.narrate(new Newspaper()));
        }
}

运行结果：
妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
妈妈开始讲故事
林书豪17+9助尼克斯击败老鹰……
这样修改后，无论以后怎样扩展Client类，都不需要再修改Mother类了。
这只是一个简单的例子，实际情况中，代表高层模块的Mother类将负责完成主要的业务逻辑，一旦需要对它进行修改，引入错误的风险极大。
所以遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。

采用依赖倒置原则给多人并行开发带来了极大的便利，
比如上例中，原本Mother类与Book类直接耦合时，Mother类必须等Book类编码完成后才可以进行编码，因为Mother类依赖于Book类。
修改后的程序则可以同时开工，互不影响，因为Mother与Book类一点关系也没有。
参与协作开发的人越多、项目越庞大，采用依赖导致原则的意义就越重大。
现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。
在实际编程中，我们一般需要做到如下3点：
1.低层模块尽量都要有抽象类或接口，或者两者都有。
2.变量的声明类型尽量是抽象类或接口。使用继承时遵循里氏替换原则。
3.依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。

声明

欢迎转载，但请保留文章原始出处
作者：Jaiky_杰哥
出处：http://blog.csdn.net/jaikydota163/article/details/52768634

设计模式个人总结，依赖倒置原则总结

总结经验

声明

猜你喜欢