优化解耦的设计思考

╰半橙微兮° 2022-03-19 11:59 185阅读 0赞

基于开源项目进行开发已经越来越普遍，WebKit和Android都有很多的深度定制的版本。

对这样庞大工程修改的逻辑越来越多，日后想要同步升级就要面对更大的复杂性和风险。跟随开源项目同步升级，寻求上层的创新和优化才比较适合未来的产品开发策略。深度定制的方式会遭遇越来越多的尴尬。

修改是必要的，但如何最大化地降低耦合和隔离对原生代码逻辑的修改？逻辑碎片的风险也许大家都体会过。以下是我对一个问题的思考，与大家分享，抛砖引玉。

## 1. 问题定义 ##

首先交待一下当前的状况。  
1.有对WebKit原生内核中HTMLMediaElement修改的需求。  
由于实现的限制，导致了必须对HTMLMediaElement进行修改。

2. 不同平台的修改逻辑混杂在一起。  
在不同平台上的适配内容也不尽相同，所以其中有许多使用宏来区分系统的修改。  
  
问题就是有没有可能将这些修改的实现放到独立的文件中去，在HTMLMediaElement中只做少量的修改，最大化的减少对原生代码的修改？或者是有规则的修改。总之要便于和最新的WebKit代码同步。

## 2. 问题分析 ##

首先从设计上来看这个问题，可以将WebKit的实现视为核心逻辑，将我们的修改视为一个辅助逻辑或特殊逻辑。

这样就可以有一个设计上问题定义:把这部分逻辑从主逻辑中抽离的设计方法，但不改变原来的类的层次架构。  
  
继承并不合适。因为一部分HTMLMediaElement中的成员定义为protected，它本身已经被HTMLAudioElement和HTMLVideoElement所继承。还有对应的Render、JS Binding与它的对应问题。远不是在parser位置将video和audio对应的类改成新类就可以的, 而是需要更改到HTMLMediaElement的定义。  
  
 解决方案就是提供一个Helper类，如MediaElementHelper来处理特殊逻辑。

![1364829676_1110.png][]

## 2. 实现说明 ##

### 2.1 建构 ###

在HTMLMediaElement的建构函数中加入:  
m\_helper = MediaElementHelper::create(this);  
 不同平台可以使用相同的类定义，但实现不同。

### 2.2  相互调用 ###

helper又为HTMLMediaElement的友类,就可以访问HTMLMediaElement的私有变量，或者执行私有成员函数。如果认为这样风险高，也可以像下面这样专为helper增加一些访问私有成员的接口。  
   ![1364829706_7438.PNG][]  
这样在需要进行特殊逻辑判断和处理的地方，就使用m\_helper来调用执行。具体的行为则在不同的helper类中实现。

## 3. 评估 ##

关于helper的使用一直是有争议，网上也有很多避免使用helperclass的讨论。主要论调在于认为helper class是过程化的产物，思考时是考虑的是流程上的逻辑补充。虽然在目前场景下，这也算是一个解决方案，但不是最佳方案，因为这些做同样增加了设计的复杂性。

参考: [ 自然而然的设计][Link 1]

[WebKit模块化分析][WebKit]

转载请注明出处: [ http://blog.csdn.net/horkychen][http_blog.csdn.net_horkychen]

[1364829676_1110.png]: https://img-my.csdn.net/uploads/201304/01/1364829676_1110.png
[1364829706_7438.PNG]: https://img-my.csdn.net/uploads/201304/01/1364829706_7438.PNG
[Link 1]: http://blog.csdn.net/horkychen/article/details/7969443
[WebKit]: http://blog.csdn.net/horkychen/article/details/8462574
[http_blog.csdn.net_horkychen]: http://blog.csdn.net/horkychen