基于开源项目开发已经越来越普遍。WebKit和Android都有许多深度定制的版本。这么庞大的项目，修改的逻辑越来越多，以后如果要同步升级，将面临更大的复杂性和风险。跟随开源项目的同步升级，寻求更上层的创新和优化，更适合未来的产品发展战略。深度定制的方式会遇到越来越多的尴尬。修改是必要的，但如何最小化耦合并隔离对原生代码逻辑的修改？可能每个人都经历过逻辑碎片化的风险。以下是我对一个问题的思考，分享给大家，以期对大家有所启发。1.问题定义首先说明现状。1、需要修改WebKit原生内核中的HTMLMediaElement。由于实施限制，必须修改HTMLMediaElement。2、不同平台的修改逻辑混在一起。不同平台的适配内容也不一样，所以很多都是用宏来区分系统修改。问题是，是否可以将这些修改的实现放在一个单独的文件中，只在HTMLMediaElement中做少量的修改，从而尽量减少对native代码的修改？或者有规则的修改。总之，很容易与最新的WebKit代码同步。2.问题分析首先从设计的角度来看这个问题。我们可以把WebKit的实现当作核心逻辑，把我们的修改当作辅助逻辑或者特殊逻辑。这样，就可以有一个设计问题定义：将这部分逻辑从主要逻辑中分离出来，但不改变原有类层次结构的设计方法。继承是不合适的。因为HTMLMediaElement的一些成员被定义为protected，所以它被HTMLAudioElement和HTMLVideoElement继承了。还有对应的Render、JSBinding及其对应的问题。远不是在解析器位置将视频和音频对应的类更改为新类，而是需要更改为HTMLMediaElement的定义。解决方案是提供一个Helper类，比如MediaElementHelper，来处理特殊的逻辑。2、实现说明2.1构造在HTMLMediaElement的构造函数中加入：m_helper=MediaElementHelper::create(this);不同的平台可以使用相同的类定义，但实现不同。2.2调用helper成为HTMLMediaElement的好友，可以访问HTMLMediaElement的私有变量，或者执行私有成员函数。如果你觉得这个风险很大，你也可以添加一些接口来访问helper的private成员，如下。这样，在需要特殊逻辑判断和处理的地方，就使用m_helper来调用执行。具体行为在不同的帮助类中实现。3.评价helpers的使用一直存在争议，网上也有很多避免使用helperclasses的讨论。主要论点是helper类是程序化的产物，思考时考虑了对流程的逻辑补充。虽然这是目前场景下的解决方案，但并不是最好的解决方案，因为这也增加了设计的复杂度。原文链接：http://blog.csdn.net/horkychen/article/details/8749050
