如何写一个清晰明了的Bug(2)

在用完组合后，我们的代码其实已经基本上比较清楚了。但为了让我们的代码更加的优雅，更上一个层次。有的场景下你需要使用到设计模式，设计模式被总结成为最佳实践，不是仅仅用来写框架用的，写日常纷繁复杂的业务逻辑代码也是需要设计模式的。

接下来我就以自己正在开发的项目中的场景为例，来说说如何使用设计模式改善你的既有代码。

在项目中我们需要为审批工作流提供一个回调(callback)接口。审批流有不同的状态，不同的状态回调会执行不同的逻辑。在重构前的代码大体是这样的：

我们希望最终的样子是这样的：

首先新建一个State接口类：

然后新建三个实现状态，分别是Yes，No和Cancel：

然后新建一个Context类：

然后，新建一个State工厂类：

改造完毕。通过上面的重构，我们使用了状态模式和一点点工厂模式。最终callback方法就只需通过newInstance就可以找到具体状态的回调逻辑，而以后即使状态在不断的增加的，你也只需新建一个新的实现状态，然后注入工厂类中，做到了可插拔。值得注意的是，这里我们的state其实并没有很好的被传递和持有，这很不“状态”，这通过这样的方式我们实现了对callback的重构，结构也更加的清晰了。总之，当你遇到业务需求的不断变化，你需要找到一种合适的设计模式来hold住它，即使GOLF不能满足你的需求，你也可以自己创造一个设计模式来让你的代码清晰易懂。

总结

本文一开始介绍了if else泛滥后的问题。然后为你介绍了“一提二抽三组四模式”法则。我们的项目也是万事万物中的一部分，套用《规模》一书中的一段话：耗散力一直在持续且不可避免地做着功，这使得所有系统都将退化。设计最为精巧的机器、最具创新组织力的公司、进化得最完美的生物都无法逃脱这一最为严酷的死神。耗散力就是一个系统运转所产生的摩擦力，系统复杂性所带来的无序热量，你的代码也一样，也需要通过不断的改进和重构来尽量的延缓和降低熵的增长。

最终我们都将屈服于各种形式的磨损和衰竭，熵能杀人，你需要吃饭!

（编辑：ASP站长网）