锁定老帖子 主题:框架的侵入性问题是不是一个伪问题?
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2006-12-12
问题是,真的吗?号称non-invasive的框架就真的不对你的代码有侵入性吗?我们又真的会因为侵入性损害系统的“灵活性”吗?即便我们需要“替换实现方式”这样的灵活性,我们利用过这种灵活性吗? 总而言之。做为一个新手,我认为框架的侵入性问题,看上去很像一个伪问题。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2006-12-12
主要是看能不能方便的进行单元测试,高侵入性的框架下面写的代码单元测试起来很困难。例如对比Struts和Webwork就可以知道。
|
|
返回顶楼 | |
发表时间:2006-12-12
啊,了解了。那侵入性就是相对是否易于“脱离容器”测试而言的。和是否易于替换成另外一种实现方式无关。那么是不是要把两种说法分开呢?经常看到有人把这两种关注点混为一谈,或者是我个人头脑中混为一谈了。
|
|
返回顶楼 | |
发表时间:2006-12-13
我认为没有必要区分。使用一个没有侵入性的系统,你写出来的东西自然就很容易测试,也很容易切换。
觉得“我们利用过这种灵活性吗“倒可能是一个伪问题了。如果没有为这种灵活性付出代价,还要质疑这个免费的灵活性? 侵入性问题一般对新手没太大影响,但是只要不是对新手造成了很大的学习成本,新手的意见就可以忽略了八? |
|
返回顶楼 | |
发表时间:2006-12-13
没有侵入性 -> 易于测试
易于测试 一定要 没有侵入性么? 我感觉实现易于替换这种灵活性束缚了框架作者。侵入性强,可以让东西做得更有想象力。特别是对于Java这种语言级别的trick支持少的语言,加上“侵入性”这个紧箍咒,框架作者很难腾挪。Ruby这方面问题就不大。你看人们为了能够给new出来的对象挂上一点东西,祭出AspectJ来在JVM上挂上一个ClassFileTransformer来达到目的。我换掉new不就行了么? |
|
返回顶楼 | |
发表时间:2006-12-13
taowen 写道 没有侵入性 -> 易于测试
易于测试 一定要 没有侵入性么? 我感觉实现易于替换这种灵活性束缚了框架作者。侵入性强,可以让东西做得更有想象力。特别是对于Java这种语言级别的trick支持少的语言,加上“侵入性”这个紧箍咒,框架作者很难腾挪。Ruby这方面问题就不大。你看人们为了能够给new出来的对象挂上一点东西,祭出AspectJ来在JVM上挂上一个ClassFileTransformer来达到目的。我换掉new不就行了么? 侵入性说的是问题分解度 分解的越清楚侵入性越弱 减低依赖也好像说的是这么一回事... 侵入性强对于想象力是有好处但是不是每个程序员的想像力都很高.... 比如我(我总是忘记哪些功能没写测试...) ......而且不用new可以提高很多资源的利用率... PS:我认真为这个问题可以给转到java区...非常有意思的讨论 |
|
返回顶楼 | |
发表时间:2006-12-13
taowen 写道 没有侵入性 -> 易于测试
易于测试 一定要 没有侵入性么? 我感觉实现易于替换这种灵活性束缚了框架作者。侵入性强,可以让东西做得更有想象力。特别是对于Java这种语言级别的trick支持少的语言,加上“侵入性”这个紧箍咒,框架作者很难腾挪。Ruby这方面问题就不大。你看人们为了能够给new出来的对象挂上一点东西,祭出AspectJ来在JVM上挂上一个ClassFileTransformer来达到目的。我换掉new不就行了么? 举个例子?怎么束缚框架了? |
|
返回顶楼 | |
发表时间:2006-12-13
框架的侵入性问题可以拿实际例子来说明:
A. IOC容器 1. Avalon采用Interface Injection,如果你采用这个框架做IOC,它的侵入性就是要实现一个接口 2. Spring和Pico采用Javabean setter或者Constructor injection,采用他们做IOC,侵入性就是要满足Javabean规范 3. 同它们相比,不需要interface,也不需要满足Javabean规范,无所不能的ajoo的IOC容器就是号称无侵入性 B. MVC架构 1. struts的侵入性是需要扩展它的一堆base class,以及写一堆带有http request/response签名的方法 2. webwork则只要是普通的javabean就可以了 做同样事情的不同框架,如果侵入性越低,通常框架本身的实现比较复杂,效率也比较低,也有可能把侵入性从Java对象的本身移到了其他地方(比如配置文件)。 |
|
返回顶楼 | |
发表时间:2006-12-13
ajoo 写道 taowen 写道 没有侵入性 -> 易于测试
易于测试 一定要 没有侵入性么? 我感觉实现易于替换这种灵活性束缚了框架作者。侵入性强,可以让东西做得更有想象力。特别是对于Java这种语言级别的trick支持少的语言,加上“侵入性”这个紧箍咒,框架作者很难腾挪。Ruby这方面问题就不大。你看人们为了能够给new出来的对象挂上一点东西,祭出AspectJ来在JVM上挂上一个ClassFileTransformer来达到目的。我换掉new不就行了么? 举个例子?怎么束缚框架了? 我把侵入性理解为对框架代码的依赖。进一步的,我们的代码要被框架调用,我们要调用框架的代码。在侵入性的要求下,系统中的知道框架存在的代码越少越好,对其他部分的设计产生的影响越少越好。我的假设就是如果低侵入性不光是为了好测试,还是为了“易于替换框架”。那么也就是说,框架本身不能对自己要回调的对象有任何要求,这种要求可能是继承一个基类,实现一个接口,遵守一个命名规范,标注一个Annotation。并且我们在调用框架的时候,还要封装一层,已保证同样的功能可以用其他框架或者库或者任何形式的第三方代码来完成。所以我把侵入性理解成了这个样子,也许我树了一个不存在的靶子。我觉得有些框架在吹嘘自己的时候,对买家有这样的暗示,就是你用我也可以抛弃我。实际显然不是如此。 如果把“易于替换框架”做为一个框架API设计的考虑标准的话,就出现了代码上无侵入性,配置文件中有侵入性的现象。我不知道Hibernate的配置文件算不算一个例子,它保证了对象无需继承,没有静态增强。但是用配置文件和动态增强,一样是有侵入性的。我觉得使用了框架,根本没有换掉一说。设计框架API的时候,考虑的只有好不好用(用在产品代码中),好不好测试(用在测试代码中),而不存在框架是不是允许你的代码移植到别的框架的问题,因为这不可能,除非重写。 |
|
返回顶楼 | |
发表时间:2006-12-13
Readonly 写道 框架的侵入性问题可以拿实际例子来说明:
A. IOC容器 1. Avalon采用Interface Injection,如果你采用这个框架做IOC,它的侵入性就是要实现一个接口 2. Spring和Pico采用Javabean setter或者Constructor injection,采用他们做IOC,侵入性就是要满足Javabean规范 3. 同它们相比,不需要interface,也不需要满足Javabean规范,无所不能的ajoo的IOC容器就是号称无侵入性 B. MVC架构 1. struts的侵入性是需要扩展它的一堆base class,以及写一堆带有http request/response签名的方法 2. webwork则只要是普通的javabean就可以了 做同样事情的不同框架,如果侵入性越低,通常框架本身的实现比较复杂,效率也比较低,也有可能把侵入性从Java对象的本身移到了其他地方(比如配置文件)。 不见得pico就比avalon复杂吧?虽然pico的侵入性低。 同样地,我也不认为我的yan比spring复杂,虽然yan侵入性低。(当然,看怎么定义复杂性了,如果认为采用monad组合就是复杂的话,那么yan确实复杂。但是yan确实没有spring的那么多if-else。) 说到效率,yan的效率比spring高的。 低侵入性一定意味着复杂?低效? |
|
返回顶楼 | |