重读COM技术内幕(inside com)有感

面向对象设计哲学在复杂领域并不能很好地解决问题。参考（http://www.richardlord.net/blog/what-is-an-entity-framework）。因此引入了面向接口的设计。微软组件对象模型就是这种设计的实现。当然，COM的应用绝对不限于Microsoft，而COM的底层架构也由于实现过于复杂带来很多性能上的问题。但是COM的思想的确有伟大之处。

动态决定一个对象能调用哪些方法是现今软件领域配置即服务的根本要求。对象不能固化；对象实现的接口也不能固化；对象从配置文件中读取配置以动态实现接口。这样一来，对象就是泛化的实体（Entity），接口如果称为组件（Component），那么组合优于继承，就是这个意思了。Entity包含了不同的Component，这样Entity就形成不同类型的对象或服务。而处理对象的流程（Process，也有称System）就是根据一定规则调用Entity服务的过程。这样一来，一切都豁然开朗了。

让我们再梳理一下思路。软件就是服务，这没错。服务就是一些部分（Component）的组合。每个部分完成具体的功能调用。组合这些部分（Component）就形成具有有种特性的实体Entity。所有Entity都应该具备查询是否支持某个Component的方法，于是IUnknown接口被抽象出来，作为所有Component都支持的接口（Interface）。Interface就是方法集合，暴露Component的功能。Component正因为具备了不同的Interface，于是成为特定的组件。Component包含数据和逻辑，而Entity组合他们。

注册表毫无意义。组件系统本身不应该依赖第3方提供的清单来发现。注册表机制的最大缺陷成为它日后被广泛攻击的靶子，最后是Windows最脆弱的部分，衍生出巨大的灰色市场。微软当初的软件哲学是封闭的黑盒子调用，所有要通过注册表机制来发现服务。某个功能既然有人实现了，就可以放到一个中心化的地方备案，然后调用者可以放心使用。这个哲学最大的出发点就是封闭。COM的衰落也是由于封闭导致。其实调用别人写好的组件并不是真正意义上的重用，这种仅仅靠数字签名没有任何保证的调用，会带来巨大的隐患。软件在工程领域真正的重用必然需要源码开放。软件本身应该成为闭包，不应该依赖系统过分的参与（脚本宿主除外）。

既然COM其核心思想如此通用，COM本来应该就是跨平台的，但是由于历史的原因，长久以来COM及其类库被绑定在Windows平台上。当然，现在看来，其核心类库已然不足取，完全可以自己根据这个思想灵活对待具体问题。

今天，使用高级语言Java, C++等开发的，鲜有不是面向接口开发的。在Java里，可以很容易判断一个对象是否实现了某个接口，在C++里，需要提供一个公共方法。面向组件开发的最大有点就是可以动态配置接口，引入脚本支持，比如lua，实现热部署，热替换，仅仅配置就可以实现功能了。今天重读COM技术内幕，10多年前的心境油然而升，当年是啃了一年啃出来的一本书，现在看来是那么轻松。当然，如果你是个新手，这本书可以看，但不要局限在微软对象模型上，重点是理解其思想，自己实现一个平台无关版本就可以了。取其精华，去其糟粕。