4.4 违背设计模式实现

如果不考虑程序的任何扩展性，只为了尽快满足需求，那么对这三种奖励的发放只需使用if…else语句判断，调用不同的接口即可。我们先按照这样的方式实现业务需求，最后再使用设计模式重构这段代码，方便对照理解。

4.4.1 工程结构

整个工程结构非常简单，包括一个入参对象AwardReq、一个出参对象AwardRes，以及奖品发放的服务类PrizeController。接下来，给出核心抽奖类的实现代码。

4.4.2 if…else实现需求

上述代码使用了if…else语句，用非常直接的方式实现了业务需求。如果仅从产品需求角度来说，确实实现了相应的功能逻辑。甚至靠这样简单粗暴的开发方式，也许能让需求提前上线。既然这样的代码可以实现快速交付，又存在什么问题呢？在互联网业务快速迭代的情况下，这段代码会在源源不断的需求中迭代和拓展。如果这些逻辑都用 if…else填充到一个类里，则非常难以维护。这样的代码使用的时间越久，其重构成本就越高。重构前需要清理所有的使用方，测试回归验证时间加长，带来的风险也会非常高。所以，很多研发人员并不愿意接手这样的代码，如果接手后需求开发又非常紧急，可能根本来不及重构，导致这样的if…else语句还会继续增加。

4.4.3 测试验证

下面通过一个单元测试验证上面编写的接口。养成单元测试的好习惯，可以增强代码的质量。

测试模拟发放优惠券。

测试模拟发放实物商品。

测试模拟发放第三方兑换卡（爱奇艺）。

虽然运行结果正常，满足当前所有的业务产品需求，但这样的实现方式不易于扩展，也非常难以维护，风险很高。