加入新功能时，可能须要添加各层的接口，接口怎样加？必定须要向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的实现。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvSG9ya3lDaGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center” alt=”” />
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就是一个要求上层类实现的接口类:
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvSG9ya3lDaGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center” alt=”” />
这是一个命名比較奇特的样例。在命名上注意client/delegate表示对外部业务逻辑依赖较重。而observer则表示逻辑上不存在对外部业务的依赖，不过通知。
3. 以独立的方式扩展既有接口
假设是对既有功能的直接扩展，且无法分离成新的接口，则能够尝试使用例如以下方法扩展: a. 继承旧的接口或使用装饰器、组合等模式扩展接口功能。 假设接口本身未定义上的兼容性需求，上层模块能够依据须要选择使用新旧接口。就能够使用这个方式。 WebViewClient能够近似看作一个演示样例： 
b. 封装到旧的接口中 (如组合，Helper class等方式) 假设接口须要保持兼容性，接口的定义不能改动，只能改变其行为，就能够应用这样的方式。变更对上层模块透明。
4. 改动原有接口
最后才干选择改动原有接口，但不建议直接改动接口函数定义，而是以新增接口函数的方式来实现。假设使用C++实现，还应当将实现文件独立出来。
转载请注明出处: http://blog.csdn.net/horkychen
