OOP

面向对象编程（OOP，Object Oriented Programming）是一种编程范式或编程风格，以类（class）和对象（object）作为组织代码的基本单元，并将封装、抽象、继承、多态四个特性作为代码设计和实现的基石。

四大特性封装、抽象、继承、多态，有些人也认为只有三大特性，把抽象排除在外。

面向对象编程语言（OOPL，Object Oriented Programming Language）是支持类或对象的语法机制，并有现成的语法机制，能方便地实现面向对象编程四大特性（封装、抽象、继承、多态）的编程语言。

按照严格的定义，很多语言都不是面 OOPL，比如 JavaScript 不支持封装和继承，Go 摒弃了继承。但是按照不严格的定义，很多语言都可以说是 OOPL，只要某种编程语言支持类或对象的语法概念，并且以此作为组织代码的基本单元，那就可以被粗略地认为它就是 OOPL 了。

OOP 一般使用 OOPL 来进行，但是，不用 OOPL，我们照样可以进行 OOP。反过来讲，即便我们使用 OOPL，写出来的代码也不一定是 OOP 风格的，也有可能是面向过程编程风格的。

面向对象分析（OOA，Object Oriented Analysis）和面向对象设计（OOA，Object Oriented Design）的产出是类的设计，包括程序被拆解成哪些类、类有哪些属性方法、类于类之间的关系。

四大特性

封装（Encapsulation）

也叫信息隐藏或数据访问保护。封装的意义：

  • 提高代码的可维护性。如果对类中的属性访问不做限制，那么则类不可控，属性被随意修改，修改的逻辑散落在代码各个角落。

  • 类通过仅暴露必要的操作，可以提高类的易用性，调用者不需要了解过多的细节。

抽象（Abstraction）

封装讲的是如何隐藏信息、保护数据；而抽象讲的是隐藏方法的具体实现，调用者只关系方法提供了哪些功能，并不需要知道这些功能是怎么实现的。

通常使用接口类或抽象类两种语法机制实现。

上文讲到有时候抽象被排除在四大特性之外。原因如下： 实现抽象不一定需要接口类或抽象类，因为类的方法是通过编程语言的函数这一语法机制本省就是抽象，使用者在调用函数的时候，并不需要知道内部逻辑。

抽象的意义：

  • 抽象和封装都是处理复杂性的有效手段，面对复杂系统，人脑有限，所以必须忽略掉非关键的细节。

  • 提高代码的可扩展性、维护性，修改实现不需要修改定义。

继承（Inheritance）

继承表示类之间 is-a 的关系。继承分为单继承和多继承。

继承最大的好处是代码复用。不过，过度使用继承会导致代码的可读性，可维护性变差，父类和子类耦合度过高。所以继承这个特性非常有争议，我们应该尽量少用。

多态（Polymorphism）

多态是指子类可以替换父类，在实际的代码运行过程中，调用子类的方法实现。

多态的实现一般需要三种语法机制：

  • 父类对象引用可以指向子类对象。

  • 支持继承。

  • 子类可以重写（override）父类方法。

多态可以提高代码的可扩展性和复用性。

面向过程

What？

面向过程编程也是一种编程范式或编程风格。它以过程（方法、函数、操作）作为组织代码的基本单元，以数据与方法相分离为最主要的特点。面向过程风格是一种流程化的编程风格，通过拼接一组顺序执行的方法来操作数据完成一项功能。

面向过程编程语言首先是一种编程语言。它最大的特点是不支持类和对象两个语法概念，不支持丰富的面向对象编程特性（比如继承、多态、封装），仅支持面向过程编程。

OOP 有哪些优势？

  • OOP 能够应对大规模复杂程序开发。对于简单程序，面向过程、面向对象差别不大，有时面向过程更简单。

  • OOP 更易复用、易扩展、易维护。由上文的四大特性可见。

  • OOP 语言更加人性化，更接近于人的思维，而机器语言、汇编、面向过程是按照计算机的思维方式。

本质是面向过程的代码

在实际开发中，不是把代码塞到类里，就表示在面向对象编程了。很多情况下，有很多表面上像面向对象的代码，本质上时面向过程的风格。

滥用 getter、setter 方法

我们经常会遇到定义完类后，随手就把所有 属性的 getter、setter 加上去，或者用 lombok 等。这样违反了面向对象封装的特性。如下面的例子：

@Data
public class ShoppingCart {
  private int itemsCount;
  private double totalPrice;
  private List<ShoppingCartItem> items = new ArrayList<>();
  
  public void addItem(ShoppingCartItem item) {
    items.add(item);
    itemsCount++;
    totalPrice += item.getPrice();
  }
  // ...省略其他方法...
}

上面的代码有很多问题：

  • items、totalPrice 定义为私有属性，但是又提供 getter、setter 方法，本质上就是 public 属性了。任何地方都可以修改这两个值，会造成和 items 的数据不一致问题。

  • items 提供了 getter 方法，返回的是 List，外部拿到这个容器后，可以修改容器内数据。解决方案：可以使用Collections.unmodifiableList()。

  • 就算用不可变容器，还是有问题，因为用户拿到容器后，再拿容器内的某个元素，还是可以修改元素的某个字段值。

总结一下：

  • 能不暴露 setter 方法就尽量不要暴露。

  • getter 方法如果返回的是容器或者类，也要注意内部的数据被修改。

滥用全局变量和全局方法

全局变量：单例类对象、静态成员变量、常量，比如 Constants；全局方法：静态方法，比如 Utils。

全局变量

我们会见到把程序中所有的常量都集中方法一个 Constants 类中，这种大而全的常量类并不好，原因是：

  • 可维护性差，一个项目有很多工程师开发，那么就都可能修改这个类，这个类就会很大，查找修改某个常量也会比较耗时，还可能引起代码冲突。

  • 增加编译时间，依赖这个 Constants 的类很多，所以只要这个常量类有修改，很多类都需要重新编译。

  • 复用性差，如果有另一个项目也依赖 Constants 类，但是只依赖一小部分，这样就引入了很多无关的常量。

解决方案：

  • 把大的 Constants 拆分，如 MySQLConstants、RedisConstants 等。

  • 不设计 Constants 类，哪个类使用了常量，就把这个常量定义在这个类中。

全局方法

为什么会出现 Utils 类呢？因为存在一种情况，两个类有一段逻辑是重复的，虽然继承可以解决代码复用问题，但是这两个类又有没 is-a 的关系，这个时候就出现了 Utils 类。

我们并不是要测地杜绝 Utils 类，只是不要滥用。另外，Utils 也可以细化。

数据和方法分离

传统的 MVC 是 Model、Controller、View。前后端分离后，后端的三层结构变为 Controller、Service、Repository，在每一层都有对应的 VO、BO、Entity，其实这就是数据和方法分离。比如，BO 只定义了数据，而操作数据的方法都在 Service 中，这就是典型的面向过程的编程风格。

这种开发模式叫做基于贫血模式的开发方式。

面向过程的取舍

虽然上文讲了 OOP 的各种优势，也讲了哪些代码表面上是面向对象，本质上是面向过程。但是面向过程并不是完全无用武之地。

若是开发微小程序，或者做一些数据处理（算法为主、数据为辅），那么面向过程更加适合。

面向对象和面向过程可以并存的，甚至在一些标准库（JDK、Apache Commons、Guava）中都可以见到面向过程风格的代码。

所以，我们最终的目的是写出易维护、易读、易复用、易扩展的高质量代码。

贫血模型

MVC 架构指的是 Model、View、Controller，表示展示层、逻辑层、数据层，现在多是前后端分离，后端分为 Repository、Service、Controller 三层。

一般在写代码的时候，Entity 和 Repository 类组成数据层，Bo 和 Service 类组成业务逻辑层，Vo 和 Controller 类组成接口层。可以发现，Entity、Bo、Vo 是一个纯粹的数据结构，不包含任何业务逻辑，业务逻辑放在另一个类中，这是一种典型的面向过程的编程风格。像 Bo 这种只包含数据，不包含业务逻辑的类叫做贫血模型（Anemic Domain Model）。

充血模型（Rich Domain Model）刚好相反，数据和业务被封装在同一个类中。基于充血模型的 DDD 开发与贫血模型的主要差别在于 Service 层，DDD 的 Service 层包含Service 类和 Domain 类，Domain 类包含数据和业务逻辑，而 Service 类很单薄。

为什么贫血模型这么受欢迎？

  • 系统业务简单，贫血模型足以应付，不需要费心思设计充血模型。

  • 充血模型更有难度。

  • 思维已固化，转型有成本。

那什么项目应该考虑用充血模型呢？

业务复杂的系统，比如包含各种利息计算模型、还款模型等复杂业务的金融系统。

PreviousUMLNextPrinciple

Last updated