终于挤出点时间，go on.
工厂模式可能是最有用的模式之一了,因为它是“面向接口编程”思想的实现者。
面向接口编程是非常优秀的思想，可以说在某种程度上将逻辑的粒度缩小到了最小，除了我关心的接口外，不用再关心接口的提供者，以及如何实现的。
但是，这样编码时的问题就是接口或者具有接口的虚类是不能够实例化的，如果我们new一个实现接口的具体类，那么还是没有解决耦合，当我们更换实现的具体类时，仍然需要修改客户端代码。如果不new一个具体类，那么我们又无法直接使用接口或虚类。怎么办？
工厂模式帮我们解决了这个问题。使用简单工厂和抽象工厂，可以只改变一处代码，重新部署工厂类即可完成实现的变化而不用重新部署客户端代码（使用抽象工厂可以创建一系列相关的类）。反射工厂，甚至不用修改任何东西。
记得我以前说过一个类似的玩笑：
需求变化了，你不用改变任何东西，ok 你是优秀的程序员
需求变化了，只用改变一处，ok,你是合格的程序员
需求变化了，需要改的地方 〉1，ok，你还是改行吧
1， 下面先说简单工厂：
class Application
{
static void Main()
{
ISomeInterface MyUse= Myfactory.GetAInstantClass();
MyUse.dosonthing();
}
}
class Myfactory
{
static ISomeInterface GetAInstantClass()
{
return myClass1;
}
}
interface ISomeInterface
{
void doSomthing();
}
class myClass1:ISomeInterface
{
void ISomeInterface.doSomething()
{.....}
}
需要更换实现方法时，我只要改动Myfactory一处就可以了Application是永远不需要变的。
2，有些简单哈，在来说说抽象工厂，这个网上资源太多了，提炼点精华：
抽象工厂模式是一种创建型的模式。抽象工厂就是生产同一个系列产品的东西，因为这一系列的产品是关联的，如果混用就可能出问题，所以就统一的在抽象工厂中进行创建。当要增加一个新的产品系列时，就多写一个工厂子类并添加相应的产品子类就可以了。
类图：
代码例子
abstract class GUIFactory
{
public static GUIFactory GetFactory()
{
int sys = ReadFromConfigFile("OS_TYPE");
if (sys == 0)
{
return new WinFactory();
}
else
{
return new OSXFactory();
}
}
public abstract Button CreateButton();
}
class WinFactory : GUIFactory
{
public override Button CreateButton()
{
return new WinButton();
}
}
class OSXFactory : GUIFactory
{
public override Button CreateButton()
{
return new OSXButton();
}
}
abstract class Button
{
public string Caption;
public abstract void Paint();
}
class WinButton : Button
{
public override void Paint()
{
Console.WriteLine("I'm a WinButton: " + Caption);
}
}
class OSXButton : Button
{
public override void Paint()
{
Console.WriteLine("I'm an OSXButton: " + Caption);
}
}
class Application
{
static void Main()
{
GUIFactory factory = GUIFactory.GetFactory();
Button button = factory.CreateButton();
button.Caption = "Play";
button.Paint();
}
}
上面只有一个button,如果还要创建一个Winlabel，OSXLabel的话，只要加在相应的工厂类中，这样做的好处如前所述，保证了创建的类都是相关的系列。
在客户端调用是多么简洁清楚啊。
反射工厂再开个帖子说，因为我想最好把反射的技术也介绍一下，反射也许有一天会改变我们的生活，全民程序员的时代，呵呵。
