设计模式六大原则整理

设计模式六大原则

设计模式的六大原则是很多互联网公司倾向问的问题，真能够考察你在实际的项目中是否真的考虑到设计问题。例如：京东面试就经常问。

有助于记忆： 一个单身（单一职责）的里氏（里氏替换原则）拿着一把颠倒（依赖倒置）的半开半闭（开闭原则）的扇子，在看接口分离（接口分离）问题，旁边还有一个米老鼠（迪米特）。

• 总原则：开闭原则，对扩展开放，对修改关闭。在进行功能扩展时不能修改原有代码。

该原则是所有程序员写程序时首先应该考虑的，只有这样在增加新功能时才能更高效。举个简单例子：两个节点一组翻转问题，在实现的时候可以实现为N个链表节点翻转，这样以后再出现三个一组、四个一组时都不要修改代码。

• 单一职责原则：每个类应该实现单一的职责。当需要扩展类的职责时，可以采用将类拆分为两个类、修改方法代码和增加方法的方式进行实现。

单一职责与进行函数设计时思想类型，我们在设计函数时尽量保证函数功能最少，避免一个main函数实现所有功能。这样做的好处是方便测试，出现问题可以快速定位修改，避免对不相关代码的干扰。

• 立氏替换原则：子类对父类的方法尽量不要重写和重载。子类可以实现父类的抽象方法但是不能覆盖父类的非抽象方法；子类中可以加入自己特有的方法；子类重载父类方法时，方法的形参要比父类的宽松；子类实现父类方法时方法的后置条件要比父类更严格。

其实在实际实现时，这个原则经常被打破，例如多态机制就需要重写父类的方法。但是其他情况还是要尽可能保持这个原则。

• 依赖倒转原则：相对于细节的多变性，抽象的东西要稳定的多，抽象不应该依赖细节，细节应该依赖抽象。传递依赖关系有三种方式：接口传递、构造方法传递和setter方法传递。

这个是面向对象设计中很关键的一个原则，例如我们使用的抽象类和接口。

• 接口隔离原则：客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。建立单一接口不要建立庞大接口，尽量细化接口，接口中的方法尽量少。

这个原则可以避免不必要的接口实现，但是在实际设计时要综合权衡，也不能一个函数一个接口，这样会导致接口泛滥，应该合理设计。

• 迪米特法则（最少知道原则）：一个对象应该对其他对象保持最少的了解。对于被依赖类尽量将逻辑封装在类的内部，对外除了提供public方法外不泄露任何信息。

这个原则是封装的体现，在设计的时候需要尽量保证高内聚、低耦合。