面向对象的设计原则——模式工程化实例及拓展

Solid原则

1、单一职责原则（SRP）

　　Single Responsibility principle:  每个类应只有一个引起它变化的原因/每个类应只担任一个职责，以便于日后的程序的维护。

2、开闭原则（OCP） 

 　　一个软件实体应当对扩展开放，对修改关闭。 你添加新功能的时候应该只是向代码集中添加新的代码不应该修改原来的代码。

 

2、李氏替换原则（LSP） 和 迪米特法则（Lod：Law of Demter、LKP）

　　Liskov Substitution Principle：LSP原则要求子类可以无条件的替代父类，子类不能对父类没有暴露的接口进行扩展，客户要调用功能只能通过父类暴露的接口来调用用不能擅自向子类调用。

　　Lod：Law of Demter、LKP

　　‘Talk only to your immediate friends and not to strangers’ 

      一个软件实体应当尽可能少的与其他实体发生相互作用。 迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

       我们在运用里氏代换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。

3、接口隔离原则（ISP）

　　使用多个专门的接口比使用单一的总接口要好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上。

 

5. 依赖倒置原则（DIP）

dependence inversion principle：“高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。中心思想是面向接口编程”。

　　换句话说就是设计的时候我们要用抽象来思考，而不是一上来就开始划分我需要哪些哪些类，因为这些是具体。这样做有什么好处呢？人的思维本身实际上就是很抽象的，我们分析问题的时候不是一下子就考虑到细节，而是很抽象的将整个问题都构思出来，所以面向抽象设计是符合人的思维的。

 

 

其它原则

DRY原则： Don’t Repeat Yourself

KISS原则： Keep it Simple and Stupid

YAGNI原则：

YAGNI stands for "you aren't gonna need it": don't implement something until it is necessary.

Why
Any work that's only used for a feature that's needed tomorrow, means losing effort from features that need to be done for the current iteration.
对于以后才有用的需求,现在进行的一切工作,都意味着会失去对当前需要完成的需求的精力.
It leads to code bloat; the software becomes larger and more complicated.
否则,将会导致代码冗余,软件会变的更加庞大和复杂.
How
Always implement things when you actually need them, never when you just foresee that you need them.
通常当你,真正需要某个功能点的时候,你再去实现那个功能点,千万不能去实现那些你认为以后有可能会用的到的功能

 

设计原则与设计模式的关系

 设计原则是指导我们代码设计的经验总结，对于某些场景下，是否使用某种设计模式，具有指导意义。比如“开闭原则”是很多设计模式模式的指导原则（策略、模板等）

设计模式是针对软件开发中遇到的一些问题总结出来的一套具体的解决方案。 设计模式主要是提高代码的可扩展性，从抽象的角度来讲设计原则比设计模式更加抽象。设计模式则更加具体、更加可执行。