面向对象特性
封装
What:隐藏信息,保护数据访问。
How:暴露有限接口和属性,需要编程语言提供访问控制的语法。
Why:提高代码可维护性;降低接口复杂度,提高类的易用性。
抽象
What: 隐藏具体实现,使用者只需关心功能,无需关心实现。
How: 通过接口类或者抽象类实现,特殊语法机制非必须。
Why: 提高代码的扩展性、维护性;降低复杂度,减少细节负担。
继承
What: 表示 is-a 关系,分为单继承和多继承。
How: 需要编程语言提供特殊语法机制。例如 Java 的 “extends”,C++ 的 “:” 。
Why: 解决代码复用问题。
多态
What: 子类替换父类,在运行时调用子类的实现。
How: 需要编程语言提供特殊的语法机制。比如继承、接口类、duck-typing。
Why: 提高代码扩展性和复用性。
面向对象和面向过程
特性
面向对象是以类为基本单元。
面向过程是以函数为基本单元。
面向过程的特点是操作和数据分离,而面向对象操作数据都在同一个类中。
面向对象的语言,面向过程的代码
首先,并不是说面向对象的程序中,完全不能使用面向过程的方式实现,而是要避免滥用、适度就好。在最合适的地方用最合适的方式实现。
滥用getter/setter
看这里实际上是指虽然考虑通过访问权限控制,将属性对外隐藏,但是提供的access方法,却依然将访问属性的入口暴露出来,导致实际上类还是没有起到封装、隐藏细节的作用。
并且如果getter返回容器类型,需要考虑保护防止被外部修改。
PS:
这里实际上我认为,保持一定的封装性这个点,说的有道理,但是getter/setter这个例子不是特别好。
像OC,继承、多态,如果不用方法继承,可能会比较不方便,而且官方也是推荐访问类属性使用getter/setter。
滥用全局变量和全局方法
在面向对象编程中,常见的全局变量有单例类对象、静态成员变量、常量等,常见的全局方法有静态方法。
常量
可以使用常量,但是避免大而全的上帝常量类。因为会有以下问题:
- 影响代码可维护性
- 增加编译时间
- 影响代码复用性
解决方案:化整为零
Utils
出现的原因是代码复用上的考虑,由于两个会复用代码的类之间并没有直接联系,所以为了重用代码生造一个父类不可取。所以将相关的操作抽离出来形成一个工具类。这样其实正是面向过程的编程风格。
这里需要思考的其实是:是否一定要抽取工具类,而不是可以将其放在某个类中?并且,同样的需要避免大而全的上帝类出现。
定义数据操作分离的类
开发中经常会出现操作与数据分离的情况,如service、model相分离。model中只会定义数据,相关的操作是在对应的service类中。这也就是俗称的贫血模型。
为什么会写出面向过程的方法
- 人脑思维惯性
- 面向对象设计需要技巧,门槛较高,设计不好会导致画虎不成反类犬
抽象类和接口
特点
抽象类特点:
- 无法实例化,只能被继承
- 可以包含属性和方法,方法中可以有实现
- 子类继承抽象类,必须实现抽象类中的所有抽象方法
接口特点:
- 不能包含属性
- 只能声明方法,不能包含实现
- 类实现接口的时候,必须实现接口所有方法
意义
抽象类是对成员变量和方法的抽象,是一种 is-a 关系,是为了解决代码复用问题。
接口仅仅是对方法的抽象,是一种 has-a 关系,表示具有某一组行为特性,是为了解决解耦问题,隔离接口和具体的实现,提高代码的扩展性。
使用场景
如果要表示一种 is-a 的关系,并且是为了解决代码复用问题,我们就用抽象类;
如果要表示一种 has-a 关系,并且是为了解决抽象而非代码复用问题,那我们就用接口。
PS:
这里的描述感觉还是太偏向于语言特性了,据评论称jdk8就已经支持接口带默认实现了。
所以这里的问题实际上还是可以辩证的看。
面向抽象编程
抽象->脱离实际业务->底层、不易改变
面向抽象编程,可以提高可维护性。
但并不是所有的类都需要抽离出抽象接口,只使用在不稳定的实现上即可。
组合与继承
-
为什么不推荐使用继承?
继承是面向对象的四大特性之一,用来表示类之间的 is-a 关系,可以解决代码复用的问题。虽然继承有诸多作用,但继承层次过深、过复杂,也会影响到代码的可维护性。在这种情况下,我们应该尽量少用,甚至不用继承。 -
组合相比继承有哪些优势?
继承主要有三个作用:表示 is-a 关系,支持多态特性,代码复用。而这三个作用都可以通过组合、接口、委托三个技术手段来达成。除此之外,利用组合还能解决层次过深、过复杂的继承关系影响代码可维护性的问题。 -
如何判断该用组合还是继承?
尽管我们鼓励多用组合少用继承,但组合也并不是完美的,继承也并非一无是处。在实际的项目开发中,我们还是要根据具体的情况,来选择该用继承还是组合。如果类之间的继承结构稳定,层次比较浅,关系不复杂,我们就可以大胆地使用继承。反之,我们就尽量使用组合来替代继承。除此之外,还有一些设计模式、特殊的应用场景,会固定使用继承或者组合。
贫血模型、充血模型
贫血模型
Service 层的数据和业务逻辑,被分割为 BO 和 Service 两个类中。
像 UserBo 这样,只包含数据,不包含业务逻辑的类,就叫作贫血模型(Anemic Domain Model)。
同理,UserEntity、UserVo 都是基于贫血模型设计的。
这种贫血模型将数据与操作分离,破坏了面向对象的封装特性,是一种典型的面向过程的编程风格。
充血模型
充血模型(Rich Domain Model)正好相反,数据和对应的业务逻辑被封装到同一个类中。
因此,这种充血模型满足面向对象的封装特性,是典型的面向对象编程风格。
DDD
领域驱动开发
可以合理的拆分微服务。
适用充血模型。
面向对象分析与设计
设计分为三大步
-
面向对象分析OOA
-
面向对象设计OOD
-
面向对象开发OOP
-
划分职责进而识别出有哪些类
根据需求描述,我们把其中涉及的功能点,一个一个罗列出来,然后再去看哪些功能点职责相近,操作同样的属性,可否归为同一个类。 -
定义类及其属性和方法
我们识别出需求描述中的动词,作为候选的方法,再进一步过滤筛选出真正的方法,把功能点中涉及的名词,作为候选属性,然后同样再进行过滤筛选。 -
定义类与类之间的交互关系
UML 统一建模语言中定义了六种类之间的关系。它们分别是:泛化、实现、关联、聚合、组合、依赖。我们从更加贴近编程的角度,对类与类之间的关系做了调整,保留四个关系:泛化、实现、组合、依赖。 -
将类组装起来并提供执行入口
我们要将所有的类组装在一起,提供一个执行入口。这个入口可能是一个 main() 函数,也可能是一组给外部用的 API 接口。通过这个入口,我们能触发整个代码跑起来。
网友评论