面向对象

面向对象特性

封装

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 接口。通过这个入口，我们能触发整个代码跑起来。