面向对象的设计过程


面向对象的设计过程

背景

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

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

场景

首先提问:平常工作中来了一个业务需求,我们是如何开始写代码的?

一般人可能:

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

一个简单的业务场景

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

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 版完整代码

上面的代码有什么好处?

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

什么是面向对象

概念

面向对象的设计原则

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

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

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

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

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

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

3.抽象用于不同的事物,而接口用于事物的行为

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



Enjoy Reading This Article?

Here are some more articles you might like to read next:

  • 2379. Minimum Recolors to Get K Consecutive Black Blocks
  • 2471. Minimum Number of Operations to Sort a Binary Tree by Level
  • 1387. Sort Integers by The Power Value
  • 2090. K Radius Subarray Averages
  • 2545. Sort the Students by Their Kth Score