前言

我一直认为分享的目的不是炫技。

• 一是，自我学习的总结。
• 二是，降低他人的学习成本。
• 三是，别人对自己学习结果的审核。

同时，本次分享有下面四个要素：

背景

工作中，几乎大家经常抱怨别人写的代码：

• 没法改
• 耦合高
• 无法扩展

今天就来探讨如何克服上面的问题～

场景

首先问个问题：

平常工作中来了一个业务需求，我们是如何开始写代码的？

我推测大多数人可能：

• 1、梳理业务
• 2、设计数据库、接口、缓存
• 3、评审
• 4、于是就开始了 怎么怎么样...如果怎么怎么样...怎么怎么样...愉快的码代码的过程

此处有人觉着有啥问题么？

备注：说出来问题的，本次分享就可以略过了~

一个简单的业务场景

比如产品提了个需求：
描述“我一个同事”一天的生活，简单来看看他一天干些啥：

1.0 饿了吃饭
1.1 到点吃饭

2.0 渴了喝水
2.1 到点喝水

3.0 困了睡觉
3.1 到点睡觉
3.2 有可能一个人睡觉，也有可能... 是吧？复杂

刚开始，一个业务逻辑从头写到尾

一个业务逻辑(拆成多个函数)从头写到尾：

一个业务逻辑(引入类)从头写到尾：

一个业务逻辑(拆成多个类方法)从头写到尾，也许、可能、貌似、猜测大多数人停留到了这个阶段。
问题：某一天多了社交的能力，咋办？

一个业务逻辑(拆成多类)从头写到尾：

一个业务逻辑(拆成类、抽象类、接口)从头写到尾：

思考🤔：上面的代码就没啥问题了吗？

上面就是面向对象设计的代码结果。

所以，如何设计出完全面向对象的代码？

代码建模

什么是代码建模？

把业务抽象成事物(类class、抽象类abstact class)和行为(接口interface)的过程。

实栗🌰分析

又来看一个实际的业务场景：

最近“我一个同事”开始创业了，刚创立了一家电商公司，B2C，自营书籍《3分钟学会交际》。最近开始写提交订单的代码。

⚠️注意场景 1.刚创业 2.简单的单体应用 3.此处不探讨架构

一般来说，我们根据业务需求一顿分析，开始定义接口API、设计数据库、缓存、技术评审等就开始码代码了。

接口参数：
uid
address_id
coupon_id
.etc

业务逻辑：
参数校验->
地址校验->
其他校验->
写订单表->
写订单商品信息表->
写日志->
扣减商品库存->
清理购物车->
扣减各种促销优惠活动的库存->
使用优惠券->
其他营销逻辑等等->
发送消息->
等等...

就开始写代码了怎么怎么样...如果怎么怎么样...怎么怎么样...一蹴而就、思路清晰、逻辑清楚、很快搞定完代码，很优秀是不是，值得鼓励。

但是，上面的结果就是大概所有人都见过的连续上千行的代码等等。上面的流程没啥问题啊，那正确的做法是什么了？就是接着要说的代码建模。

我们根据上面的场景，开始建模。

业务分析少不了

同样，首先，我们看看提交订单这个业务场景要做的事情:

换个角度看业务其实很简单：根据用户相关信息生成一个订单。

1. 梳理得到业务逻辑

   参数校验-> 地址校验-> 其他校验-> 写订单表-> 写订单商品信息表-> 写日志-> 扣减商品库存-> 清理购物车-> 扣减各种促销优惠活动的库存-> 使用优惠券-> 其他营销逻辑等等-> 发送消息-> 等等...

2. 梳理业务逻辑依赖信息

   用户信息 商品信息 地址信息 优惠券信息 等等...

再次回归概念

什么是代码建模？把业务抽象成事物(类class、抽象类abstact class)和行为(接口interface)的过程。

获取事物

比如我们把订单生成的过程可以想象成机器人，一个生成订单的订单生成机器人，或者订单生成机器啥的，这样我们就得到了代码建模过程中的一个事物。

从而我们就可以把这个事物转化成一个类(或结构体)，或者抽象类。

获取行为

这些操作就是上面机器人要做的事情。

事物有了：订单生成机器人
行为呢？毫无疑问就是上面各种业务逻辑。把具体的行为抽象成一个订单创建行为接口：

得到UML

设计代码

1. 定义一个类

2. 定义一个订单创建行为的接口

3. 定义具体的不同订单创建行为类

   参数校验-> 地址校验-> 其他校验-> 写订单表-> 写订单商品信息表-> 写日志-> 扣减商品库存-> 清理购物车-> 扣减各种促销优惠活动的库存-> 使用优惠券-> 其他营销逻辑等等-> 发送消息-> 等等...

4. 创建订单

这里的代码该怎么写，这样？

还可以继续优化吗？

使用闭包。

PHP版完整代码

Go版完整代码

上面的代码有什么好处？

假如“我一个同事”又要新开发一个新的应用，新的应用创建订单的时候又有新的逻辑，比如没有优惠逻辑、新增了增加用户积分的逻辑等等，复用上面的代码，是不是就很简单了。

所以现在，什么是面向对象？

概念

面向对象的设计原则

• 对接口编程而不是对实现编程
• 优先使用对象组合而不是继承
• 抽象用于不同的事物，而接口用于事物的行为

针对上面的概念，我们再回头开我们上面的代码

对接口编程而不是对实现编程

结果：RobotOrderCreate依赖了BehaviorOrderCreateInterface抽象接口

优先使用对象组合而不是继承

结果：完全没有使用继承，多个行为不同场景组合使用

抽象用于不同的事物，而接口用于事物的行为

结果：
1. 抽象了一个创建订单的机器人 RobotOrderCreate
2. 机器人又有不同的创建行为
3. 机器人的创建行为最终依赖于BehaviorOrderCreateInterface接口

是不是完美契合，所以这就是“面向对象的设计过程”。

结论

代码建模过程就是“面向对象的设计过程”的具体实现方式.

预习

设计模式

最后，设计模式又是什么？

同样，我们下结合上面的场景和概念预习下设计模式。

设计模式的设计原则

开闭原则（Open Close Principle）：对扩展开放，对修改封闭

看看上面的最终的代码是不是完美契合。

依赖倒转原则：对接口编程，依赖于抽象而不依赖于具体

结果：创建订单的逻辑从依赖具体的业务转变为依赖于抽象接口BehaviorOrderCreateInterface

接口隔离原则：使用多个接口，而不是对一个接口编程，去依赖降低耦合

结果：上面的场景，我们只简单定义了订单创建的接BehaviorOrderCreateInterface。由于订单创建过程可能出现异常回滚，我们就需要再定义一个订单创建回滚的接口
BehaviorOrderCreateRollBackInterface.

迪米特法则，又称最少知道原则：减少内部依赖，尽可能的独立

结果：还是上面那段代码，我们把RobotOrderCreate机器人依赖的行为通过外部注入的方式使用。

合成复用原则：多个独立的实体合成聚合，而不是使用继承

结果：RobotOrderCreate依赖了多个实际的订单创建行为类。

里氏代换：超类（父类）出现的地方，派生类（子类）都可以出现

结果：不好意思，我们完全没用继承。（备注：继承容易造成父类膨胀。）

下回预告

上面预习了设计模式的概念，下次我们进行《设计模式业务实战》。