- 浏览: 72865 次
- 性别:
- 来自: 深圳
-
最新评论
-
tang52016639:
插。。。还真是顺序的问题,害我搞了大半天
poi的一个让人失望的bug -
dlheart:
放到bin里面?哪有bin目录?
poi的一个让人失望的bug -
smh821025:
veriolion 写道2008-12-02 12:03:15 ...
poi的一个让人失望的bug -
yadsun:
原来GEF中大量使用的是command模式
command命令模式 -
raisinmiao:
3.2也是同样的问题,上移即可解决。谢谢!
poi的一个让人失望的bug
文章列表
composite合成模式可以使用户对象以同样的方式对待单独的对象或复合的对象,合成模式要设计一个公共接口,即可提供给单独的对象使用,也可以供给复合对象使用。 使得用户类一致地使用单独的对象或者复合的对象,也不必关系要如何处理复合对象,只需要向复合对象添加单独对象即可。 junit的Test接口的两个子类TestCase和TestSuite就是使用了合成模式。
其部分关键源代码如下,合成模式的代码结构基本上跟下面代码一样:
package junit.framework;
/** * A <em>Test</em> can be ...
- 2008-05-21 14:37
- 浏览 1452
- 评论(0)
bridge桥接模式的目的和decorator装饰器模式是一样的,都是避免过多的子类,只是它们的实现的方法有所不同,桥接模式采用聚合的方式来实现。要对类的功能进行扩展,可以修改现有的代码来做,但是如果一个父类的n个子类都要该功能,那么就得修改n次,不但工作量大而且重复代码量很多。这也违反了面向对象的开放/封闭原则(对扩展来说是开放的,对修改来说是封闭的)。在前面的《decorator装饰器模式》中提到的“父类的n个子类的都要派生出子类并实现这些功能”,这种方来处理但然也是不合理的。 bridge桥接模式中“将抽象化与实现化脱偶,使得二者可以独立地变化”的意思,就是利用聚合 ...
- 2008-05-21 14:06
- 浏览 1278
- 评论(0)
decorator装饰器模式,动态地扩展一个对象的功能,而不需要改变原始的类代码或使用继承。是通过创建一个跟目的类同一等级(继承目的类的父类)的称为装饰器的封装对象来实现的。要新添加的功能类继承这个装饰器,这样用户类可以像使用原来的类那样使用新添加的功能类。 decorator装饰器模式可以动态地添加功能,也可以动态地撤销功能。如果一个父类的n个子类,都需要有一个或若干个功能,而它们操作该功能的代码结构基本一致,这个时候就可以考虑使用decorator装饰器模式。如使用继承来实现的话,父类的n个子类的都要派生出子类并实现这些功能,随着子类的增加,重复的代码量会不断增加,灵活性较差。 ...
- 2008-05-21 00:45
- 浏览 1037
- 评论(0)
adapter适配器模式,目的在于扩展。是在原系统上进行扩展时用到的方法。 adapter适配器模式,个人认为在其名前加两个字,命名为接口适配模式。其用意是在保留原有类的前提下(即不改变原来的代码)把一个类的接口 ...
- 2008-05-20 01:46
- 浏览 947
- 评论(0)
prototype原型模式,简单明了的讲是,克隆并复用原型对象模式。 当客户机需要创建对象集时,其中对象是相似的,或仅在状态方面有所不同,并且创建此类对象将花费很多的时间,所涉及的处理也较多。比如,通过复制具有类似结构代码,并进行修改,来创建一个新的实例,这时可以考虑采用原型模式,这样就不必通过复制修改代码来实现新的实例,只要克隆一下另一个实例,通过修改相应的属性的值来到达你的目的。 克隆有浅克隆和深克隆。
class Person implements Cloneable {
private String name;
public String getName() ...
- 2008-05-19 17:38
- 浏览 981
- 评论(0)
builder构造模式,简单明了的讲就是一个对象(或者说是一个部件)实例化过程的提取模式。目的在于方便维护和扩展。 如果要创建的对象是复杂的,而且组成对象创建工程的一系列步骤可以按不同的方式来生成不同的对象,这是就应该要考虑使用构造模式,否则你把构造的所有的过程都放在一个对象里面,代码可能会变得很臃肿,这时应该把系统模块化。允许创建复杂的对象,可以只提供要创建的对象类型的相关信息,并且使有关对象创建的详细信息对客户机保持透明,这种方式方式允许相同的过程生成不同的对象。 在jdon里面讲的设计模式之Builder的例子(http://www.jdon.com/designpatter ...
- 2008-05-19 14:27
- 浏览 1652
- 评论(0)
singleton单例设计模式,目的在于类之间的信息共享。 singleton单例设计模式也是相当容易理解的模式之一。就是在整个系统中,只有一个实例。更确切的讲,应该是让jvm一旦为某对象创建了一个引用,就不会在创建的一种模式。举一个在本人的项目中比较典型的例子,就是用户在某个类中就行了一些信息处理,接着用户可能会频繁的使用到这些处理后的信息而且这些信息占用的空间较小,那么就应该把这些信息保存在一个单例中。 singleton单例设计模式代码基本都是这样:
public class Singleton{
private static Singleton singl ...
- 2008-05-19 01:37
- 浏览 924
- 评论(0)
factory工厂设计模式,目的在于方便系统扩展。 这是设计模式里面最容易理解的模式之一。工厂就是可以生产东西的地方,然而一个工厂也是限定生产成品的,例如生产鞋子和袜子的工厂,你只能定鞋子和袜子的货。for example,在我的一个项目里面,有这样的功能,就是多格式文件处理,并获取一定信息,由于各种格式的文件的格式不同,所以读取方式不同,就要对应的类进行读取。我是这样处理的,根据传进来的文件名,判断其文件的后缀,然后在工厂类中获取一个对应的读取类的实例。 我的代码大概架构如下:
public interface Document {
public Strin ...
- 2008-05-19 00:54
- 浏览 1230
- 评论(0)
在链接传一个参数例如:struts.do?type=all,在声明一个文本框:例如<html:text property="type"/>,在ACTION类里面,用request,getParameter("type")和form.getType()(对应的ActionForm类的函数),读出来的是链接的参数的值——"all",读不出在文本框手动填入的值 。在servlet里面也是这样的,因为struts的内核还是servlet。
搞了半天才知道是因为POI(3.0.1版本)还不支持EXCEL4.0以上的版本所造成的,把EXCEL另存为EXCEL3.0或其以下版本就可以解决问题了。
一个finally里的return与java异常抛出的问题
我在做一个项目时,该项目遇到了一个debug,经过的纠错之后才发现了一个finally里的return与java异常抛出的问题。
对于这个问题,笔者举以下简单的程序为例进行描述:
public static void main(String []args){
System.out.println(file());
}
public static boolean file(){
try{
for(int i=0;i<3;i++){infile();}
}
catch(FileNotFoundException e){System ...