一、如何评价一个框架

要评价一个框架，或者说理解一个框架，需要适当地了解一下这个框架发展的历史，这样就能知道框架某种做法的来龙去脉。很多今天我们所认为理所当然的 一些东西，在框架的开发过程中，正在被探索中。在探索中，深入学习了流行的框架，并对其优缺点形成了一套自己的认识。最流行的并不是技术最前卫的。我们要 去理解一个框架，首先要了解它所产生的一个技术背景，然后再来做出评价。

二、如何改进框架

业界的发展很快。雨后春笋般冒出来的新框架新思路，最初的框架中有肯定会有很多地方会落后了。那么我们就要来不断的改进框架。一个框架能不能很好的 扩展和改进也是衡量一个框架质量的标准。但是框架也不能说改进就改进，框架必须稳定，不能说变就变。虽然我们知道有很多新技术新理念，但必须一点一点地加 到框架中。对于现有已经稳定工作的框架，还是要保证其正常运行。一般采取两条路线： 一条是渐进路线，一条是变革路线 。前者的原则是稳定压倒一切。在稳定的基础上，尽可能解决大家碰到的问题和不爽之处。后者是站在前者肩膀之上，但不拘于现有应用的束缚，大胆变革，以产生更好的框架。

三、如何看待一个框架

每一种框架都有它自己特定的优点，相对而言，也会有它的缺点。没有一种框架是完美的。框架是为了达成下列目标而设立的：

1. 重用代码 。框架聚合了很多公用的代码、模块，以便简化编程的工作，提高编程的质量。
2. 良好设计 。如果没有框架，写程序就可以天马行空。但有了框架，就可以把程序员约束在一种良好的设计里面。
3. 降低耦合 。这一点其实包括在良好设计范围内，不过它非常重要。其实近来IoC、AOP从本质上来说，都是为了降低代码的耦合度。随之带来的好处是易测试、易重用、易读懂、易维护等。
4. 简化工作 。把和业务无关的内容尽量处理掉，使程序员可以专注在业务上。
5. 保证性能和稳定性 。框架中也需要考虑性能问题、稳定性、扩展性、可用性......等很多问题

纵观opensource世界中的很多流行框架，例如Webwork、Struts2等。它们确实在某一方面做得很好，或者说它们在80%的地方都 做得很好。但是如果想要把它们直接拿过来，放在特定的应用场景中使用，可以想象，一定还有很多的事情要做，一定还有很多的问题需要解决。

是不错的OSGi的小工具。

1、方便切换OSGi平台，默认是Felix，可以随时切换OSGi的平台

2、即使你不知道OSGi是什么，你也可以很简单那的使用

3、也许你现在还没有很方便快速的把OSGi平台给工作起来，那么快来吧

4、自动维护依赖的Bundle，自动从网上下载。

还是看视频来学习下吧

百度不行啊，还是去我JavaEye的博客看

例子是BlueDavy的OpenDoc上的内容,是一个简单的用户登陆的例子。

启动应用之后

通过http://127.0.0.1:8080/demo/page/login.htm进行访问

我们可以通过控制台输入ss可以看到LADP、DB和ConfigFile三个提供验证的服务的Bundle都在提供服务，

我们通过页面输入用户名和密码，

在后台可以看到打印输出了LDAP验证

好，那我们来stop LDAP验证的Bundle，不需要重启应用，我们直接再次登陆，发现依然可以，控制台打印出DB验证。

那我们接下来关系的事情是，如果我们把三个提供验证的Bundle都stop了，对用户登陆的Bundle会不会影响呢？

由于只能上传三个附件，所以就不截图了。

答案是不会影响，只是在登陆时候，会告诉你没有能够提供服务的Bundle。

也就是说Bundle之间的确应依赖影响，由一个Bundle失效而引起连锁反应是不存在的。

但是从业务的角度上来讲，如果某些Bundle无法提供服务，那整体应用对外提供的服务也会收到很大的影响，即使应用的其他Bundle不受到什么影响。

一、项目的需求变更迫使你改变原有的设计

在项目开发的中期，已经完成了系分设计，编码也进行到一半的时候，需求方提出需求变更。虽然可以拒绝接受需求的变更，但是由于功能点的重要性，接受了变更。但是面临的问题就是还有半个月，项目就有上线，为了能够在规定的时间内完成项目，并且实现变更的需求，我们采取的方案是尽量不改动原有的设计，以最小的代价来实现新的需求。最后我们的项目是按期完成了，满足需求方的第一期需求，但是我们付出的代价就是改变了我们原有的设计，使得设计变得丑陋了。

二、项目的deadline使得你不得不提交丑陋的实现代码

设计变得不完美的时候，实现的代码就会有bad smell了，但是项目的deadline就在眼前，你只得提交你不甚满意的代码，虽然这些代码已经实现了最初的功能。也许你会觉得，将来我再重构这些代码好了，但事实上，这几乎成了很困难的一件事情。首先、你改了代码就意味着测试那边需要进行一次回归测试，人力上的投入不是我们能说得算的，得boss同意。其次，你真的敢改已经运行的很正常的代码吗？没有良好的单元测试配套，没有良好的设计上的重构，想要对代码进行重构，那几乎是不可能的事情。

三、项目的二期、三期会让代码的bad smell越来越多

既然你没有办法去消除一期项目的bad smell，那么在二期、三期的时候，你的设计和变更不得不基于原有的丑陋的代码，那就出现了bad smell蔓延的情况，最后代码也就变得很难维护了。

以后还是要对自己写得每一个类，每一个方法都写好相应的tese case！