聚合Aggregation - A包含B,B的生命周期不依赖A public A(B b) { this.b = b; }
组合Composition - A包含B,B的生命周期依赖A public A() { this.b = new B(); }
关联Association - 非常弱的关系,包含聚合和组合
依赖Dependency - 是一种比关联关系更加弱的关系,包含关联关系。不管是 B 类对象是 A 类对象的成员变量,还是 A 类的方法使用 B 类对象作为参数或者返回值、局部变量,只要 B 类对象和 A 类对象有任何使用关系,我们都称它们有依赖关系。
设计原则理论 SOLID
- **单一职责原则SRP**
- A class or module should have a single reponsibility。
- 将两个不相干的功能放到同一个类中,那就违反了单一职责原则
- 根据业务需求判断是否拆分,有几个不成文的经验:
- 类中代码行数,函数属性过多
- 类依赖其他类过多
- 类的私有方法过多
- 类起名字时比较难起一个合适的名字
- 类中大量的方法都是集中操作类中的某几个属性
- 有些场景不适合拆的太细,要考虑高内聚,比如Serializer类
- **开闭原则Open Closed Principle**
- 怎么判断修改的代码是扩展还是修改?
- software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。我们把它翻译成中文就是:软件实体(模块、类、方法等)应该“对扩展开放、对修改关闭”,增加新功能是尽量新增模块、类、方法代码,不要再原有代码基础上修改。
- 大前提只要没有破坏原有代码和测试用例的运行就是合理的修改扩展。
- 对于一些判断聚合类的修改思路:把参数封装成类,判断用handle类代替,这样新增功能是只用改参数类和新增handle类就可以了。
- 为了尽量写出扩展性好的代码,我们要时刻具备扩展意识、抽象意识、封装意识。这些“潜意识”可能比任何开发技巧都重要。
- 写代码前先思考怎么设计代码结构,事先预留好扩展点。
- 最常用来提高代码扩展性的方法有:多态、依赖注入、基于接口而非实现编程,以及大部分的设计模式(比如,装饰、策略、模板、职责链、状态等)。
- 也不要过度设计,对于短期内的变动设计扩展点是用到就ok了,另外如果ifelse不太多也不建议用策略模式增加代码的可读性难度。
- **里氏替换LSP**
- Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it / 子类对象(object of subtype/derived class)能够替换程序(program)中父类对象(object of base/parent class)出现的任何地方,并且保证原来程序的逻辑行为(behavior)不变及正确性不被破坏。
- 多态是一种语法,LSP是指导子类如何设计不会影响到父类的逻辑行为。
- 拿父类的测试用例去跑子类的方法如果报错就违背了LSP原则。
- “design by contract,按照协议来设计”
- **接口隔离原则Interface Segregation Principle**
- “Clients should not be forced to depend upon interfaces that they do not use。”客户端不应该被强迫依赖它不需要的接口
- 部分接口只提供给部分调用者使用就要拆分开,单独提供服务,其他调用者不用强制依赖不需要的接口。
- 单个api的函数接口层面,如果调用者只用到了接口中部分功能,那这个接口就违背了ISP,这也是和SRP的最大区别,SRP关注模块类接口设计,ISP只关注接口设计。
- **依赖反转原则Dependency Inversion Principle**
- DI 将所依赖的类对象通过构造函数传递进来
- 控制反转 流程的控制权从程序员“反转”到了框架
- 高层模块不依赖低层模块,它们共同依赖同一个抽象。抽象不要依赖具体实现细节,具体实现细节依赖抽象。
- **KISS和YAGNI You Ain’t Gonna Need It原则**
- Keep It Simple and Straightforward.尽量保持简单
- 保持可读可维护。优化投入产出比,逻辑复杂度,实现难度。系统性能瓶颈代码,核心功能要用复杂的方法。
- 不要使用同事不懂的技术,不要重复造轮子,不要过度优化。
- code review 评判代码是否简单。
- YAGNI不要提前引入不需要的依赖包,kiss如何做,yagni要不要做。
- **DRY Don't Repeat Yourself 不要重复自己**
- 实现逻辑重复,只要不违背语义重复,不要合并
- 功能语义重复,合并
- 代码执行重复,尽量减少IO执行。
- 代码复用性,代码复用,DRY。
- 提高复用性方法:
- 减少代码耦合
- 满足单一职责原则
- 模块化
- 业务与非业务逻辑分离
- 通用代码下沉
- 继承、多态、抽象、封装
- 应用模板等设计模式
- 泛型编程,复用意识
- **迪米特法则LODLaw of Demeter最小知识法则,实现高内聚、松耦合**
- 高内聚:相近的功能放到同一个类中。
- 松耦合:类与类之间的依赖关系简单清晰。
- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.每个模块(unit)只应该了解那些与它关系密切的模块(units: only units “closely” related to the current unit)的有限知识(knowledge)。或者说,每个模块只和自己的朋友“说话”(talk),不和陌生人“说话”(talk)。
- 不该有直接依赖关系的类之间,不要有依赖;减少依赖,使用工厂模式创建对象。
- 有依赖关系的类之间,尽量只依赖必要的接口(也就是定义中的“有限知识”)。拆分多个功能单一的接口。
- 基于最小接口而非最大实现编程