美文网首页
面向对象

面向对象

作者: 西山薄凉 | 来源:发表于2020-03-29 22:50 被阅读0次

    面向对象特性

    封装

    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。

    滥用全局变量和全局方法

    在面向对象编程中,常见的全局变量有单例类对象、静态成员变量、常量等,常见的全局方法有静态方法。

    常量

    可以使用常量,但是避免大而全的上帝常量类。因为会有以下问题:

    1. 影响代码可维护性
    2. 增加编译时间
    3. 影响代码复用性

    解决方案:化整为零

    Utils

    出现的原因是代码复用上的考虑,由于两个会复用代码的类之间并没有直接联系,所以为了重用代码生造一个父类不可取。所以将相关的操作抽离出来形成一个工具类。这样其实正是面向过程的编程风格。
    这里需要思考的其实是:是否一定要抽取工具类,而不是可以将其放在某个类中?并且,同样的需要避免大而全的上帝类出现。

    定义数据操作分离的类

    开发中经常会出现操作与数据分离的情况,如service、model相分离。model中只会定义数据,相关的操作是在对应的service类中。这也就是俗称的贫血模型。

    为什么会写出面向过程的方法

    1. 人脑思维惯性
    2. 面向对象设计需要技巧,门槛较高,设计不好会导致画虎不成反类犬

    抽象类和接口

    特点

    抽象类特点:

    • 无法实例化,只能被继承
    • 可以包含属性和方法,方法中可以有实现
    • 子类继承抽象类,必须实现抽象类中的所有抽象方法

    接口特点:

    • 不能包含属性
    • 只能声明方法,不能包含实现
    • 类实现接口的时候,必须实现接口所有方法

    意义

    抽象类是对成员变量和方法的抽象,是一种 is-a 关系,是为了解决代码复用问题。
    接口仅仅是对方法的抽象,是一种 has-a 关系,表示具有某一组行为特性,是为了解决解耦问题,隔离接口和具体的实现,提高代码的扩展性。

    使用场景

    如果要表示一种 is-a 的关系,并且是为了解决代码复用问题,我们就用抽象类;
    如果要表示一种 has-a 关系,并且是为了解决抽象而非代码复用问题,那我们就用接口。

    PS:
    这里的描述感觉还是太偏向于语言特性了,据评论称jdk8就已经支持接口带默认实现了。
    所以这里的问题实际上还是可以辩证的看。

    面向抽象编程

    抽象->脱离实际业务->底层、不易改变
    面向抽象编程,可以提高可维护性。
    但并不是所有的类都需要抽离出抽象接口,只使用在不稳定的实现上即可。

    组合与继承

    1. 为什么不推荐使用继承?
      继承是面向对象的四大特性之一,用来表示类之间的 is-a 关系,可以解决代码复用的问题。虽然继承有诸多作用,但继承层次过深、过复杂,也会影响到代码的可维护性。在这种情况下,我们应该尽量少用,甚至不用继承。

    2. 组合相比继承有哪些优势?
      继承主要有三个作用:表示 is-a 关系,支持多态特性,代码复用。而这三个作用都可以通过组合、接口、委托三个技术手段来达成。除此之外,利用组合还能解决层次过深、过复杂的继承关系影响代码可维护性的问题。

    3. 如何判断该用组合还是继承?
      尽管我们鼓励多用组合少用继承,但组合也并不是完美的,继承也并非一无是处。在实际的项目开发中,我们还是要根据具体的情况,来选择该用继承还是组合。如果类之间的继承结构稳定,层次比较浅,关系不复杂,我们就可以大胆地使用继承。反之,我们就尽量使用组合来替代继承。除此之外,还有一些设计模式、特殊的应用场景,会固定使用继承或者组合。

    贫血模型、充血模型

    贫血模型

    Service 层的数据和业务逻辑,被分割为 BO 和 Service 两个类中。
    像 UserBo 这样,只包含数据,不包含业务逻辑的类,就叫作贫血模型(Anemic Domain Model)。
    同理,UserEntity、UserVo 都是基于贫血模型设计的。
    这种贫血模型将数据与操作分离,破坏了面向对象的封装特性,是一种典型的面向过程的编程风格。

    充血模型

    充血模型(Rich Domain Model)正好相反,数据和对应的业务逻辑被封装到同一个类中。
    因此,这种充血模型满足面向对象的封装特性,是典型的面向对象编程风格。

    DDD

    领域驱动开发
    可以合理的拆分微服务。
    适用充血模型。

    后台MVC架构

    面向对象分析与设计

    设计分为三大步

    1. 面向对象分析OOA

    2. 面向对象设计OOD

    3. 面向对象开发OOP

    4. 划分职责进而识别出有哪些类
      根据需求描述,我们把其中涉及的功能点,一个一个罗列出来,然后再去看哪些功能点职责相近,操作同样的属性,可否归为同一个类。

    5. 定义类及其属性和方法
      我们识别出需求描述中的动词,作为候选的方法,再进一步过滤筛选出真正的方法,把功能点中涉及的名词,作为候选属性,然后同样再进行过滤筛选。

    6. 定义类与类之间的交互关系
      UML 统一建模语言中定义了六种类之间的关系。它们分别是:泛化、实现、关联、聚合、组合、依赖。我们从更加贴近编程的角度,对类与类之间的关系做了调整,保留四个关系:泛化、实现、组合、依赖。

    7. 将类组装起来并提供执行入口
      我们要将所有的类组装在一起,提供一个执行入口。这个入口可能是一个 main() 函数,也可能是一组给外部用的 API 接口。通过这个入口,我们能触发整个代码跑起来。

    相关文章

      网友评论

          本文标题:面向对象

          本文链接:https://www.haomeiwen.com/subject/qsmpuhtx.html