得墨忒耳定律（Law of Demeter）

前阵子在微博上看到有人在说软件架构的东东，以前也没接触过，就放狗搜了一通，想简单了解学习以下。

这种新东西， 一般都是先找 PPT 看以下浓缩的大概，然后就找到了这这篇 PPT：

4+1 View Model of Software Architecture

在这篇 PPT 里看到了 Garlan and Shaw`s Architecture styles 这句话，然后又放狗搜。

找到了这两篇文档：

1. Garlan and Shaw describe several architectural styles for software.pdf

2. An Introduction to Software Architecture.pdf

在第一篇文档里看到了 Law of Demeter,然后继续放狗搜，学习了一下。

解耦合手段之四：Law of Demeter 这篇文章是搜到的， 写的不错， 解决了一些疑问， 在此感谢作者。

其实就是“最少知识原则（Principle of Least Knowledge）”，是一种软件开发的设计指导原则，在面向对象软件设计种用的较多，效果很好。得墨忒耳定律是松耦合的一种具体案例。使得软件更好的可维护性与适应性。因为对象较少依赖其它对象的内部结构，可以改变对象容器（container）而不用改变它的调用者（caller）。

这个就好像一个企业里最有效率的团队成员之间各自努力干着自己的事情：

不相关的不扯淡，弱相关的少扯蛋，尽量减少强相关。避免不必要的干扰和恢复中断之前状态所需要的成本。

这里包括心情成本，时间成本。。。

软件的各个模块之间也是同样的道理，尤其是越大的系统越要注意。

不仅仅是软件， 硬件也遵循着同样的道理。 一点点感悟， 尼玛， 又要开会了。 本来还要写点的。 卧槽。。。

====================会=======后========吐=======槽=============================

我靠。 开会决定了。临时让我加入联/网/平/台项目。 这下好了。

ED137五个产品，ED137标准文档， F4核心板，C919模块，这又加了个联网平台，无语。

乱七八糟的管理！

项目之间耦合严重啊。。。懂不懂？人的精力是有限的，识得唔识得啊？不要拉出来来回溜行不行？

图样图森破,萨么塔么拿衣服!

搞了快一年了，当初拍脑袋火急火燎的上马，功能需求都没有定义清楚，设计仓促决定。

后面一边改一边重新确立功能，现在烂摊子，让我们擦屁股。。。

统共就四块板子，结果硬件回来几个月了。还没有确定硬件是否可以用。。。

摔。。。玩我呢？还是逗我呢？

我虽然是新手，但是我也知道，一个新产品，既然客户的需求定义的少，也不知道要什么，我们是不是应该先捡常用的功能先期做出一个能用的简化版的产品？别贪多，想一次性把后面要升级换代时候的功能也加进来，一劳永逸，这不扯自己蛋吗？

涉及到硬件的研发，能像软件开发一样迭代进行吗？开板不要钱啊？看着那些浪费的板子，心疼啊。

日。懒得说了。瞎管理，怪不得产品各种问题频出。。。还不思悔改。简直了。

让我负责就少特么瞎掺和瞎指挥。失败了我负责。你掺和了算什么事？有没有职业节操？