写成一个框架分为三部分，1主程序（顺序执行的一段代码，一般为一个函数，struts,junit,
hibernate,spring均如此），2一些定义的用于扩展的接口，3配置文件（xml,proterties,框架使用反射
定位实现接口的实现类）.程序分为两个部分一部分是框架代码，一部分是接口的实现代码，框架代码定
义了系统执行的顺序和怎样调用接口，接口的实现代码实现了业务逻辑，框架代码和接口代码是相互独立
的他们之间可以存在一对多的关系（一个框架对应多组接口代码），从而可以生成多组不同功能的系统
j2ee框架是典型的框架接口模型，j2ee分为两个部分，应用服务器（j2ee容器）和j2ee组件，
j2ee容器定义了怎样调用这些接口(包括生命周期方法，和其他一些功能，如事务，线程，持久性)，
j2ee组件是一个包括一些实现规格接口的代码，和部署描述符的集合。
而部署描述符的作用是容器通过部署描述中的信息使用反射装载指定的实现标准接口的类。
扩展性（例如：1定义一个接口，以后添加一定的逻辑只要实现此接口，并把此类加入，可直接生成实例，
也可配置，2实现一个框架代码，代码调用一些接口，此接口的实现是空，或在配置文件中定义了开关
设置，当需要此功能实现逻辑，或打开开关），可维护性（将经常修改的代码移出到一个类，修改时
仅修改此类即可，不会改动主要程序，例如框架代码），可重用性（一个类中多个方法共用一段代码，将
此代码抽象成一个方法，多个类都使用同一个方法，将此方法抽象成一个类，多个工程都使用一个类，将
此类打包成一个jar包，或者多个框架（或者说是定义了规范，不同的框架实现体都符合此规范）定义了
标准的接口规范，则你的此部分模块可实现组件化）
关于环境的概念，能得到一定的属性，和方法的能力表示他具有在此环境的能力，引用和继承都可以
实现此效果，我建议使用引用而尽量少使用继承（这也是GOF的思想），在RFT的接口中曾有一个Constant
接口里面定义了一些常量，然后需要这些常量的类implements了这个接口，我觉得这种感觉不好，或者
说我不喜欢这种风格，不如定义一个类，他实现单例，然后每次用对象引用常量，我觉得这样会感觉清晰
些，我很讨厌看到一个方法而不是此类中定义的，然后他是继承了很多层的一个类，去寻找继承树相当
麻烦不如直接使用一个引用那么简单
java的运行的代码包括两部分，1虚拟机，2Class,jvm+class在操作系统级也只不过是一个线程，而
java文件更象一个高级语言化的脚本