嗯哼？其实对于这7大原则我也一脸懵，设计模式基本上就是在这几个原则里面做选择，一种模式可能很好的满足了一种原则，但对于其他原则可能就不能很好的满足。背下来，老师如是说。恩，，感觉在设计类的时候会下意识往这上面想，怎么设计父类？接口还是抽象类？是包含引用还是依赖关系？还是比较有趣的，在几种选择里面做平衡。
一、开放-封闭原则【Open-Closed Principle】
【介个小哥哥是设计模式第一大原则，老师问的时候还一脸懵】
1》内容：
一个软件实体应当对扩展开放，对修改关闭。
【说人话：面对需求，对程序的改动是通过增加新的代码进行的，而不是更改现有代码。】
2》关键：
1> 合理地抽象、分离出变化与不变化的部分，为变化的部分预留下可扩展的方式。例如：钩子方法或是动态组合对象等。
PS:【钩子方法:是对于抽象方法或者接口中定义的方法的一个空实现】
2> 要完全遵守开闭原则是不可能的，也没这个必要。适当的抽象可以提高系统的灵活性、使其可扩展、可维护；过度抽象，会大大增加系统的复杂程度。
二、单一职责原则【Single Responsibility Principle】
1》内容：
就一个类而言，应该仅有一个引起它变化的原因（职责）。
【说人话：一个类就一个功能，不承担太多的责任，到时候哪儿有bug，好改】
2》难点：
如何区分职责、职责的粒度问题。
三、里氏代换原则【Liskov Substitution Principle】
1》内容：
子类型(subtype)必须能够替换它们的基（父）类型。（子类可以以父类的身份出现）。
【说人话：父类有的属性，功能，方法，子类必须都有。即抽象的时候要合理，别把子类没有的功能弄到他们的父类中去】
2》作用：
使开放封闭成为可能。
【why?要是抽象这一块做的不好，以后修改代码时就不只增加子类，还要修改父类的抽象，又会影响到原来就存在的子类】
四、依赖倒转原则【Dependence Inversion Principle】
1》内容：
要依赖于抽象，不要依赖于具体。
【说人话：编程时，要看向父类，跟着父类制定的规则走，跟着接口走，而不是只想着这一个类的功能实现】
2》常见错误：
1> 层次化调用的时候，应该是高层调用“底层所拥有的接口”，这是一典型的误解。
一般高层包含对业务功能的处理和业务策略选择，应该被重用，是高层模块去影响底层的具体实现。
底层的接口应该是由高层提出的，然后由底层实现，即底层的接口的所有权在高层模块，是一种所有权的倒置。
3》如何使用：
1>每个类尽量都有接口或抽象类
2>变量的表面类型尽量是接口或者是抽象类
3>任何类都不应该从具体类派生
4>结合里氏代换原则使用
五、合成/聚合复用原则
1》内容：
要尽量使用合成/聚合，而不是继承关系达到复用的目的。
【说人话：想拥有一个类或者一个接口的所拥有的功能时，尽量不要使用继承这种耦合度高的方式，尽量使用引用、或者包含一个实例化的对象】
六、接口隔离原则
1》内容：
使用多个专门的接口比使用单一的总接口要好。
换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。
2》实现方法：
使用多重继承分离接口
七、迪米特法则
1》内容：
最少知识原则。
【如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用】
【一个软件实体应当尽可能少的与其他实体发生相互作用】
1136
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
