在文章開始之前。我要叽歪几句，一上来就看Chrome的代码。简直晕头转向，摸来摸去莫不着头脑，好不easy看了一点点代码。却犹如瞎子摸象。无法众观全局。以下这篇小文，简介当中一个重要的模块--Component的设计，为我们阅读Google的代码打开思路。
概述
Chrome浏览器组件是一个google的一个项目。它用来不断的模块化Chrome的代码。
把整个content模块从src/chrome文件夹下抽取出来，虽然组件项目付出了不少努力，到眼下为止，这个文件夹(src/chrome)仍然是最大的互相依赖的模块。
因此，抽取src/chrome子模块仍然是google团队下一步的工作之中的一个。
目标
众所周知，Chrome项目在过去几年中，不管是代码还是复杂度都增长了很多。
对这个项目贡献代码的人员数量也添加了很多。并且。google也添加了很多目标平台以及配置，这些并没有在项目启动初期被他们预见到得到。对每一个人来说，要理解整个架构变得越来越难。更别说全部代码了。
Chrome浏览器组件项目引入了模块化并强制运行，目标例如以下：
- 按比例增大架构，使得浏览器更适合需求变更。比方：使用src/chrome/browser模块的浏览器希望关掉或者又一次实现某些模块。比方安卓上的Chrome;
- 通过进一步实现依赖关系图，我们想要实现的架构变得更清晰。
那些依赖规则指出哪些子模块是同意的。哪些是不同意的。 - 大大简化了src/chrome子模块的依赖关系图，使他们不循环依赖;
- 通过添加很多独立的组件比方单元測试可运行程序来加速开发人员的浏览器构建过程。
降低最大组件的连接时间。比如browser组件。单元測试程序更小了，这有利于大家用gdb调试代码。或者通过printf高速便利代码。 - 上面提到的方法应该能够降低大家的担忧、也让google团队更easy合作，使得架构更不easy误解，同一时候不easy写出不好的架构来，通常也会使我们更高效。
设计
概览
1 把src/chrome文件夹提取出一个个的组件。这些组件变成了一个个的目标，他们有自己独立的单元測试目标，明白指定他们的依赖。没有循环依赖。
2 没有循环依赖
指的是组件并不认识自己的使用者（embedder）--嵌入组件的模块比如src/chrome。假设组件须要获得自己使用者的信息和服务，他们能够在初始化的时候获得。或者执行时通过抽象的client接口获得。这个client接口由组件定义、使用者(embedder)来实现。
3 组件在哪里？
在src/components/的子文件夹里。
- 注意: 一些模块更像一个抽象层--比方src/content、或者更像一个产品--比方src/chrome，这些模块应该有自己的顶级文件夹，而不应该放到src/components文件夹下。
4 Client接口在哪里?
他们的声明在每个组件里，而实如今组件的使用者那里。
5 组件有必要提供API给组件的使用者调用吗？
A: 通常说来。例如以下使用方法是没问题的：组件的使用者採用C++类的详细类来使用组件。这样的情况下，API是非常easy的，不管组建类是什么--组件收到指针。实现来自使用者的托付接口。某些情况下，google引入了全然抽象的API给组件的使用者调用，这些API隐藏了组件的实现细节。就像他们给src/content组件做的一样。
某些其它情况下，他们给组件的C++详细类分分类，一部分分到内部类，一部分分到public类里。不管是内部类还是外部类，他们都应该存在于组件文件夹下，比如：src/components/mycomponent/public/.
假设一个组件的public分类存在，组件的client接口应该存在那里。
部分參考：http://www.chromium.org/developers/content-module
本文属原创，转载请注明出处，违者必究
关注chromium群480089700。或者微信公众平台:程序猿互动联盟(coder_online)，你能够第一时间获取原创技术文章，和（java/C/C++/Android/Windows/Linux）技术大牛做朋友。在线交流编程经验。获取编程基础知识，解决编程问题。程序猿互动联盟，开发者自己的家。
