其实，很多移动平台都号称是面向组件编程，不过他们所谓的面向组件的层次其实是不同的。
首先我们看Android，它在设计思想，解空间模型上的确是面向组件的，它将进程，application的边界模糊化，而独将组件的边界凸显化，从而提醒开发者，是基于组件的开发思想。 不过，其实对于android，不管是app level的开发，还是framework，还是native level，coding层次的确是没有面向组件的。你可以大量的看到类的暴露和类的复用。 而并不是所有的组件实现对外隐藏，仅仅暴露接口而已，客户基于接口编程，而对组件的实例化完全交给工厂。 当然，android如此设计也有其初衷，他毕竟可能是希望使用面向对象的“实现继承”的强大功能来复用，并简化客户程序的开发。 所以，放弃了纯粹的“接口继承”。 不过，抛开这一点，确实非完全的面向组件体系的实现显得相对分散而凌乱，类的继承的爆炸更加使得代码不清晰。
我们再来看看Qualcomm自己的BREW/BMP， 虽然他并不是智能平台，影响也不是那么大，但我一直觉得BREW/BMP的设计者的理念还是非常的“潮”的，你不得不承认，BMP/BREW的确是一个完全面向组件的系统。而且还是基于C实现的。 他借鉴了COM思想，然后使用高效的C语言，在资源受限的移动平台上，大部分实现了COM（至少将COM的精髓都实现了）。 这样一个平台，一切的服务都基于接口，客户永远只能基于接口使用服务，而组件的实例化完全交给了工厂（Ishell_CreateInstance）。这样使得客户和服务的关系，从代码和二级制层次均完全解耦，所以类似运行时的服务热插拔，以及服务的动态加载都均水到渠成。 对于初识BMP/BREW的程序员，可能会感到比较晦涩，但是，一旦理解了他的组件体系思想及其实现，则会感觉豁然明朗，一切均开阔而清晰。 不像Android，初识感觉很亲切，Class的继承多么的熟悉，但是，当你深入之，就会显得晦涩而苦味。
首先我们看Android，它在设计思想，解空间模型上的确是面向组件的，它将进程，application的边界模糊化，而独将组件的边界凸显化，从而提醒开发者，是基于组件的开发思想。 不过，其实对于android，不管是app level的开发，还是framework，还是native level，coding层次的确是没有面向组件的。你可以大量的看到类的暴露和类的复用。 而并不是所有的组件实现对外隐藏，仅仅暴露接口而已，客户基于接口编程，而对组件的实例化完全交给工厂。 当然，android如此设计也有其初衷，他毕竟可能是希望使用面向对象的“实现继承”的强大功能来复用，并简化客户程序的开发。 所以，放弃了纯粹的“接口继承”。 不过，抛开这一点，确实非完全的面向组件体系的实现显得相对分散而凌乱，类的继承的爆炸更加使得代码不清晰。
我们再来看看Qualcomm自己的BREW/BMP， 虽然他并不是智能平台，影响也不是那么大，但我一直觉得BREW/BMP的设计者的理念还是非常的“潮”的，你不得不承认，BMP/BREW的确是一个完全面向组件的系统。而且还是基于C实现的。 他借鉴了COM思想，然后使用高效的C语言，在资源受限的移动平台上，大部分实现了COM（至少将COM的精髓都实现了）。 这样一个平台，一切的服务都基于接口，客户永远只能基于接口使用服务，而组件的实例化完全交给了工厂（Ishell_CreateInstance）。这样使得客户和服务的关系，从代码和二级制层次均完全解耦，所以类似运行时的服务热插拔，以及服务的动态加载都均水到渠成。 对于初识BMP/BREW的程序员，可能会感到比较晦涩，但是，一旦理解了他的组件体系思想及其实现，则会感觉豁然明朗，一切均开阔而清晰。 不像Android，初识感觉很亲切，Class的继承多么的熟悉，但是，当你深入之，就会显得晦涩而苦味。
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货