整理在设计架构时注意的六大原则

设计模式是为了让平台具有更好的优点：

1、代码可重用性(比如：相同功能的代码，不用多次编写)。
2、可读性(比如：编程规范性，便于其他程序员的阅读和理解)
3、可扩展性(比如：当需要增加新的功能时，非常的方便，称为可维护。
4、可靠性(比如：当我们增加新的功能后，对原来的功能没有影响)。
5、使程序呈现高内聚,低耦合的特性。

一、单一职责原则：
　　对象不应承担太多功能，正如一心不能而用，比如太多的工作(种类)会使人崩溃。唯有专注才能保证对象的高内聚；唯有唯一，才能保证对象的细粒度。一个类只负责一件事，面向对象语言开发，类是一个基本单位，单一职责原则就是封装的粒度。

解决问题：

　　假如有A和B两个类，当A需求发生改变需要修改时、更好的可以维护A的功能，，不能导致B类出问题。

二、接口隔离原则：
　　1、客户端不应依赖它不需要的接口

　　2、类间的依赖关系应该建立在最小的接口上

　　其实通俗来理解就是，不要在一个接口里面放很多的方法，这样会显得这个类很臃肿。接口应该尽量细化，一个接口对应一个功能模块，同时接口里面的方法应该尽可能的少，使接口更加灵活轻便。或许有的人认为接口隔离原则和单一职责原则很像，但两个原则还是存在着明显的区别。单一职责原则是在业务逻辑上的划分，注重的是职责。接口隔离原则是基于接口设计考虑

三、依赖倒置原则
其指出了一种特点的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。
几个关键点：
（1）高层模块不应该依赖底层模块，两者都应该依赖其抽象。
（2）抽象不依赖于细节。
（3）细节应该依赖抽象 

四、里氏替换原则：
　　子类应当可以替换父类并出现在父类能够出现的地方。

　　里氏替换至少包含一下两个含义：

　　　1、里氏替换原则是针对继承而言的，如果继承是为了实现代码重用，也就是为了共享方法，那么共享的父类方法就应该保持不变，不能被子类重新定义。子类只能通过新添加方法来扩展功能，父类和子类都可以实例化，而子类继承的方法和父类是一样的，父类调用方法的地方，子类也可以调用同一个继承得来的，逻辑和父类一致的方法，这时用子类对象将父类对象替换掉时，当然逻辑一致，相安无事。

　　　2、如果继承的目的是为了多态，而多态的前提就是子类覆盖并重新定义父类的方法，为了符合LSP，我们应该将父类定义为抽象类，并定义抽象方法，让子类重新定义这些方法，当父类是抽象类时，父类就是不能实例化，所以也不存在可实例化的父类对象在程序里。也就不存在子类替换父类实例（根本不存在父类实例了）时逻辑不一致的可能

五、 迪米特法则(LOD)：
　　也叫最少知识原则。迪米特法则的定义是只与你的直接朋友交谈，不与"陌生人"说话。如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该应用。其目的是降低类之间的耦合度，提高模块的相对独立性。

　　迪米特法则中的朋友是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

优点：　　

      1、降低类之间的耦合度，提高模块的相对独立性。
      2、由于亲和度降低，从而提高了类的可复用率和系统的扩展性。

缺点：

　　过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

使用迪米特法则需要注意：

      1、在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
　　2、在类的结构设计上，尽量降低类成员的访问权限。
　　3、在类的设计上，优先考虑将一个类设置成不变类。
　　4、在对其他类的引用上，将引用其他对象的次数降到最低。
　　5、不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
　　6、谨慎使用序列化（Serializable）功能。　　

六、开闭原则：
　软件对象（类、模块、方法等）应该对于扩展是开放的，对修改是关闭的。比如：一个网络模块，原来只有服务端功能，而现在要加入客户端功能，那么应当在不用修改服务端功能代码的前提下，就能够增加客户端功能的实现代码，这要求在设计之初，就应当将客户端和服务端分开。公共部分抽象出来。