On Simple Design II: 简单 != 少


See also Lightening Talk: 简单设计


经常碰到的一段对话是:“这里为什么要引入一个类?字符串就好了,简单设计嘛” 或者 “一个switch/case就搞定的,弄个子类干嘛?”

事实通常是反过来的,引入新的类型或子类比使用字符串或switch/case更简单. 我来解释一下

设计是否简单的一个判断标准是它是否更容易理解. 而我们对事物的理解建立在概念或模型之上. 比如做一个最简单的超市存包系统,能存包能取包,没有进一步的需求. 牵扯到的概念可能有包裹,储物柜,存完包有个凭证用于取包. 这时我的设计中引入一个空类 public class Package {} 来代表包裹,另外一个空类 public class Ticket {} 来代表凭证. 你跟我说应该用字符串因为它更简单,反正也不会有新的需求, 我是不同意的. 我们来看采用这两种设计的代码,比如存包:

  • public Ticket Put(Package package){…}
  • public string Put(string package) {…}

用起来:

  • new Cabinet().Put(new Package());
  • new Cabinet().Put(“some package”);

即使不再有扩展需求,即使第一种设计比第二种设计多两个没有任何行为的空类,第一种设计也要比第二种简单. 因为它更易于理解. 它跟我脑袋里关于存包这件事概念和词汇是一致的,不需要做任何翻译的. 而采用字符串,我看到代码后还得把它翻译成包裹,翻译成凭证,甚至没人跟我解释这段代码我还不知道应该做个翻译,它阻碍了我的理解,因此它是更复杂的. 这是第一个角度

Ubiquitous Language

第二个角度是沟通交流的问题. 我们在描述存包系统的需求的时候,不可避免的会提到包裹和凭证这类概念,Tester来写测试用例肯定也会用到这类词汇,可到代码中突然没有了,只剩字符串了, 你告诉我这是简单设计,你这是令人困惑的设计.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值