在brighten接口的实现中包含了对于外部对象的依赖，那么很糟糕，客观事物之间的关系将完全失去控制。试想，电灯泡接收到变亮消息的时候要去检查电网的电压，电力软件开发过程中，先要搭建软件框架，然后才能决定自己的参数（静态信息）吗？不，这很难让人接受。

另外，如果对象中真的包含依赖外部对象的行为，换句话说，按照对象可以接收的请求都应该封装在对象中的逻辑，那么，在保险业务中的一个代理人，将会有数量庞大的接口。在这种情况下，代理人接受到请求，不仅仅是修改自己的状态，还要去通知其他对象去计算保单的保费，去计算自己的佣金。这些原本应该是外部的数学规律（牵涉众多对象的静态信息和动态信息），却被收进了代理人对象的行为集。我认为这种依赖是不合理的。 

如果对象的行为不依赖于其他对象呢？那也没有什么太大的意义。对象本身状态（静态信息）的变化，应该由外部环境（数学规律）来决定。电网的电压和电灯泡自身的功率，决定了电灯泡的亮度。如何决定呢？需要通过动态信息（数学规律）。 静态信息是客观事物的一个状态，

这很好理解。而理解动态信息则比较困难一点。在我看来，电力软件开发的动态信息是对行为的认识，是具有驱动状态转换能力的数学规律。听上去有点抽象，对吗？举个例子，我们想想驾驶这个行为。 驾驶行为是动态的、有规律的。当驾驶摩托车时，需要左脚换挡、右脚刹车、右手控制油门把手；当驾驶手动挡轿车时，需要左脚控制离合器、右脚控制油门和刹车、右手换挡，油门把手或油门脚踏用力多少、决定了机动车的速度，而刹车脚踏用力多少决定了刹车距离的远近。 

我们看到，电力软件开发的动态信息（驾驶行为）离不开静态信息（机动车）的参与。和静态信息不同，动态信息关注的是如何使用手脚，以及用力的大小。 除了手脚的方位和力量等静态信息之外，对于驾驶行为来说，手脚的协调是属于数学规律的范畴、是动态信息，而手脚的方位和力量属于行为中的静态信息。 综上所述，我认为，如果一定要区分，那么项目协同软件的对象应该有两种：一种是只具有静态信息的对象，也就是通常所说的实体对象，或者说是Martin Fowler所谓的贫血对象；一种是同时具有静态和动态信息的对象，它尝试描述驱动静态信息状态变化的数学规律，例如，驾驶行为，它可以使摩托车、轿车、飞机、轮船等的状态发生变化。