[设计原则] 保护自己之我评

原来的博文参见 [设计原则] 保护自己

我在回复中主要说明以下的问题

首先作者想声明“从业务逻辑来看SNMP Agent相对的稳定，因为它只是翻译收到的SNMP消息并最终调用Box库中的函数完成消息的处理，而Box库会因业务的演进而频繁地变动...将前一方案中SNMP Agent直接调用Box库函数的形式转化成了通过进程间通讯将这一调用发送给Proxy进程，Proxy进程再通过FDR接口调用Box案”

于是乎我们有了这样的构想

 

SNMP将自己的责任委托给Agent，Agent则需要一个FDR的对象替他工作。由于Box是第三方的库，为了隔离以便于部署到其他地址空间，我们创建了一个Proxy。对于Agent最简单的方式就是Proxy也是同样签名（FDR）。这是最自然的，因为Agent不知道到底是哪一个FDR此时真正的实现。Proxy同样仅仅是委托给Box。（再想想我为什么要Proxy同样有FDR签名？呵呵）

再看看如何部署

 

所以我说你的图2有问题。首先作为一个architect，不要试图在一个视图里面表现很多东西，例如你的图2，将逻辑视图和组件部署混在一起。这样就有了Agent实现IPC接口而Proxy依赖于这个接口。这是完全混淆的。实际上你仅仅想表达Agent与Proxy是通过IPC通信的，分别部署在两个进程。实际上的逻辑依赖关系是Agent依赖Proxy，因为Proxy在能将Agent的请求委托给Box。实际的功能/职责只有Box实现。

 

我之所以说“It is a idiom. But it can not be used widely. I mean you have increase the maintainability but how about the performance, how about the resource consume? Considering if you have bought 10 modules from 3rd, you create 10 process to be "only-proxy", it might waste more.”

比如在一个手机平台就会有很多第三方的库，例如Android SQLite，OpenGL，WebKit...如果你的这种方式运用在一个平台上，试想会有多少个浪费的Proxy进程。所以我表明了这种方式不能被广泛应用。你可以作为临时的方案但是不能作为发布的方案。

 

最后同样提醒其他的Architect/Designer/Developer，不要试图在一种类型的视图里面混淆另外的视图的信息，这样只会越来越乱。

事不说不明，博客不评不显。