0O00--成品 汇总 原材料、数量

眼前有个包含多层bom的成品，怎么统计它需要（哪些，多少）原材料？

 

要解决这个问题，很喜欢自己挂在嘴边的一句话：写个递归有多难嘛？你写就完事了。

递归函数可谓是面试题里的常客了，例如当年“请对列表进行求和（不能出现关键字：while、for）”之类的《最后一题》我直到现在还记得。

递归有多难呢？就看调试有多烦。

小弟看了直摇头，不知道需要哪些参数，怎么接转传，只会自己调自己；

大哥一想也摇头，再清楚需要哪些参数，怎么接转传，代码没法一遍过。

 

一般来说，递归函数需要关注的无非就是，一层过，两层过，层层过，这3个阶段。然而，现实情况是，往往错的不是递归本身，而是其中的业务方法。而由于递归函数往往伴随着上下文的传递，以至于单独对特定实例业务方法的断点行为缺乏意义，最终还得回归递归方法本身，结合参数与实际业务一起考虑，那就讨厌了。

 

举个例子，如果所有原材料都有各自基于数量的阶梯价格，而这个数量在递归函数中是通过自身物料明细的数量（3） 及 当时的上下文系数（2）来共同决定，那甚至哪里错了都不能定位了。

成品=>半成品*2； 半成品=>原材料*3；

成品=>原材料*2*3；

 

某种程度来说，原材料价格表的方法最终会接到的这个数量6。如果与期望不符，它最好2*3中的3错了-_-||（但愿吧，祈祷）

 

综上所述，递归不是重点，调试才是。而且我不会为了调试而递归。我会为了面试而递归。

 

回归正题（简单问题），如果有这样一个 包含多层bom的成品，我会姑且将它每一层的展开结果视为一个这缺那缺的扇形图。那么基于每个bom节点的递归方法，无疑就是从最左至右进行扫描，将原来一个空有轮廓的扇形图一笔一划的填充而已。以我多年填充图形的经验来看，在我画完最后一根竖线的那一刻，我就画完了。

 

等等，别忘了还要自测和调试。我可看不清每个节点跟其他节点的关联关系，但起码我能一眼看出这个复杂结构到底有多少层。

如果可以竖着画，那我就来试试横着画。

 

基于常识而言，我必须画完倒数第二层才能花最后一层，推导回来，我必须先画完第一层，才能去画第二层。让我们来看最后一层需要画成什么样吧。

如果我把最终的结果以 {原材料:数量} 的形式来定义（用来合并重复原材料所需要的数量），那它必然需要[(原材料/半成品，数量)]的支持（即便这个概念只在程序运行时有所体现）。推导回来，我们的第一层也需要以这样的形式传递给第二层。

 

问题是，第一层既不是原材料，也不是半成品啊？话说回来，第一层不就是个点吗，哪来的层？

现实逻辑告诉我，当老板/客户需要的时候，它就是原材料/半成品，它就是一层。

因此，我们将从第一层的[(成品，1)]，慢慢推导至最后一层的[(原材料，数量)，(原材料，数量)]

 

说白了就是在while True里面通过bom进行数据映射（也方便卡断点），仅此而已。写过的都说好。好！

 

最后来归纳一下中心思想吧，关于递归

低情商：你写的很好。

高情商：下次别写了。