2007-06-12

应用开源项目时，你会大肆封装，修改它吗？

关键字: 封装开源项目
趁着前面那位”LUCENE应用体会“，发表此帖，也是我心中压抑已久。

我觉得，对于开源项目，就是工具，大可不必用的那么复杂。

封装再封装，HACK再HACK，有什么明显的性能提升吗？某些我们作出的改进，人家作者能想不到相关方面吗？

见过有把Struts的DispatchAction 封装的面目全非的，见过有把Spring Mvc中的 controller 重写源代码的， 见过有为了实现美其名曰“权限的动态管理”把Acegi改的一塌糊涂的。最后效果怎么样？

改Struts的那个只是为了增加个log，写出的class却无法被 doclet辨认。改Spring mvc controller的那个也就是增加个log，却没有使用官方推荐的 paraMethodResolver，弄的那方法名是千奇百怪啊。至于改Acegi的那个，是我做的蠢事。人在公司，身不由己。上级要求的，于是我按照上级的思想来实现。到最后BUG 多多，诡异事件到处都是。领悟用3天，改Acegi用4天，教人使用还要2天。我自己都不知道把现在这东西是怎么用的。哎！

记得在某坛见到某前辈谈经验。他说，见过的好系统，都是设计简单的。越是经历多几个项目，我就越身有体会。

菜鸟刚飞，说的漏洞很多，请各位朋友多多指教！
评论
wangfuyu 2007-07-05
我觉得，对于开源项目，就是工具，大可不必用的那么复杂。

封装再封装，HACK再HACK，有什么明显的性能提升吗？某些我们作出的改进，人家作者能想不到相关方面吗？

见过有把Struts的DispatchAction 封装的面目全非的，见过有把Spring Mvc中的 controller 重写源代码的， 见过有为了实现美其名曰“权限的动态管理”把Acegi改的一塌糊涂的。最后效果怎么样？

改Struts的那个只是为了增加个log，写出的class却无法被 doclet辨认。改Spring mvc controller的那个也就是增加个log，却没有使用官方推荐的 paraMethodResolver，弄的那方法名是千奇百怪啊。至于改Acegi的那个，是我做的蠢事。人在公司，身不由己。上级要求的，于是我按照上级的思想来实现。到最后BUG 多多，诡异事件到处都是。领悟用3天，改Acegi用4天，教人使用还要2天。我自己都不知道把现在这东西是怎么用的。哎！

记得在某坛见到某前辈谈经验。他说，见过的好系统，都是设计简单的。越是经历多几个项目，我就越身有体会。

菜鸟刚飞，说的漏洞很多，请各位朋友多多指教！
haohappy 2007-07-04
封装、扩展但尽量不修改源码，否则最好直接参与开源项目的建设。

当然这也是好事，目前贡献代码的人比拿来就用的人要少得多，特别中国的程序员只有很小部分参与国际开源项目，这种状况也需要改变了。
geszJava 2007-07-03
ltian 写道
侵入式地修改开源的东西要慎重。最好是不侵入式修改。

严重同意.
可惜有时候需要加功能,又要兼顾效率和处理历史问题.俺也不想这么做的.想想以后的维护...头很大.不过没办法,现在也看不见以后会怎么样,或许公司倒闭或许公司成功,反正无论哪种可能,俺都不用去维护这个破东西了.所以,想改就改吧!
ltian 2007-07-02
侵入式地修改开源的东西要慎重。最好是不侵入式修改。
taelons 2007-06-28
好的开源项目都是面向接口设计的,便于扩展。写程序时一定要明白,你的代码要便于扩展,使用你的代码的人也应该明白,去扩展而不要去修改,除非有bug。
其实许多大的开源项目我们都不用，比如spring、hibernate，一直用老版本的struts，加上一些自己的扩展，因为当时spring、hibernate等没出现或者不完善。
kedao 2007-06-27
如果封装能更好的实现应用，为什么不呢？
bbiao 2007-06-21
对DispatchAction封装过...
我觉得有些东西如果有改得好的话,还是很有意义的...
limx 2007-06-21
TommyCool 写道
记得,我们在做地税项目时,根据实际需求对hibernate进行了一定的封装,将事务处理封装的很好,使得程序员都不用理会后台,而专注于实际业务本身.对开源框架的封装要根据实际需要而定,不要走极端.建议多关注AOP方面的应用,对进行封装或业务需求的处理有很好的借鉴!


同意，很多时候封装都是为了将前后台或不同模块的业务分隔开
曾经封装过lucene,目的也是为了方便其他模块的程序员调用
至于说修改...... 个人还是扩展用得多一些 实在不敢自己未完全掌握的开源框架前造次
geszJava 2007-06-19
lucene的hack是必需的,在我们的项目中.
TommyCool 2007-06-19
记得,我们在做地税项目时,根据实际需求对hibernate进行了一定的封装,将事务处理封装的很好,使得程序员都不用理会后台,而专注于实际业务本身.对开源框架的封装要根据实际需要而定,不要走极端.建议多关注AOP方面的应用,对进行封装或业务需求的处理有很好的借鉴!
zlsunnan 2007-06-19
这个完全是根据实际情况而定 如果是你的项目中 有这样的需求的 那是肯定要改的 如果没有需要的话 为什么要改呢 都封装的那好 拿来就用 行了
galaxystar 2007-06-18
在真正做开发时,少写一行代码也是好的!
findhappy7 2007-06-18
自己修改封装是件好事，因为每个公司的业务类型应该变化不大，针对公司现况分装下，有利于 业务的快速开发，但有个问题就是，要看自己的水平，如果连源代码都不能彻底理解，而是一直版半解就去改动，或者做些很肤浅的方法集成，这样的行为比较危险。
zwchen 2007-06-18
其实，敢改开源项目，必须先问自己：
1、你对原开源产品理解透了吗？
2、除了封装，又其它扩展办法吗？
3、你的项目必须这么做吗？
4、开源产品的后续升级对你冲击大吗？
zwchen 2007-06-18
我看具体情况了，一般来说，我觉得如果你用开源框架做产品，比起做项目，修改框架的可能性要大多了。象log4j，我见过几个产品，因为ClassLoader的问题，将log4j给封装了（log4j提供的那个自定义ClassLoader就像有时候不满足要求）。

打个比方，象最常用的Struts，本身就提供了很多的扩展点，譬如那个ActionServlet和RequestProcessor，包括RequestProcessor里面的每个protected的processXXX的模板方法都是留给扩展的，否则要用protected干嘛，而且自定义RequestProcessor都可以在struts-config.xml 里面配置的。也就是说它很好支持扩展。那个Plugin机制也是专门为我们做扩展的，因为已有的Validation和国际化、临时数据库都是典型的例子。
而且，我以前用一个类似Spring的的Seasar框架，它通过IoC和AOP，把Struts变成了webwork那样易用。

一般来说，框架提供的filter、interceptor等类似AOP的东西，是一个通用的扩展方式。

如果把开源项目给封装了，大肆修改，后期你发现那个开源项目出现了bug，并且在新版本里面更正了，该更正也是你需要的，你咋办？再对新版改造？

我觉得，一定要考虑优先用开源产品自己的plugin机制！

我现在在对Jive公司著名的即时通讯服务器和客户端Openfire和Spark二次开发，但首先考虑的是写plugin，但是我们的在Spark客户端（类似于MSN）的上的二次开发就没法再用Spark的后续版本了，因为有很多定制的功能，譬如最简单的：Spark的国际化只做了90%，剩下的10%是hard code的，我们一给它完善，呵呵.... 它本身的后续bug都交给我了。
sun113 2007-06-18
通用框架并不一定适合所有的系统，
对于具体的系统通常对框架封装就可以了，
至于修改代码认为没必要。
无明 2007-06-15
大规模修改？那还不如自己写个土制框架好了，至少是100%贴合实际
magice 2007-06-15
修改，封装都是正常之事，毕竟国外人的有些框架绕的弯子和我们思路就不一样，如果能修改简单一些那自然是好，但是如果修改复杂了，那就。。。
agile_boy 2007-06-15
gigix 写道
奇怪……竟然没有人指出如此明显的一件事：
如果你需要修改开源项目，别人很可能也有同样的需要
所以你应该把你的修改贡献给开源社区

赞成，这才是正确的开源之道
agile_boy 2007-06-15
除非，你决定参与到开源项目中，否则最好不要去修改源代码（特殊情况除外），当然看人家代码实现，是应该也是必须的 :)
大肆封装也没有必有吧，但有时候也会用facade，adapter模式去做些简单封装的.
sg552
搜索本博客
博客分类
最近加入圈子
存档
最新评论