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）的产出是类的设计，包括程序被拆解成哪些类、类有哪些属性方法、类于类之间的关系。
也叫信息隐藏或数据访问保护。封装的意义：
- 提高代码的可维护性。如果对类中的属性访问不做限制，那么则类不可控，属性被随意修改，修改的逻辑散落在代码各个角落。
- 类通过仅暴露必要的操作，可以提高类的易用性，调用者不需要了解过多的细节。
封装讲的是如何隐藏信息、保护数据；而抽象讲的是隐藏方法的具体实现，调用者只关系方法提供了哪些功能，并不需要知道这些功能是怎么实现的。
通常使用接口类或抽象类两种语法机制实现。
上文讲到有时候抽象被排除在四大特性之外。原因如下：
实现抽象不一定需要接口类或抽象类，因为类的方法是通过编程语言的函数这一语法机制本省就是抽象，使用者在调用函数的时候，并不需要知道内部逻辑。
抽象的意义：
- 抽象和封装都是处理复杂性的有效手段，面对复杂系统，人脑有限，所以必须忽略掉非关键的细节。
- 提高代码的可扩展性、维护性，修改实现不需要修改定义。
继承表示类之间 is-a 的关系。继承分为单继承和多继承。
继承最大的好处是代码复用。不过，过度使用继承会导致代码的可读性，可维护性变差，父类和子类耦合度过高。所以继承这个特性非常有争议，我们应该尽量少用。
多态是指子类可以替换父类，在实际的代码运行过程中，调用子类的方法实现。
多态的实现一般需要三种语法机制：
- 父类对象引用可以指向子类对象。
- 支持继承。
- 子类可以重写（override）父类方法。
多态可以提高代码的可扩展性和复用性。
面向过程编程也是一种编程范式或编程风格。它以过程（方法、函数、操作）作为组织代码的基本单元，以数据与方法相分离为最主要的特点。面向过程风格是一种流程化的编程风格，通过拼接一组顺序执行的方法来操作数据完成一项功能。
面向过程编程语言首先是一种编程语言。它最大的特点是不支持类和对象两个语法概念，不支持丰富的面向对象编程特性（比如继承、多态、封装），仅支持面向过程编程。
- OOP 能够应对大规模复杂程序开发。对于简单程序，面向过程、面向对象差别不大，有时面向过程更简单。
- OOP 更易复用、易扩展、易维护。由上文的四大特性可见。
- OOP 语言更加人性化，更接近于人的思维，而机器语言、汇编、面向过程是按照计算机的思维方式。
在实际开发中，不是把代码塞到类里，就表示在面向对象编程了。很多情况下，有很多表面上像面向对象的代码，本质上时面向过程的风格。
我们经常会遇到定义完类后，随手就把所有 属性的 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 类很单薄。
为什么贫血模型这么受欢迎？
- 系统业务简单，贫血模型足以应付，不需要费心思设计充血模型。
- 充血模型更有难度。
- 思维已固化，转型有成本。
那什么项目应该考虑用充血模型呢？
业务复杂的系统，比如包含各种利息计算模型、还款模型等复杂业务的金融系统。
Last modified 3yr ago