好的管理的一个重要特征是对职位进行管理，而不是针对人的管理。

  我一直认为，很多道理都隐藏在我们的周围，只不过我们没有认识到罢了。在这里我先从一个简单的故事开始。这个故事我已经在很多场合讲过。在找到更好的故事之前，我将一直用它。
    我说的这个故事的名字叫“总经理与秘书”的故事。这里没有任何桃色新闻，这点恐怕会让某些人失望:)。
    上海的一家公司的总经理A明天需要到北京参加一个非常重要的会议，他叫过来自己的秘书B吩咐道:“B小姐，请帮我订一张明天早上9点到北京的机票。”
    第二天，A总经理来到公司向B秘书拿机票，B秘书回答道：“昨天机票没有订到”。A总经理勃然大怒：“你知道这个会议对公司多么重要吗？”。A总经理严厉的斥责了B，随后暗暗发誓等回来一定要换一个秘书。
下面我们将从软件的角度分析这个故事。
    这个故事出现了两个类总经理A和秘书B，由于是A订票需要B的协助，所以可以画一条箭头从A指向B的线，如图1。

    结果类A就知道类B的很多细节，任何A向B发送消息的执行结果都应该由A检查。显然，这并不符合现实情况，这样的总经理活的也太辛苦了。因为他吩咐手下要做的每一件事都需要他自己关注执行结果，一旦关注不到位就可能出乱子。所以，现在很多老总都希望自己的员工读一读《给加西亚的信》这本书。但事实上给加西亚的送信的员工一定是一个稀缺资源，请这样的员工，工钱一定不会少。所以“加西亚”只能用在关键的、确实需要的岗位。

    那么这样的模型有问题，我们可以改进一下，如图2。在这个图上，增加一条从B到A的箭头。B和A之间关系更加紧密。让我们将这个模型放在这个故事中看看结果如何。在A发出一个订票消息后，B及时把订票的每一个进展都向总经理反馈，如果订票顺利也就罢了，可是一旦过程中出现问题，总经理一定会备受骚扰。一旦公司中所有的员工都是这种勤汇报的人，那么总经理的辛苦程度一定不会比上面情形中的总经理差。
    从软件设计角度来看，这种双向联系的这两个类之间是强耦合的关系，不是特殊原因尽量避免。因为既然两个类需要互相知道，为什么不合并成一个类了？
    两个图都否定了，看来没有办法了。这时候向大家隆重介绍软件设计的一个非常重要的原则(请鼓掌)。
“依赖倒置原则(DIP)”。
* 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
* 抽象不应该依赖于细节，细节应该依赖于抽象。[1]
    好，根据这个原则我们可以得出正确的结构见图三。这里面引入了一个新的类，即服务于总经理的秘书类。还是用这个“总经理与秘书”的故事来分析，这个结构为什么能解决问题。总经理A根据自己能开出的工资条件定下了秘书职位（注意，是职位，不是秘书）的职责和工作程序。这样，秘书B对遇到正常情况，都能依据公司的规范来正确处理。只有遇到异常情况才向总经理报告，这个异常情况很快也将补充进新的规范之中成为正常情况。

    所以，好的管理的一个重要特征是对职位进行管理，而不是针对人的管理。回到软件设计。我曾经说过，接口的集合就是架构，而架构在整个软件中无处不在。作为一个想成为架构设计师的程序员来说，“依赖倒置原则”的运用是一个好的起点。