“你好，阿米戈！我希望你能了解 OOP 的用途。我会给你讲一个故事。”
曾经，有一家小公司，专门向外太空运送货物…
“和银河系狂奔号一样？”
“是的，和银河系狂奔号一样。公司里有 5 个人。第一个人负责财务，第二个人负责仓库，第三个人负责运输，第四个人负责宣传，而第五个人负责监督其他四个人。”
他们非常努力，精力旺盛。公司的声誉很好，挣了很多钱。每年订单都在增加，所以 CEO 需要招聘更多的员工。其中，有几个是负责仓库的，有几个是负责运输的，还有一个出纳和一个市场营销人员来提高销量。
问题也由此引发。公司里的人越来越多，他们开始相互干扰。
市场营销人员把所有的钱都花在新的广告宣传活动上，导致公司手头没有现金来采购急需发运的货物。
仓库里有 10 箱每月发运一次的全新超光速推进装置。每个运输员只能运一台超光速推进装置，导致另一个客户订的 10 台超光速推进装置又被延误 1 个月。第一个运输员根本不知道第二个运输员正在完成另一个订单。
新任的 CEO 助理派了一个运输员开飞船去采购货物，一切都得等另一架飞船回来才能运作。公司积压了很多订单急着发货，但是这名助理只管采购，并且竭尽所能把这件事做好。某个人职责履行得越到位，对别人的干扰就越大。
分析情况后，CEO 意识到飞船、现金和货物等重要资源的使用并没有达到最优化，而是以“先到先得”的方式在被应用。任何人都可以利用这些资源开展他们自己的工作，进而影响其他同事和整个公司的生产效率。
改进措施势在必行。CEO 决定把整个公司划分成不同的部门。他创建了运输部、市场营销部、采购部、财务部和仓储部。现在，没有人可以随便开走飞船。运输部主管会收到所有发货信息，哪个运输员的订单对公司而言最有利润，飞船就派给谁。同时，仓储部并不会让运输员直接取走货物。仓储部控制着流程。如果财务部知道马上要采购，就不会把钱划给市场营销部。每个部门都有一个公共人物：部门主管。部门内部的架构由各部门自己决定。如果运输员想要取走货物，他要去找仓储部经理，而不是直接去仓库。新的订单来了，会先发给运输部主管（public 人物），而不是运输员（private 人物）。
换句话说，CEO 将资源聚集在一起并按部门行动，通过部门的内部结构，禁止部门间相互干扰。大家都只能联系特定的人员。
用 OOP 的话来说，这就好比把一个程序划分成不同的对象。一个包含不同功能和变量的庞大程序，通过这种方式，转换成一个由不同对象组成的程序。而这些对象则包含不同的变量和功能。
“稍等一下。你是说，问题的症结在于员工可以不受限地获取资源，并且可以向任何其他员工下达命令，对吗？”
“是的，正是如此。
“真有趣。虽然引入了一些限制，但却获得了更多的订单。他们可以对一切保持更好的管控。”
“对。用它最纯粹的方式分而治之。”
“正如你所言，分而治之。这一点我们要牢记。”
GO TO FULL VERSION