《ASD》设计模式：Factory － 兼谈模式的滥用

operator new是个很特别的命令，只要一出现，就会破坏DIP（依赖倒置原则）和OCP（开放封闭原则），然而她又是不能避免的命令。
解决办法就是使用Factory模式，把new命令与使用者隔离开来。
然而依然需要一个地方来创建Facotry类的具体实例，不过这个工作可以放在应用程序的初始化部分来作，与其它应用还是隔离开来的。
关于Factory应该不用多写什么了。对于一个面向对象程序员来说，这可能是最常见的模式了。
不过可以谈谈什么时候该用Factory模式。

原则上说，当创建一个可能会变化的具体对象时，就应该（必须）要使用Factory模式。
然而，什么对象是会变化呢？
传统的设计方法是在最初的设计时就考虑这个问题。
可是极限编程的思想略有不同。

极限编程则认为，第一，在项目之初是很难预料哪些类是会变化的，所以不应该预先考虑这些变化。
说实话，对于设计工程师来说，要接受这个观点还真的有点痛苦。虽然我知道她说的是真的。
如果，软件不需要变化，那么面向对象的思想就失去了大半的意义。因此工程师们一定要让自己的作品能够灵活地响应变化，这也就是OCP的原则。
然而，当运用了大堆的strategy、template、factory等等模式，建造出一个叹为观止的系统后，只等着需求改变，这个系统就能体现出OCP的好处。这时就象是搭了一个完美的陷阱，只等着猎物经过。
可惜的是，猎物却常常并不从设置陷阱的地方出现。需求的改变总是出乎设计者的预想。那个陷阱成了一个完美的装饰品。
我写过很多这样的装饰品。他们唯一的用处就是给后来者作为学习的例子。

那么该在何时使用这些模式来让程序变得坚固而灵活可以承受需求的改变呢？
极限编程认为，第二，发生过变化的地方趋向于再次变化。套用一句老话，“可以跌倒，但是不可以在同一个地方跌倒”
就软件设计而言，在最初，并不去考虑应该应对什么样的变化。只有当第一次变化出现的时候，才去更改设计，让程序对这种变化能够遵守OCP的原则。并且，这种改动后的设计，应该能够应对今后出现的所有同类变化。
我想，对于设计工程师，这种观念应该是可以接受的。

设计模式的初学者，就好像拾到了一本秘籍的孩子。艺成下山，不管遇到什么都想施展一下拳脚。这就是模式的滥用。
如何避免模式的滥用，应该多考虑一下上面所说的两条原则。