关于解耦合的一个现实例子：

“跟大部分餐饮企业一样，星巴克也主要致力于将订单处理的吞吐量最大化。顾客订单越多，收入就越多。为此，他们采取了异步处理的办法。你在点单时，收银员取出一只咖啡杯，在上面作上记号表明你点的是什么，然后把这个杯子放到队列里去。这里的队列指的是在咖啡机前排成一列的咖啡杯。正是这个队列将收银员与咖啡师解耦开，从而，即便在咖啡师一时忙不过来的时候，收银员仍然可以为顾客点单。他们可以在繁忙时段安排多个咖啡师，就像竞争消费者模式（Competing Consumer）里那样。”

解耦带来的好处是：①提高问题的解决概率；②提高问题的解决效果；③提高问题的解决速度；④降低将来爆发隐患的可能性。
这是一篇细究的文章如果只是为了知道一种能解决问题的方案那么就可以到此为止了，如果想了解解耦的好处是如何带来的那么，下面我们就细细分析一下：
例子里说的时将收银员与咖啡师解耦开的情况，那么解耦前是个什么情况？
解耦前，收银员与咖啡师是一个人，我们可以称之为万能的员工，他什么都干。当用户来了他负责收银，然后往咖啡机中放入饮品的材料，开动咖啡机等制作准备工作，等待，取出完成品递给顾客。当然机灵点的员工他会在等待时去让其他顾客下单然后记下，顾客下单然后记下，直到没有下一位顾客或者这位万能的员工记不下了，又或者第一杯咖啡做好了然后他往返于咖啡机与收银台之间，在这个例子里除了必要的收银时间和制作准备时间，往返于咖啡机与收银台之间的时间是不必要的。
当店铺很受欢迎时，大量涌入的顾客就会压垮这个万能的员工，然后顾客没有得到他们满意的服务，然后生意一落千丈，GAME OVER。我们需要在问题刚有苗头的时候做出改变现状的决断了，这个时候我有三种想法：①将咖啡机移到收银台旁边，让收银员转身就能制作咖啡，让往返的距离等于0，甚至然收银机和咖啡放在一起让转身角度等于0；②添加员工。③添加咖啡机。最终在大量顾客的压力下很有可能这三种想法都实现了，随着咖啡机的增多咖啡机们从收银台移到了收银台后面的料理台上，然后员工们又再次需要转身180°来往返了。然后多个员工使用这一个收银机，多个咖啡机归一个员工调配。员工们大量的往返于收银台和料理台又由此产生了一些交通问题。
当店铺很受欢迎时，你还有第二种选择让原来的万能员工专门负责收银，招收专门咖啡师，收银员收到订单，之间将订单打在小票上递给咖啡师，咖啡师收到小票制作咖啡，然后交由服务员送到顾客手上。然后咖啡制作压力巨大时增加咖啡师和咖啡机，收银压力大时添加收银员，小票传递压力大时改用传送带，传送带压力大时改用软件自动化。这样将万能员工身上的两项工作分离出来交给两种不同的角色处理，这就是解耦。解耦之后本来一个综合性的高效服务顾客问题就可以分解成三个小问题：①如何高效收银；②如何高效的制作咖啡；③如何高效的在收银和咖啡制作之间交换信息。这就是解耦带来的好处：简化逻辑，虽然一个问题分解成了三个问题但是问题难度下降带来的不仅仅是问题的解决概率和解决效果的提升，而且每次只用解决一个问题，这三个问题不会是同时发生的，只会在压力的提升下一次发生。在实际生产环境中的经验还告诉我：简化逻辑还能减少隐患，就比如未解耦的咖啡店中发生的交通问题就没有出现在解耦的情况下。

说点题外话:
我不知道这个例子最初是来自哪里，我只是在百度RESTful时在infoq这个网站上看到的，以前也没有见过这个网站。
但是这不妨碍我觉得这句话说的很对，以前从我听到的看到的消息，都在说解耦好解耦好，但是我从来都没有很明白解耦好在哪里。只是明白一个人不做两件事，一个小模块不做一个以上的事务处理。当我在设计代码结构的时候也是这么做的，并且将这个解耦作为说服别人的理由，告诉别人我充分考虑了解耦的问题，并且做到了几乎零耦合的高度。
然而我并没有深切的体会到解耦和带来的好处。自从我看到了这个例子，这个例子很有启发性，虽然例子里讲的不是很透，不经过我们再思考或者遇到一个初学者或许就不能理会例子的意思，但是这并不妨碍我的理解。上面我的解说就讲的很透知识密度也很低，不过这是对我来说的，很多对我来说当然如此的部分被我隐藏掉了，不过也不影响细心的初学者们理解。