关于Factory, Abstract Factory, Factory Method, 和Builder...

能和同好在这里展开讨论, 真是人生一大快事.

snomile兄, 正如你说的那样,在进行应用系统开发时,要照顾到编码人员, 尽量降低门栏, 对外尽可能提供简单的Factory。我们也是这么做的。

说道Abstract Factory，其实Swing里面JFormattedTextField就用到了。 这里说句题外话，JDK里面用到了相当多的模式，没事的时候读读JDK的源代码，可以帮助理解。回到正题，在JFormattedTextField中有一个抽象类AbstractFormatterFactory, 她有一个默认的实现类DefaultFormatterFactory, 具体的功能请看文档，写得很详细。当我们需要编写一个特殊的JFormattedTextField时，就需要编写一个自己的XXXFormatterFactory
以及相应的XXXFormatter。因为公司内部的代码不属于我个人，抱歉没有办法在这里展示给大家看。不过，我估计在JGoodies里一定有相关的例子，比方说输入日期，时间的TextField。

age0兄, 变化在软件开发中是没有办法避免的, 而且Ioc不是万能的，有很多情况是没有办法用到Ioc的。

是啊，其实用了模式就是隐含着遵守了OO编程里的那几大基本原理，OP了，DI了，等等。换句话说，如果我们开发时能够考虑到所有这些基本原理的话，也不需要太拘泥于模式。

现在只期盼能有牛人给出在真实情况中使用复杂工厂的scenario，呵呵。
GUI是一个，应该还有更多。

叫我怎么说呢? 我发现大家都在那里兴致勃勃地炒概念,现在炒的最多的就是Ico和AOP。就好像练武术只去学那些漂亮的花架子，却对基本功不屑一顾。难怪核心技术总在国外。我想说，只学会了花架子只能蒙蒙门外汉，治标不治本，练好了基本功后，任你花架子如何变，都可以迅速拿下，以不变应万变。从根本上解决问题。

另外，Ico的历史我了解得不多，AOP可是很早就有了，只不过现在因为有几个实现才火了起来。现在似乎不论讨论任何问题，都会有人抬出Ico和AOP来。真成银弹了。

兄台，我不得不说我有些赞同你的意见了，程序员杂志现在的确有些炒作的成分，但你把它看作窗口就可以了，然而我对你关于核心技术和银弹的论调有些话要说,我对满口挂术语的人,向来是这么看的,这些人都有一个共性,就是紧跟技术发展潮流,你不得不承认这些术语带来了交流的畅通,我挂术语主要是这个目的,至于自豪感和优越感也是有的,我觉得做软件技术要坦荡,有话说,有错改,有好东西学,核心技术始终在外国,近十年是改变不了的,后十年也许也不行,如果哪天你发现中国的乒乓被人宰割了,那么用母语写软件的外国人俯首称臣的日子也到来了,不是嘛,至于pattern,我也很喜欢,各种pattern我都玩过,难说有多精通,但是你花了十年研究透pattern,软件技术确不会停滞,也不会因为aop,ioc而停滞,归入正题,我说ioc能部分替代factory是这样的,因为原本factory负责new object,很不错,object被ioc了,我们前进了一步,可是问题来了,factory由谁去new呢,于是借助ioc,我们把factory再抽离出来,现在我们可以在context.xml里去ioc了,也就是说现在由我们的手或者某些IDE来负责new,将来或许可能又有新的办法了,比如依靠意念来new出一个factory,不知道我这样阐述是不是比较符合共性的认识呢,当然我承认说factory没有什么研究是有些偏颇了,因为我们都站在不同层面考虑问题,所以追求共性吧,忘记核心,忘记银弹,抓住本质,坦荡些,放开些

spiritj兄说的很中肯，这样讨论问题我很喜欢。

怎么说呢, 我并没有说对流行的技术不闻不问，我想说的是流行的技术不过是针对某些问题而发展起来的，对实际应用非常有帮助，我本人也看了很多关于Ico和AOP的书和资料，觉得只是停留在实用上，没有太大的讨论价值，也不太值得深入研究（开发相关实现产品的除外），有多少人会去开发类似PicoContainer和Spring这类产品的呢？而且使用Ico和AOP后，我们就必须要和某些API建立了“紧耦合” -- 大多数人都是使用现有的实现，而不是自己去开发新的Ico和AOP实现。而Patterns就不同了，

1。 她有实用价值。就目前而言，只要是做软件开发，不管是开发PicoContainer, Spring, 还是 小公司自己的某行业软件，不管大小，不管定位高低， 不管行业范畴都会用到。

2。 她有讨论和研究的价值。patterns是被发现的，而不是被发明的。这些都是由无数开发专家从漫长的软件开发发展历史中沉淀出来的。想想看，学会patterns需要多少时间，而学会Ico和AOP又需要多少时间。 而且想要使用patterns时，我们不需要去学习任何独特的API, 甚至JDK的API也不需要。这样各个层次各个行业的程序员都可以参与讨论。patterns发挥作用的时间要远远长于那些流行的技术， GOF写在10多年前的，现在一样很有用，我认为将来十年也一样很有用。

3。 再就是，学通了patterns也可以帮助你更好的理解Ico和AOP的实现产品，她们用到了无数的patterns。可是反过来呢？学会了Ico和AOP，是不是可以帮助我们更好的理解patterns呢？

注重基本功，不代表不重视流行技术。而反过来，很多人追随流行技术，却忽视了基本功。

期待大家一起来参与讨论。

DP是oop的基本功，有些追求的开发者都应该有所掌握，很大程度上，我甚至觉得ioc还是dp的经典手法呢，比如多态就是依靠interface或者abstract class来ioc子类，只是那时候ioc这个叫法还没有被gof或者martin flower之类的大师所发明而已，而dp的基本就是依赖多态机制，由于程序设计语言被设计出有多态特性，才使得接口可以使用ioc来控制子类行为，这真的很高明却又很简单，所以从楼上兄台的角度来看，ioc理解起来并不困难，因为本质的东西总是很简单，只是各种pattern本身就是从纷繁复杂的场景中提取出来的，所以反过来看如果将各种共性pattern反向使用回去，并且要保证合理和优雅，理所当然是门复杂的学问了，其实我觉得ioc和aop是两个应该完全分开讨论的东西，不该合在一起的，是不是觉得当中都有个o,唤起来比较顺口呢，另外aop和oop也是相容的，这点已经达成共识了，aop是做为oop补充而诞生的

这个可是OO的features, 和Design Patterns没有关系。

ioc容器的出现并不也从来不应该影响业务代码的设计。

如果你发现有些工厂因为有了ioc容器可以不用了，一般就是两个原因：
1。 这个工厂没有ioc容器的时候本来也不应该用，你只不过偷懒了，或者根本没有意识到这个错误。
2。根本就应该用工厂。你试图利用ioc容器来代替工厂的做法是错误的。


至于说用了ioc容器就和容器紧耦合了。也是两个原因：
1。这个容器产品不够好。侵入性太强。比如avalon，比如spring里面一些XXXAware的接口。

2。你用错了。依赖注入容器被你当作廉价的service locator了。拿菜刀去削铅笔你说是谁的错？