值对象的威力

值对象是DDD中非常重要的一种技术,掌握这种技术让你写代码事半功倍,体会到OO的精妙。如果你是一名Java程序员,我相信你或多或少地见过值对象了,只是你没有意识到而已。

引用维基百科的解释

In computer science, a value object is a small object that represents a simple entity whose equality is not based on identity.

字面意思就是,值对象是一个小对象,它代表着一个简单的实体,而实体的相等性不取决于它的ID。

刚刚接触OO编程的新手看完上面的解释相信直接是懵逼的,跟我接触这一概念时一样。如何理解值对象了,我还是举一个栗子。比如我们在做一个短信推送的服务,需要根据目标用户的手机号推送到相应的短信网关。我们定义了一个根据手机号推送短信的interface,很有可能我们是这么设计:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void sendMessage(String phone, String message) {
if(StringUtils.isBlank(phone) && phone.length()!=13) {
throw new IllegalArgumentException("phone format error:"+phone);
}
if(phone.starts("134")) {
sendMessageToChinaMobileGateway(phone,message);
}else if(phone.starts("130"){
sendMessageToChinaUnionGateway(phone,message);
}else if(phone.starts("189") {
sendMessageToChinaTelecomGateway(phone,message);
}else {
throw new RuntimeException("unknown phone range");
}
}

上面的过程我们只考虑3个号码段,134(移动)\130(联通)\189(电信),其他的号码短我们暂不处理。上面的处理方式有什么问题?

如果我们的工程里面只有一个地方用的phone的概念,也只有一个地方对phone所属的号码短进行判断,那么没问题。上面的写法没有任何问题,因为它是一个简单问题。但是如果你在做一个短信推送的应用,在你的工程里面会只有一个地方会使用phone这个概念吗,也之有一个地方需要判断号码短吗? 显然不可能。

有人可能会争论说,不就是判断号码归属吗?我可以搞一个类似PhoneQueryService之类的查询类,再提供一个
Operator queryBelong(String phone)的interface不就搞定了吗? 当然,这么做也没有问题。但是当你的问题域逐渐变得复杂的时候,你就会开始有些不舒服了。因为每一个出现phone的地方,你发现基本上都会需要PhoneQueryService,但是他们在代码上又是两个东西。这种做饭的滥用最终会导致Fat Service的出现,代码的复用性会急剧降低。

究其原因,是因为我们把phone这个概念和phone的行为给拆开了。你可以用String代表任何字符类型,可以是phone,也可以是name,基本上这种类型可以代表任何东西。使用你API的人无法从中得到任何信息,除了你把变量名称叫做phone以外。同时,判断手机号网段这个动作是和phone本身强相关的,为什么不把这个动作加到phone里面了?! 现在,我们重构一下代码,得到类似下面的代码结构:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
class Phone {
private String phoneNumber;
public Phone(String phoneNumber) {
if(!validate(phoneNumber)) {
throw new IllegalArgumentException("phone format error:"+phone);
}
this.phoneNumber = phoneNumber;
}

public static boolean validate(String phoneNmber) {
//验证逻辑
}

public boolean isMobile() {
return phoneNumber.starts("134");
}

public boolean isUnion() {
return phoneNumber.starts("130");
}

public boolean isTelecom() {
return phone.starts("189");
}

public String getRawPhone() {
return this.phoneNumber;
}

public boolean isSameWith(Phone other) {
return other!=null&&this.phoneNumber.equals(other.getRawPhone());
}
}

我们新增了一个叫Phone的类,并加入了判断网段归属的逻辑。引入这个类以后sendMessage()发生了什么变化呢?

1
2
3
4
5
6
7
8
9
10
11
void sendMessage(Phone phone, String message) {
checkNotNull(phone);

if(phone.isMobile()) {
sendMessageToChinaMobileGateway(phone,message);
}else if(phone.isUnion()){
sendMessageToChinaUnionGateway(phone,message);
}else if(phone.isChinaTelecom()) {
sendMessageToChinaTelecomGateway(phone,message);
}
}

咋一看,代码好像没有怎么减少啊。对于这个interface来说代码确实没有减少,反而我们还新加一个类。但是现在看看我们获得了什么:

  • 首先,方法签名变了。不在用String了,取而代之的是Phone类型。这对使用者的约束更强了,我们也再也不用判断phone是否合法了。
  • 其次,判断网段归属和phone合在一起了,这样我需要判断归属运营商的时候直接调用phone的方法就行了。

现在,我们已经得到了一个值对象了,那就是Phone。它是一个小对象,代表了手机号这个概念,它的相等性是基于其业务属性的,而不是ID,而且值对象根本就没有ID这个概念。

值对象最大的好处在于增加了代码复用,同时它也是类型安全的(这一点和我之前提到了enum类似)。如果你只在一个地方使用值对象,那么你是不会体会到值对象带来的好处的。但是,每当你的代码应用一次值对象,你就会收获值对象带来的好处。用的越多,收益越大,这一点和单元测试比较类似。使用值对象的另外一个好处就是前置的安全校验,尤其是你在编写SDK或者开放接口的时候。因为你无法知道使用者会如何使用你的API,那么通过值对象来获得一个前置的安全校验有着非常大的好处。

值对象用在什么地方呢? 我个人的经验就是,如果在你的工程中反复出现一个具体的概念(往往跟现实生活有关),而且这个概念中涉及的行为是某种确定性的(比如你知道了手机号,就知道对应的运营商一样),那么你可以考虑一下值对象。引用《实现领域驱动设计》中关于值对象特征的定义:

  • 描述了领域中的一件东西
  • 不可变的
  • 将不同的相关属性组合成了一个概念整体
  • 当度量和描述改变时,可以用另外一个值对象予以替换
  • 可以和其他值对象进行相等性比较
  • 不会对协作对象造成副作用

最为重要的就是它描述了领域中的某件东西,并且它是不可变的。值对象一旦创建就不会发生变化,如果你需要表示另外一个东西,用另外一个值对象来代替它。

值对象是DDD中非常重要的部分,我们应该尽可能对使用值对象来建模,因为它是易于使用和替换的。但是值对象的实例化确实一个令人头疼的问题,尤其是聚合中存在1对多的关系时。由于这些内容涉及到DDD的多方面的知识,我不在这里展开讨论了。后续会专门讲值对象的持久化问题。之所以在讲DDD之前首先讲值对象,因为它还是少数几个可以完全脱离DDD并不失其威力的利器。就算你完全不了解DDD,也可以非常顺手的使用值对象。

说了这么多,我相信你也对值对象有个具象的认识了。纸上得来终觉浅,不如看看你现有的代码中哪些可以用值对象来代替吧!

参考文献:

Wikipedia值对象的定义
Martin Fowler值对象的解释
实现领域驱动设计
Power Use of Value Objects in DDD: 强烈推荐

坚持原创技术分享,您的支持将鼓励我继续创作!