17.1 场 景 问 题

17.1.1 报价管理

向客户报价,对于销售部门的人来讲,这是一个非常重大和复杂的问题,对不同的客户要报不同的价格,比如:

■ 对普通客户或者是新客户报的是全价;

■ 对老客户报的价格,根据客户年限,给予一定的折扣;

■ 对大客户报的价格,根据大客户的累计消费金额,给予一定的折扣;

■ 还要考虑客户购买的数量和金额,比如,虽然是新用户,但是一次购买的数量非常大,或者是总金额非常高,也会有一定的折扣;

■ 还有,报价人员的职务高低,也决定了他是否有权限对价格进行一定的浮动折扣。

甚至在不同的阶段,对客户的报价也不同。一般情况是刚开始比较高,越接近成交阶段,报价越趋于合理。

总之,向客户报价是非常复杂的,因此在一些CRM(客户关系管理)系统中,会有一个单独的报价管理模块,来处理复杂的报价功能。

为了演示的简洁性,假定现在需要实现一个简化的报价管理,实现如下的功能。

■ 对普通客户或者是新客户报全价;

■ 对老客户报的价格,统一折扣5%;

■ 对大客户报的价格,统一折扣10%。

该怎么实现呢?

17.1.2 不用模式的解决方案

要实现对不同的人员报不同价格的功能,无外乎就是判断起来麻烦点,也没多难,很快就有朋友能写出如下的实现代码。示例代码如下:

6d338e09947446c391d03ee244378d5d

1281b9e1448142ca8b3d9fdab9889cc0

17.1.3 有何问题

上面的写法是很简单的,也很容易想到,但是仔细想想,这样实现,问题可不小,有以下两个问题。

(1)价格类包含了所有计算报价的算法,使得价格类,尤其是报价这个方法比较庞杂,难以维护。

有朋友可能会想,这很简单嘛,把这些算法从报价方法里面拿出去,形成独立的方法不就可以解决这个问题了吗?据此写出如下的实现代码。示例代码如下:

3f2ccb64a612469f8a3db8a41d62e4f6

bc35d41d33ad4fe9a7cdf3e190ede62a

1ea79fe76a9f461d84feef6f907e51a8

这样看起来,比刚开始稍稍好点,计算报价的方法也稍稍简单一点,这样维护起来也稍好一些,某个算法发生了变化,直接修改相应的私有方法就可以了。扩展起来也容易一点,比如要增加一个“战略合作客户”的类型,报价为直接8折,就只需要在价格类里面新增加一个私有的方法来计算新的价格,然后在计算报价的方法中新添一个else-if即可。看起来似乎很不错了。

真的很不错了吗?

再想想,问题还是存在,只不过从计算报价的方法挪动到价格类中了,假如有100个或者更多这样的计算方式,会使这个价格类非常庞大,难以维护。而且,维护和扩展都需要去修改已有的代码,这是很不好的,违反了开一闭原则。

(2)经常会有这样的需要,在不同的时候,要使用不同的计算方式。

比如,在公司周年庆的时候,所有的客户额外增加3%的折扣;在换季促销的时候,普通客户是额外增加折扣2%,老客户是额外增加折扣3%,大客户是额外增加折扣5%。这意味着计算报价的方式会经常被修改,或者被切换。

通常情况下应该是被切换,因为过了促销时间,又还回到正常的价格体系上来了。而现在的价格类中计算报价的方法,是固定调用各种计算方式,这使得切换调用不同的计算方式很麻烦,每次都需要修改if-else中的调用代码。

看到这里,可能有朋友会想,那么到底应该如何实现,才能够让价格类中的计算报价的算法,能很容易地实现可维护、可扩展,又能动态地切换变化呢?