记录个人学习、感悟、吐槽为什么需要软件架构设计原则为了不让自己的成果被别人骂成狗屎山，工作中经常被分配写一个功能模块（扩展、维护），可能是基础功能模块（消息联系、文件生成），以及业务模块，如：SSO、产品管理、订单管理、促销管理等。当第一期产品愉快完成后，并且一切都完美上线，产品会针对四期和五期的需求提出较大的修改，目前的代码设计很难从容的完成需求。给定的时间不足以完成重构，只能通过兼容实现需求。渐渐地，这个项目变成了一堆狗屎。自己维护很痛苦，别人维护更痛苦。如果在项目之初，在架构设计中就考虑到软件的健壮性、可读性、灵活性、易扩展性、易复用性、易用性等……那将是一件多么美妙的事情。软件设计原则原则1开闭原则（Open-ClosedPrinciple）对扩展开放，对修改关闭。该原则强调使用抽象来构建框架和实现扩展细节，可以提高系统的可重用性和可维护性。开闭原则是面向对象设计最基本的设计原则。它指导我们如何构建稳定灵活的系统，包含在版本更新中。我们尽量不修改源码来实现功能。在开发会员系统时，需要根据会员级别提供不同的权限。使用这种思路会使功能扩展变得非常清晰和容易。eg：base->level1extendslevel1->level2extendslevel1原则2依赖倒置原则（DependenceIversionPrinciple）高层模块不依赖低层模块，两者都依赖于它们的抽象。抽象不应该依赖于细节，细节应该依赖于抽象。通过依赖倒置，可以降低类之间的耦合度，提高系统的稳定性，提高代码的可读性和可维护性，降低修改程序带来的风险。依赖倒置原则（InversionofControl）是spring框架的基本思想原则。三单一责任原则（SimpleResponsibilityPrinciple）类变更的原因不超过一个。该原则的主要目的是为了解耦。假设我们有一个类负责两个职责。如果发生单个变更，一个职责在修改期间的逻辑实现代码可能会导致另一个职责的功能出现故障。在设计之初，需要考虑某个类的职责。这样的设计可以降低类的复杂度，提高类的可读性，功能的可维护性，降低变更带来的风险。例如：消息联系人中的消息推送，推送到小米手机，推送到华为手机。IA,IB,AbsPush>MiPushextendAbsPushimpIA,HuaWeiPushextendAbsPushimpIA,IB原则四接口隔离原则（InterfaceSegregationPrinciple）多个单一职责接口，不要使用一个通用接口客户端应该依赖它做的接口notneed，这个原则指导我们在设计接口时要注意以下几点：一个类对另一个类的依赖应该建立在最小接口的基础上建立单一接口，不要创建过于臃肿的接口。它应该尽可能少（而不是尽可能少）。从JAVA提供的List和Map接口可以窥见这种设计思路。原则5Demeter原则（LawofDemeterLoD）一个对象应该保持对其他对象的最少了解，降低类之间的耦合度。得墨忒尔原则主要强调：只与朋友交流，不与陌生人交流。出现在成员变量、方法输入输出参数中的类都可以是成员友元类，而出现在方法体中的类则不属于友元类。当a通过b获取到c的信息时，a在代码中不应该与c关联。原则6里氏替换原则（LiskovSubstitutionPrinciple，LSP）如果每个T1类型的对象O1都有一个T2类型的对象O2，使得T1定义的所有程序P都被O2替换，当所有对象O1都被替换时，程序P的行为有未更改，则T2是T1的子类型。这个定义是抽象的。只是看起来非常简洁易懂，但是理解需要深度。学习如下。可以这样理解，如果一个软件实体适用于父类，则必须使用其子类。所有对父类的引用都必须透明地使用其子类对象。子类对象可以替换父类对象，程序逻辑不变。按照这种理解，扩展的意思就是：子类可以扩展父类的功能，但不能改变父类原有的功能。子类可以实现父类的抽象方法，但不能重写父类的非抽象方法。子类可以添加自己独特的方法。输入参数）比父类的输入参数更宽松。严格类或类同原则七复合重用原则（Composite/AggregateReusePrinciple，CARP）复合重用原则是利用对象组合（has-a）/聚合（containis-a）而不是继承关系来实现软件重用。目的可以是系统更加灵活，类之间的耦合度降低，一个类的改变对其他类的影响相对较小。本文主要知识来自谭永德《Spring 5 核心原理》
