一般我们习惯性都是利用类构造函数直接获取一个类的实例,但是要考虑利用静态的工厂方法获取是否会更优?如果更优,则应该将构造方法私有化,提供公共的静态工厂方法获取实例。
静态工厂方法的优点
-
方法有名称。
- 有时候如果通过构造器去获取实例,可能这个实例的获取有一些比较特殊的意义,构造器没法通过名称体现这个意义,如果提供一个静态的方法,则方法名可以提现具体的意义。
- 关于这一点,很好理解,但是最好在后续的阅读源码中能找到这样的例子
-
不必在每次调用他们的时候都创建一个新的对象。
- 最好的理解方式就是单例模式,我们只需要一个实例,不用每次需要用到的时候浪费性能去重新获取实例。
- 当然实际当中我们之所以写单例,都是因为某些情况下只能保证一个实例,出现多个就会报错才去写单例,这一点上要纠正过来,某些情况下即使允许多个实例同时出现,也有可能需要提供这样的方式去获取实例,因为在性能上是有优化的。
- 关于这一点,多思考在实际开发中怎么运用起来
-
可以返回原返回类型的任何子类型的对象
- 没看懂,后面多看几遍,再补充
-
在创建参数化实例的时候,可以使代码变的更简洁
- 关于这一点感觉意义不大,不知道是不是理解不对,后面阅读在细心领会下。
静态工厂方法的缺点
-
类如果不包含共有的或者受保护的的构造器,就不能被子类化。
- 这一点应该这么理解:就是如果提供静态的工厂方法,则构造器一般会私有化,如果有子类需要继承该类是没法继承的。
- 当然这一点书中也提到了:这样也鼓励了程序员使用复合,而不是继承。(这一点书中后面会有讲到,后面去体会)
-
它们与其它的静态方法实际上没有任何区别。
- 意思就是说这样做,就跟普通的静态方法没有什么区别了,那对于开发者在用这个类的时候可能不能很快地知道怎么实例化这个类。例如提供api,会专门把构造函数提出来说明,但是静态的工厂方法不会。
- 因此在提供一个类的静态工厂方法去实例化该类的时候,最好按以下的惯用名称去提供:
- valueOf:包装类都有提供这样的方法。
- of:和valueOf一样。
- getInstance:获取唯一的一个实例。单例模式一般这么定义
- newInstance:每次获取一个新的实例
- getType:和getInstance一样,但是在工厂方法处理不同类中的时候使用,这样能代表这个方法返回的是一个什么类的实例。
- newType:同理。