设计模式的六大基本原则

基本原则：

• 迪米特法则，最少知道原则

• 单一职责原则

• 开放-封闭原则  （构造抽象来隔离那些变化，对修改封闭，对扩展开放，加减乘除运算器）

• 依赖倒转原则 （抽象不应该依赖细节，细节应该依赖抽象，也就是针对接口编程，而不是针对实现编程，计算机主板接口）

• 里氏代换原则 （子类型必须能够替换掉他们的父来行 Animal a = new Cat()）

• 接口隔离原则

---

找IT部比找具体的某个人要好

不管公司和人，找IT部就可以了，不管认不认识人，反正他们会想办法找人来解决。

IT部代表是抽象类或接口，小张小李代表是具体的类。

---

单一职责原则

就一个类而言，应当 仅有一个引起他变化的原因。我们在做编程的时候，很自然的就会给一个类各种各样的功能，比如我们写一个窗体应用程序，一般都会生成Form1这样的类，于是我们就把各种各样的代码，像某种商运算的算法呀，像数据库访问的SQL语句呀什么的都写在这样的类里面，这就意味着，无论任何需求要来，你都要更改这个窗体类，这其实是很糟糕的，维护麻烦，复用不可能，也缺乏灵活性。

单一职责原则：就一个类而言，应该仅有一个引起他变化的原因

软件设计真正要做的许多内容，就是发现职责并把那些职责互相分离，其实要去判断是否应该分离出类来，也不难，那就是如果你能够想到多于一个的动机去改变一个类，那么这个类就真是多余一个的职责，就应该考虑类的职责分离。

游戏中界面的变化和游戏本身没有关系的，界面是容易变化的，而游戏逻辑是不太容易变化的，将他们分离有利于界面的改动。

---

开放封闭原则

构造抽象来隔离那些变化

---

依赖倒转原则

子类继承了父类，所以子类可以以父类的身份出现。

李氏替换原则，实现多态，正是有了里氏替换原则，才使得开放-封闭成为可能，由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展，

高层模块不应该依赖底层模块，两个都应该依赖抽象

依赖倒转其实就是谁也不依赖谁，除了约定的接口，大家都可以灵活自如。

收音机就是典型的耦合过渡，只要收音机出故障，不管是没有声音、不能调频，还是有杂音，反正都很难维修，不懂的人根本没法修，因为任何问题都可能设计其他部件，各个部件互相依赖、难以维护。

依赖倒转其实可以说是面向对象设计的标志，用那种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中的所有依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之是过程化的设计。