基础知识: 需求!

起因:
http://forum.iteye.com/viewtopic.php?t=6417

解决:
http://forum.iteye.com/viewtopic.php?t=6545

static factory 自然是有其優點。說 static factory 可以做到 new 可做之事，也是很自然的，就像 goto 可以做到 loop 可做之事一樣。loop 對 goto 做了合理的限制，而 new 的限制不盡然就是壞事。

ajoo 將 constructor 給 private ，的確有可議之處。首先，很多工具是依 javabean 的規則來運作的，而不只是 spring ，javabean 規則中就是要用 default constructor 來建立物件，雖然你可以說這是 javabean 規定的缺點，但這也反映用 static factory 命名無法統一的問題。

而且說 static factory 可以依 interface 來回傳物件，不必受到真正型別的限制，但有些情況你反而不想要這一層彈性，如 object serialize 的情況，這時明確的型別是重要的事，能回傳別的型別不一定是好事。

其實我覺得， factory pattern 本就是個良好的設計，有 I 這個 interface ， A, B 都繼承 I 並都遵守標準的 javabean 規則，而 IF 是一個 factory ，回傳符合 I 的 instance，這時 factory 用 private constructor, final 等作法就是合理的了 (雖然有時候還會需要 factory 本身的 instance，不過這個情況並不多)。
這樣少了些強制性，讓別人可以直接產生 A, B 等物件，而不通過 IF 。但一來有時這是必需的，二來，編程會犯錯的地方多的是，明眼人自然知道如何去使用這些東西。

factory 是個經典的 pattern ，但 factory 就是 factory ，用在 factory 身上的作法不一定適合在別的地方。

分析得有道理.
不过拿factory和goto比可有点不合适吧?
我们都知道依赖抽象的设计肯定可以做到直接依赖具体的设计能做到的事,照这么比,难道依赖抽象的设计都是应该被淘汰的?

factory的名字不统一问题,也在前面列出的一个缺点之中. 我是可以说javabean的设计不够灵活, 但是同时,javabean之类东西不管灵活与否,事实成为了一个标准,必然要对factory造成反作用. 这也是一个灵活 vs. 简单的两难问题.

至于说serialize的时候不希望抽象, 这也是事实.
但是不能说明抽象就不如具体.

这些例子唯一能够说明的,就是: 抽象, 工厂不是万能的, 有些场合是要依赖具体, 要直接用构造函数.

这我也没意见.

不过,在程序设计中, 主要的核心不在于javabean, 不在于serialize. 在一个足够复杂的程序中, javabean只占很小的一个部分, 就是一些entity而已. 如果程序的全部就是处理一些entity,呵呵,世界不免太简单了.
java bean的作用主要在一些粗粒度的组件边界.
打个比方, 我们要做一个hibernate库, 一个connection pool, 或者做一个xml parser,我们在代码的百分之几需要设计java bean呢? 需要serialize呢?


只怕我们大部分的精力都要集中在用java语言提供得强大的抽象和封装能力来解决问题本身. 容器? java bean? 那是几乎没什么关系的遥远的事.
而且,即使最终要用到, 做一些adapter的盒子套上就是了. 大可不必为了担心bean的问题而在编程过程中捆住自己的手脚.

开禁以后我想到的第一个发贴就是在这里了。
haha.
其实static factory不算是经典的factory中的一员。而且，经典的模式大多是在C++时代进化过来的，有些也不适合java.
还有，这个静态工厂依赖的也是具体，这个和new是一样的。所以这一点和new是五十步和六十步的区别。