加入新功能时，可能须要添加各层的接口，接口怎样加？必定须要向Chromium的原则看齐。
首先Chromium的模块设计遵循依赖倒置原则，上层模块依赖于低层模块。低层模块不会依赖上层模块的实现。
再者要区分添加接口的两种目的:
1. 提供功能供外部使用 (一些以功能定义的接口属于这类，如WebView,NavigationState等 )。
2. 同意将一些业务逻辑在外部实现 (命名中带有client,observer或delegate属于这类)。
除了命名上不同外，能够參考的实现方式也不同。
1. 使用IPC Message Filter
Chromium为了避免加入新功能时使得接口类”膨胀”，特别提供了一系列的Helper (Observers)。
当须要实现新功能时，能够通过这些observers，过滤IPC消息。实现自己的功能。
假设新功能能够向外派发或接收IPC消息完毕通知或回调功能，则优先使用IPC Filter的模式。
Renderer进程中实现RenderViewObserver接口能够接收处理RenderView上的IPC消息。ChromeExtensionHelper是一个用来监控Frame载入及关闭的演示样例。
假设有一部分代码在WebKit里，不要直接扩展WebViewClient, 能够定义一个新的接口给WebKit调用，然后在Render端的实现。
能够參考WebAutoFillClient的实现。
Browser进程中通过实现WebContentsObserver的方式过滤IPC消息。
详细的做法能够參考TabHelper。
WebKit模块等其他类消息
能够通过实现BrowserMessageFilter接口，在RenderProcessHostImpl::CreateMessageFilters()再将其加入到Filter列表中(render_process_host_impl.cc)。
假设一个功能须要处理不同的IPC消息。就不要放在render_messages.h里了，应当放到独立的文件中。比方pepper_messages.h。
详情请參考:How to add new features
2. 提供独立的接口
假设功能相对独立，则能够在模块中添加新的接口提供出去。如blink模块中的非常多功能，以下是当中WebImageCache的类图:
假设须要外部实现某些业务逻辑，则能够使用观察者模式或者同意以继承的方式实现，相应提供一个注冊接口或接口类(interface)。
比方blink::Prerender须要外部定义实现blink::WebPrerenderingSupport时才有功能，这个blink::WebPrerenderingSupport就是一个要求上层类实现的接口类:
这是一个命名比較奇特的样例。在命名上注意client/delegate表示对外部业务逻辑依赖较重。而observer则表示逻辑上不存在对外部业务的依赖，不过通知。
3. 以独立的方式扩展既有接口
假设是对既有功能的直接扩展，且无法分离成新的接口，则能够尝试使用例如以下方法扩展:
a. 继承旧的接口或使用装饰器、组合等模式扩展接口功能。
假设接口本身未定义上的兼容性需求，上层模块能够依据须要选择使用新旧接口。就能够使用这个方式。
WebViewClient能够近似看作一个演示样例：
b. 封装到旧的接口中 (如组合，Helper class等方式)
假设接口须要保持兼容性，接口的定义不能改动，只能改变其行为，就能够应用这样的方式。变更对上层模块透明。
4. 改动原有接口
最后才干选择改动原有接口，但不建议直接改动接口函数定义，而是以新增接口函数的方式来实现。
假设使用C++实现，还应当将实现文件独立出来。
转载请注明出处: http://blog.csdn.net/horkychen