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

趁着前面那位”LUCENE应用体会“，发表此帖，也是我心中压抑已久。

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

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

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

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

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

菜鸟刚飞，说的漏洞很多，请各位朋友多多指教！

评论

45 楼 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天。我自己都不知道把现在这东西是怎么用的。哎！

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

菜鸟刚飞，说的漏洞很多，请各位朋友多多指教！

44 楼 haohappy 2007-07-04  

封装、扩展但尽量不修改源码，否则最好直接参与开源项目的建设。

当然这也是好事，目前贡献代码的人比拿来就用的人要少得多，特别中国的程序员只有很小部分参与国际开源项目，这种状况也需要改变了。

43 楼 geszJava 2007-07-03  

ltian 写道

侵入式地修改开源的东西要慎重。最好是不侵入式修改。

严重同意.
可惜有时候需要加功能,又要兼顾效率和处理历史问题.俺也不想这么做的.想想以后的维护...头很大.不过没办法,现在也看不见以后会怎么样,或许公司倒闭或许公司成功,反正无论哪种可能,俺都不用去维护这个破东西了.所以,想改就改吧!

42 楼 taelons 2007-06-28  

好的开源项目都是面向接口设计的,便于扩展。写程序时一定要明白,你的代码要便于扩展,使用你的代码的人也应该明白,去扩展而不要去修改,除非有bug。
其实许多大的开源项目我们都不用，比如spring、hibernate，一直用老版本的struts，加上一些自己的扩展，因为当时spring、hibernate等没出现或者不完善。

41 楼 kedao 2007-06-27  

如果封装能更好的实现应用，为什么不呢？

40 楼 bbiao 2007-06-21  

对DispatchAction封装过...
我觉得有些东西如果有改得好的话,还是很有意义的...

39 楼 limx 2007-06-21  

TommyCool 写道

记得,我们在做地税项目时,根据实际需求对hibernate进行了一定的封装,将事务处理封装的很好,使得程序员都不用理会后台,而专注于实际业务本身.对开源框架的封装要根据实际需要而定,不要走极端.建议多关注AOP方面的应用,对进行封装或业务需求的处理有很好的借鉴!

同意，很多时候封装都是为了将前后台或不同模块的业务分隔开
曾经封装过lucene,目的也是为了方便其他模块的程序员调用
至于说修改......  个人还是扩展用得多一些  实在不敢自己未完全掌握的开源框架前造次

38 楼 geszJava 2007-06-19  

lucene的hack是必需的,在我们的项目中.

37 楼 TommyCool 2007-06-19  

记得,我们在做地税项目时,根据实际需求对hibernate进行了一定的封装,将事务处理封装的很好,使得程序员都不用理会后台,而专注于实际业务本身.对开源框架的封装要根据实际需要而定,不要走极端.建议多关注AOP方面的应用,对进行封装或业务需求的处理有很好的借鉴!

36 楼 zlsunnan 2007-06-19  

这个完全是根据实际情况而定  如果是你的项目中 有这样的需求的 那是肯定要改的  如果没有需要的话  为什么要改呢 都封装的那好 拿来就用 行了

35 楼 galaxystar 2007-06-18  

在真正做开发时,少写一行代码也是好的!

34 楼 zwchen 2007-06-18  

其实，敢改开源项目，必须先问自己：
1、你对原开源产品理解透了吗？
2、除了封装，又其它扩展办法吗？
3、你的项目必须这么做吗？
4、开源产品的后续升级对你冲击大吗？

33 楼 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都交给我了。

32 楼 JerryZheng 2007-06-18  

agile_boy 写道

gigix 写道

奇怪……竟然没有人指出如此明显的一件事：
如果你需要修改开源项目，别人很可能也有同样的需要
所以你应该把你的修改贡献给开源社区

赞成，这才是正确的开源之道

呵呵 有时候老板的话乃们要听...

31 楼 sun113 2007-06-18  

通用框架并不一定适合所有的系统，
对于具体的系统通常对框架封装就可以了，
至于修改代码认为没必要。

30 楼 无明 2007-06-15  

大规模修改？那还不如自己写个土制框架好了，至少是100%贴合实际

29 楼 magice 2007-06-15  

修改，封装都是正常之事，毕竟国外人的有些框架绕的弯子和我们思路就不一样，如果能修改简单一些那自然是好，但是如果修改复杂了，那就。。。

28 楼 agile_boy 2007-06-15  

gigix 写道

奇怪……竟然没有人指出如此明显的一件事：
如果你需要修改开源项目，别人很可能也有同样的需要
所以你应该把你的修改贡献给开源社区

赞成，这才是正确的开源之道

27 楼 agile_boy 2007-06-15  

除非，你决定参与到开源项目中，否则最好不要去修改源代码（特殊情况除外），当然看人家代码实现，是应该也是必须的
大肆封装也没有必有吧，但有时候也会用facade，adapter模式去做些简单封装的.

26 楼 devilbaby 2007-06-14  

工具性的开源项目不会，好像liferay，expresso这种整合框架性的开源项目，会