OO Software Development Principle
2023-09-01 09:17:16 0 举报AI智能生成
OO Software Development Principle
作者其他创作
大纲/内容
面向对象
概念
面向对象分析
面向对象设计
面向对象编程
四大特性
封装(Encapsulation)
例子
目的
提高代码可读性，可维护性
提高易用性
抽象(Abstraction)<br>
例子
目的
培养抽象思维，过滤非必要信息
关注功能点，而非实现
继承(Inheritance)
例子
目的
表示类之间的 <b>is-a</b> 关系, 反应真实世界中的这种关系
解决代码复用
设计结构美感
注意
尽量多用组合，少用继承
避免继承层次过深
修改父类可能会影响到子类
多态(polymorphism)
例子
继承 & 重写
接口类
duck-typing
目的
提高可扩展性与复用性
问题
滥用 getter / setter 方法
滥用全局变量和全局方法
定义数据和方法分离的类(基于贫血模型的开发模式)
设计原则
SOLID
单一职责原则(SRP)
类中的代码行数、函数或属性过多，影响代码可读性和可维护性
类依赖的其他类过多，或依赖类的其他类过多，不符合高内聚、低耦合的设计思想
比较难给类起合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，说明类职责定义不够清晰
私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性
类中大量的方法都是集中操作类中的某几个属性，那就可以考虑将这几个属性和对应的方法拆分出来
为了满足单一职责原则，是不是把类拆得越细就越好呢？答案是否定的
开闭原则(OCP)
预留扩展点
代码的扩展性会跟可读性相冲突
里式替换原则(LSP)<br>
<span style="font-weight: normal;"><font color="#d32f2f">关键点</font>：design by contract -按照协议来设计</span>
子类<font color="#d32f2f" style="">不能</font>违背父类声明要实现的功能<br>
子类<font color="#d32f2f">不能</font>违背父类对输入、输出、异常的约定
子类<font color="#d32f2f">不能</font>违背父类注释中所罗列的任何特殊说明
接口隔离原则(ISP)
<font color="#d32f2f">若为一组接口的集合时</font>，如果其中部分接口只被部分调用者使用，则需要将这部分接口隔离出来，供单独使用，不强迫调用者依赖用不到的接口
<font color="#d32f2f">若为单个接口/函数时</font>，如果部分调用者仅使用其中部分功能，则需将接口/函数拆分成更细粒度的多个接口/函数，供单独调用所需
<font color="#d32f2f">若为OOP中的接口时</font>，接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数
依赖反转原则(DIP)
控制反转(IOC)
依赖注入(DI)
依赖注入框架(DI Framework)
KISS
<font color="#d32f2f">不要</font>使用同事可能不懂的技术来实现代码
<font color="#d32f2f">不要</font>重复造轮子，善于使用已经有的工具类库
<font color="#d32f2f">不要</font>过度优化
YAGNI<br>
<font color="#d32f2f">不要</font>过度设计
<font color="#d32f2f" style="">并不是说不需要</font>考虑代码的扩展性
DRY
常见重复
实现逻辑重复
功能语义重复
执行流程重复
提高代码复用性(Code Reuseability)
减少代码耦合
满足单一职责原则
模块化
业务与非业务逻辑分离
通用代码下沉
继承、多态、抽象、封装
应用模板等设计模式
LOD
高内聚、松耦合
不该有直接依赖关系的类之间，不要有依赖
有依赖关系的类之间，尽量只依赖必要的接口
规范与重构
Subtopic
Subtopic
0 条评论
下一页
