说来惭愧,很早就制订了一个读书计划,要读一些名著,但是找了一大堆借口,至今未实行。这次决定无论如何要起步了。因为打算转Android开发,那么首先就选那本大名鼎鼎的Effective java。似乎自从有了Effective c++之后,这种以条目式总结最佳实践的书就火了起来。这也难怪,只是认识一堆的语法是写不出好的程序来的。这种条目书将优秀的程序员的精髓以短小精悍的形式总结出来,条目之间相对独立,可以随意翻阅,更难得的是,这种经验往往是与具体语言无关的,完全可以应用到他出。现在我就来说说第一条目:静态工厂方法。
好吧,在设计模式中,工厂模式绝对是知名度最高的模式之一,不要弄混了,静态工厂方法并不属于GOF,只不过现在的设计模式书籍都喜欢附带的讲讲静态工厂方法。因为它们的确有类似之处,那就是都要解决对象实例化的问题。实例化常用的方式就是new + constructor()。但是在实际的开发中,这种实例化方式往往有一些缺点。当然,这些缺点同时也就是静态工厂方法的优点,否则又何必多此一举,推荐静态工厂方法呢?
首先,何谓静态工厂方法,其实静态工厂方法不是什么新鲜的东西,java标准库中早就大量使用了,比如:
包装类中的valueOf方法就是常用的静态工厂方法,它取代公有构造器来完成对象实例化功能。
public static Boolean valueOf(boolean b) {
return b ? Boolean.TRUE : Boolean.FALSE;
}
看到了吗?静态工厂方法的第一个优点是------有名字。什么意思?当然是可以更清晰的表达实例的意图。比如BigInteger(int, int, Random)返回一个可能的素数,但是通过构造方法本身谁看的出来,再比如,如果有需要创建两种初始化的实例,但是给它们传入的参数是相同的,怎么办,构造方法只能够通过改变传参顺序来实现重载,这可是最糟糕的一种实践方式了。
静态工厂方法的第二个优点就是-----不用每次调用都创建新的实例。就如前面介绍过的Boolean的valueOf方法,就从不创建新的对象。这在某些需要重用单一实例的场景下是很有用处的。
静态工厂方法的第三个优点就是-----可以传回返回类型的字类型。客户端只是拿到了父类型的引用,至于实际的类型他是不知道的,这样就屏蔽了细节,方便维护。库的维护人员可以在日后根据需要修改返回的具体类型而不影响客户端代码
至于第四个优点则显得有些过时了,可以简化泛型实例化的代码,这点在java7中就已经实现了,希望作者能够抽空出来出个effective java第三版
最后简要说说静态工厂方法的缺点:
1,那些被静态工厂方法返回的实际子类型如果没有公开的构造方法将无法被继承,不过从好的一面说,这也迫使程序员坚持组合优于继承的原则
2,第二个是静态工厂方法在API文档中没有被特别标注,和普通的静态方法没有明确区分,解决的办法往往是使用一些命名规范,比如valueOf, getInstance,newInstance等,具体的可以看书。