sillydaddy

如果你仔细观察那么多设计模式，会发现它们基本上都是在讲一件事：接口的抽象、分层、去耦合， 就像 #26 楼 @NoOneNoBody 说的。把这点仔细研究研究，就豁然开朗了。

举几个例子，

「观察者模式」： 某个对象变动了，通知其他对象（或者说其他对象观察某个对象的变动）。 这种“一变动就通知”的机制，主要用于底层对象向上层对象发送通知，对于这些通知，无论上层对象是处理还是不处理，无论上层具体怎样处理，都跟底层对象没有关系了。所以观察者模式，其实是将底层对象的向上通知这种（接口）行为统一抽象出来了，而且去掉了底层与上层的耦合。
「访问者模式」：将被访问的数据结构的遍历抽象出来了，上层要访问某个比较固定的数据结构的时候，不用每个访问者把遍历这个数据结构的代码都重复写一遍，只需要写出来对该数据结构如何具体操作，遍历这个数据结构的过程已经被“访问者模式”抽象和剥离出来了。像 C++ stl 的迭代器也可以算是非常典型的访问者模式，只需要 iterator++就可以，不用关心底层是 vector 还是 list 。
「工厂模式」：这个就更直接了，传给工厂一个不同的参数，生成一个与之对应的实例，并且这些实例都实现了一个相同的接口。具体生产哪个类的实例不需要关心，唯一需要关心的就是，传入一个不同的参数，得到同一个接口的不同实现，经过这种抽象后，工厂模式对外呈现出一种极为简洁的形式：不同参数->接口的不同实现。


所以学习的时候，只要仔细留心接口是怎样抽象的，接口抽象出来后，达到了什么目的和效果，就可以了，不用特意记各种设计模式，死记也记不住。

@meeop 前面提到的周转资金，可以从另一个角度考虑：
如果一个商家，每天卖出 100 件商品，商品总成本 10000 元，第 2 天可以收到付款。这个商家的库存里面，总是保留用于第 2 天卖的，与第一天卖的 100 件一模一样的商品。也就是说这个卖家只需要投入 20000 元，就可以维持它的生意不断，它库存与销售比是 2：1 。
如果使用押金模式，那么它需要 10000*10+10000=110000 元才能维持，也就是资金利用率只有原来的 1/5 左右。
如果扩大商家的库存销售比，比如扩大到 10:1 ，资金利用率也只有 1/2 。
所以这种高押金模式，对于商家/工厂来说，资金利用率是很低的。如果它的资金中有 50%是贷款，贷款利率是 4%，原本它的 6%的利润率就足够，如果它的资金利用率只有一半，那么它的利润率就要提升一大截才行。

@meeop 我想到了一个可能的问题。
如果双方的目的是交易，那么感觉这个方案非常合适。
但是，如果其中有一方的目的不是交易，而是借助这个机制进行攻击呢？
下面介绍这种通过耗尽对方资金进行的攻击方法，我把它叫做“榨汁攻击”：
如果有一方是专门通过出售商品获利的，那么它所拥有的资金一般总是充分利用的，甚至有些资金还是通过借贷获得的。也就是说，它的资金几乎全部用于商品的周转。这时，如果有大体量资金的对手针对它发起大量交易并拖延交易的达成，那么只需要十分之一的交易量就能耗尽它的资金。一方资金耗尽的话，就完全失去了继续盈利的能力，也就丧失了谈判的筹码。
对于闲鱼二手交易，如果某个专职卖家中的买方中有二十分之一的人采用榨汁攻击，那么会导致占用该卖家的 50%的周转资金。而这些资金很可能只占用买家的很小一部分。这种明显的优势可能会促使买家结盟，构成所谓的 DDOS 攻击。

这么好的方案我咋没想到呢！等待高手来破解。
@cnkuner 的挑战和 OP 的回复都很犀利，看着过瘾。

感觉这像是一个无法证明答案的问题。

#10 楼说的很清楚。主版本号升级，通常意味着不兼容。这个平时一定要注意。
不过锁死了主版本，可能会锁死一大批依赖它的库的版本，也挺麻烦。

附言里的“这么多人乱喷”，“世界太缺乏诚信的人”，这两句是什么因果关系？

@lurui45 #203
你这样说反而更证实了为啥老丈人要把钱要回去。

原本老丈人自己出钱买车自己开，心安理得，谁的人情也不欠。置换后，自己本来出的钱变成了不清不楚的 0.4 辆车，而自己要开的还不是这 0.4 辆车，而是在别人看来是配置拉满的豪车，反而倒欠了别人人情。

索性把这不清不楚的 0.4 辆车的钱要回来，欠就欠个整人情。

用数学来解答这个问题非常简单，
置换前：老丈人出资为 1 ，实际使用为 1 。
置换后：老丈人出资为 0.4 ，实际使用为 1 。

置换前，无论车给谁用，老丈人出资大于使用，有底气；
置换后，老丈人只占了不到 0.5 辆车的出资，开着 1 的车，出资小于使用，怎么都别扭，而且经过楼主一折腾，莫名其妙少了 0.5 的出资，心理也不会平衡。
世界上没有 0.5 的车。