JAVA的23种设计模式---前置：6大基本原则

概要：

该文章参考了《设计模式之禅》一书、百度百科及一些前辈的博客文章

1.该文章阐述了JAVA的6大基本原则；
2.该文章适合初学设计模式的技术人员研习；
3.该文章有许多不足之处，请各位大咖指正，喷子绕道；

正文：

在阐述6大基本原则之前，先说说“高内聚，低耦合”

耦合性：也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息
内聚性：又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。

高内聚：是指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。提高接口、类、模块的处理能力。
重点内容
低耦合：一个完整的系统，模块与模块之间，尽可能的使其独立存在。也就是说，让每个模块，尽可能的独立完成某个特定的子功能。模块与模块之间的接口，尽量的少而简单。如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分。这样有利于修改和组合。

1.开闭原则（OCP原则）：软件实体应对扩展开放，对修改关闭，考虑到所有可能变化的因素，留下接口，等待“可能”变为“现实”

优点：    a：可以提高复用性    b：可以提高可维护性    c：面向对象开发要求实现：    a：抽象约束：        第一，接口或抽象类对扩展进行边界约束，不允许出现接口和抽象类中不存在的public方法        第二，参数类型，引用对象尽量使用抽象类或者接口，而不是实现类        第三，抽象层尽量保持稳定，一旦确定即不允许修改    b：元数据（用来描述环境或数据的数据，配置参数）控制模块行为：        例如spring等各种框架    c：制定项目章程        类似团队开发中约定俗成的各类规范    d：封装变化        第一，相同的变化封装到一个接口或者抽象类中        第二，不相同的变化封装到不同的接口或者抽象类中        找出有变化或者不稳定的点，为这些变化创建稳定的接口，封装可能发生的变化。

2.单一职责原则（SRP原则）：应该有且仅有一个原因引起类的变更。类和接口职责单一，注重职责。

优点：    a：类的复杂性降低，实现哪个职责有清晰明确的定义    b：可读性提高    c：可维护性、扩展性提高    d：变更引起风险降低要求：接口一定要做到单一职责原则，类的设计尽量做到只有一个原因引起变化。

3.里氏替换原则（LSP原则）：只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何异常，但有子类出现的地方，父类就不一定合适。

    a：子类必须完全实现父类的方法    b：子类可以有自己的个性    c：重载或实现父类的方法时输入参数可以被放大    d：重写或实现父类的方法时输出结果可以被缩小

4.依赖倒置原则（DIP原则）：对抽象进行编程，不要对实现进行编程

    a：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。    b：接口或抽象类不依赖于实现类    c：实现类依赖于接口或抽象类作用：减少类间耦合性，降低并行开发风险

5.接口隔离原则（ISP原则）：建立单一接口，接口尽量细化，接口的方法尽量少

接口是我们设计时对外提供的契约，通过分散定义多个接口，可预防未来变更的扩散，提高系统灵活性及可维护性。    a：接口尽量要小    b：接口要高内聚    c：系统或模块间的接口采用定制服务    d：接口设计有限度

6.迪米特法则（LoD法则）也称最少知识原则（LKP原则）：一个对象应当对其他对象有尽可能少的了解

    a：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中    b：类间解耦