添加新功能时，可能需要增加各层的接口，接口如何加？必然需要向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_internal.h里了，应当放到独立的文件里，比如pepper_file_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