单一职责：1， 任何一个软件模块都应该只有对某一类行为者负责；类，模块。
2.模块，类，函数也是；降低调用者的耦合。 1，过多属性和方法，依赖他的类比较多，他依赖的类比较多。
名字笼统，不细致；过半的方法都是集中操作某几个属性，那么可以拆分成一个单独的类。部分概念被复用。从行为者（使用者）角度来指导设计的。
开放封闭:1. 模块，类，方法 应该对扩展开放，对修改关闭
新增方法，类，方法，
对老用户影响：1 重新编译 2. 被迫对其修改 3. 被迫重新测试（用例）
1 设计出可扩展性更好的架构，从而降低消除高层组件对底层组件的依赖。
可扩展性：衡量架构设计质量的重要维度。对扩展开放，为了低沉本的应对需求变化。
保证现有代码的稳定性，对修改关闭。
1， 熟悉业务。2. 熟悉设计模式‘’ 3 分离关注点：基于接口或者抽象实现封闭，基于实现接口或者继承实现开放。
里shi替换：1. 子类对象能够替代程序中，任何地方出现的父类对象
逻辑行为不变。
替换后，没有改变原来程序的逻辑行为和约束：
1. 功能约定 2.输入约定 3 输出约定 4，在父类注释下提到的其他约束
改变函数的实现；错误返回值变了；违背父类注释的说明
接口隔离：用户不应该被迫依赖他不需要的接口
API接口，类，模块。降低多个调用者之间的耦合。
1 被迫重新编译 2. 被迫对齐修改 3. 被迫重新测试
单一职责在接口的应用；接口隔离：降低依赖度，更好的耦合
1，单一职责：模块，类，函数，从自身设计出发，不要设计大而复杂的接口，保证高内聚。
2. 接口隔离： 从接口的用户出发，避免用户依赖他不需要的逻辑，强调解耦
物理拆分：多个接口；不拆分：适配器模式来提供适配接口
facade模式封装给用户。
接口粒度取决于调用者的需求和内聚性概念；一个用户最棒了，不用接口隔离。
1 考虑从各个用户的需求触发，也要从接口逻辑的内聚性出发。
依赖倒置: 1, 高层是调用者 2， 被调用者为底层。
抽象：现在概念背后的本质，细节是挡墙用到的现实概念。
抽象:用接口 抽象类来代替； 细节：具体类或者实现来代替。
细节依赖抽象，抽象不依赖细节。
高层模块（类）不应该依赖于底层模块（类），二者都依赖于抽象。
1. 保持核心逻辑核心稳定：高层为业务策略层，底层为实现层，高层变动比底层多。不期待频繁的变化影响底层实现。
低层：技术变型，外部依赖等。低层的变动不影响高层业务逻辑。
依赖：代码依赖方向和程序控制流方向一致，就是正常依赖
核心逻辑：分离关注点。
1 在代码中多使用抽象接口，避免使用多变的具体实现类
2 任何变量不该指向一个具体类
3 任何类不应该继承具体类
4 任何方法都不应该改写父类中已经实现的方法
标准库中的类相对是稳定的，string vector等，可以直接依赖。
业务的实现需要具体类。判断标准：依赖的对象是否稳定。
网友评论