软件架构设计原则

通常，我们在开发一个完成项目的时候，总会谈到要进行软件架构设计，那么为什么要进行软件架构设计呢，肯定是为了方便软件后期的维护性、扩展性和易读性。
软件开发设计有七大原则：

1. 开闭原则 有利于软件的稳定性和可维护性
2. 依赖倒置原则 减少类与类之间的依赖，高层模块与底层模块之间的依赖，实现与抽象
3. 单一职责原则 降低类的复杂度，提高代码的可读性和可维护性，降低变更引起的风险。一个类 、接口、 方法只负责一项职责。
4. 接口隔离原则 多个专门的接口，而不是使用单一的总接口，客户端不应该依赖它不需要的接口。
   1、一个类对一类的依赖应该建立在最小的接口之上；
   2、建立单一接口，不要建立庞大臃肿的接口；
   3、尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。
   复合高内聚低耦合的设计思想，从而使得类具有更好的可读性、可扩展性和可维护性。对业务模型的理解是非常重要的。
5. 里氏替换原则
   主要是指子类继承父类的时候，子类能够继承父类的非私有成员变量，也可以重新给父类的非私有成员变量赋值，从而替换父类的属性值。
   引申含义：子类可以扩展父类的功能，但不能改变父类原有的功能。
   1、子类可以实现父类的抽象功能，但不能覆盖父类的非抽象方法；
   2、子类中可以增加自己特有的方法；
   3、当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松；
   4、当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输
   出/返回值）要比父类更严格或相等。
   优点：1、约束继承泛滥，开闭原则的一种体现；
   2、加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的维护性、扩展性。降低
   需求变更时引入的风险。
6. 迪米特法则（最少知道原则）
   类和类之间尽量不要产生依赖关系，如果确实非要有依赖关系，要尽量保证他们的依赖最弱。
   比如如果非要有依赖的话，优先使用方法体内的成员变量，入参等关系，而不是方法体内部的类。
   一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的public方法，我就调用这么多，其他的一概不关心
7. 合成复用原则
   当有新的需求，需要创建新的对象时，尽量使用对象的组合/聚合来实现，而少用继承关系。尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。
   优点：可以使系统更加灵活，降低类与类之间的耦合。一个类的变化对其他类的影响较少。

设计代码架构时，能够根据实际情况灵活的选择适合自己的实际业务场景的原则，加以运用，达到未雨绸缪的效果，当有新需求时，可以很好的扩展。