程序设计复用——偷保险箱与放大象

一个系统中负责业务逻辑的代码应该是精炼的，要确保代码行数非常少，非常精简。避免这部分代码编写的非常复杂。

一方面，业务逻辑是对实际需求的实现，而需求往往是最难以捉摸，难以理解的，更是变化莫测的，也就意味这部分代码是最容易变动的，编写的越精简，越容易后期维护和升级。

另一方面，业务，说白的就是做一件事情的步骤，这种步骤，无论看似多么复杂，都是可以进行拆分的，拆分成很多的，很简单的，可重复的步骤，这样可以增强业务操作的可重用性，这应该是设计层面完成的，反应出来是重用代码，减少工作量，降低工作成本。

举个不是很恰当的例子，脑筋急转弯：如何把大象放进冰箱里？

这是个经典的脑筋急转弯，并且很巧妙说明，业务逻辑精简。大部分人第一次听到这个问题，都会去思索，这怎么放啊，大象那么大，有这么大的冰箱吗，就算冰箱足够大，那该如何放，横着，竖着，切碎了，但是这些都是在回答这件事的可行性，其实我们都知道该如何做：打开冰箱门，把大象放进去，关上冰箱门，就这么三步。但是我们直接就跳过去了，作为设计人员，你要做的就是从具体的操作中，提取暗含的步骤信息，并且做到精简到极致的步骤也就是业务逻辑的提取，这样无论是放大象也好，放鸡蛋也罢，都只能这么做。步骤一模一样，不能再精简哪怕一步。

然后再开发的时候，把打开冰箱门这个操作，可以做的通用性强一下，复杂一点，保证无论什么门都能打开，这只是个极端的例子。那么下一次，你们做一个偷保险库的程序时，你会发现，这些操作完全可以复用。偷保险箱和放大象，两个各不搭边的业务也可以复用。

转载于:https://www.cnblogs.com/yweaner/p/3419976.html