设计模式与设计原则

设计原则

如果把设计模式理解为优秀软件系统模块设计的最小抽象，那么设计原则就是这些抽象的指导思想。目的是设计一个易于扩展和维护的系统。设计模式的六大原则有：

• Single Responsibility Principle：单一职责原则
• Open Closed Principle：开闭原则
• Liskov Substitution Principle：里氏替换原则
• Law of Demeter：迪米特法则
• Interface Segregation Principle：接口隔离原则
• Dependence Inversion Principle：依赖倒置原则

单一职责原则

应该有且只有一个原因引起类的变化，一个类只负责一个职责。一个功能应该要划分成多少个职责类去实现，并没有明显的限定。举例说明对于用户管理，用户信息管理和用户行为管理可以做初步拆分，用户信息管理又可以拆分成普通信息维护和敏感信息的维护。又比如用户发生一笔支付行为可以初步拆分为交易信息管理和支付信息管理。职责划分的粗细的影响因素有对于业务理解程度、项目开发阶段等，过粗会造成一个处理类包含太多职责，过细又会增加开发维护成本。单一职责是“高内聚低耦合”设计的一种实现形式，单一职责即为同一职责内部的内聚性，降低不同职责之间的耦合性。

里氏替换原则

描述继承关系，子类全部实现或继承父类方法，子类可以扩展父类方法实现，将子类替换父类不会产生异常。在重构角度来说如果多个子类拥有相同的行为，可以将相同行为提取到父类实现，子类调用扩展父类实现。在开发上基于“组合大于继承”的原则，通过定义实现接口的形成被其它类调用。违反这个原则不一定会产生严重后果，但是会对后面的开发维护造成困难。

开闭原则

描述的是对于需求产生变化后，软件实体部分应该进行扩展开发，避免修改。通过扩展实体行为来响应需求变化，而不是通过修改现有软件代码。

迪米特法则

描述的是一个对象应该进行减少对于其它对象的理解。通过封装我们可以屏蔽类内部逻辑，只提供足够用且少量的方法来给外部使用，降低对象之间的耦合性。当一个接口或者一个对象被公开，意味着后面我们进行开发和维护的时候很难再将这个对象收回，重构内部逻辑时也会更加困难。

接口隔离原则

描述的是建立单一的接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量行为统一，避免臃肿。对于支付接口来说，定义类通用支付方法，对于获取分期支付信息也属于支付行为的一个环节，但不是所有实体类必须要实现的，可以拆分出来。

依赖倒置原则

描述的是实现类之间不能直接发生依赖关系，其依赖关系是通过接口或者抽象类产生，即面向接口编程。实现类依赖接口或者抽象类，而接口或者抽象类不依赖实现类。

设计模式

https://design-patterns.readthedocs.io/zh_CN/latest/index.html