简单工厂模式

记得第一次接触设计模式是从园子上的一篇博文看起的。

http://www.cnblogs.com/anlyren/archive/2008/01/25/simple_Factory_Pattern.html 

这篇博文将简单工厂模式讲得即简练又通俗，算是给了我一次初窥设计模式之美的机会，不过那时还是流于字面上的肤浅理解，直到后来的一次小项目经历，才有机会派上用场。

项目截图：

项目概况：实现基于WF的网页新闻内容下载(数据采集部分)

项目需求：支持多个主流网站门户的新闻内容下载 

需求分析：（因为个人想阐述一下简单工厂模式的运用，所以一些细节，如页面内容如何下载，我就略去文字了）各个门户网站的采集标签既有不同点又有相同点。相同点是页面标题，css，charset，直接用web相同的标签正则匹配，不同点是页面新闻主体内容，需要用到不同的标签。

代码设计：

基类：

子类：

    这样处理的话就能实现代码重用以及很好的扩展性，可以针对不同的门户网实现不同的子类。（其实这里有一点处理得很不好，就是那些匹配的采集规则写死在代码里面，这样就造成了紧耦合，要实现修改规则就只能修改源代码并再次编译代码，这并不是一个友善的处理。改进方法：可以用XML文件存储这些匹配规则，再建立一个类，可以做映射处理，从类中读取出XML文件中的规则。这样，要修改规则，只需修改XML文件，并不需要对代码再次编译，可维护性以及扩展性得到了很大的提升。）

工厂封装：

（这里又出现了一些弊端，工厂封装应该专注于实例化对象，实现单一职责原则，而不应该把方法也写在同一个类中。改进方法：工厂应该专注于实例化对象的操作，在此之为建立另一个类实现业务逻辑，就是将原本在同一个类的代码进行分离。而且，对于命名也应该遵循一定的准则，特别是工厂的命名。如：DataFactory.CreateData（）的静态方法。）

业务逻辑：

在客户端就只用这两句代码就实现了数据采集。

 

总结：简单工厂关心的就是如何去实例化对象的问题。

后续：

    一次滥用简单工厂模式的反思：这次面对的问题是电子商务的的电子支付平台问题

    基类：

    

    子类：

    

    

    枚举：

    

    工厂：

    

    （这里我依照自己的思维第一时间就想到了简单工厂，而且毫不犹豫就劈哩哗啦地动工，等到写到了创建对象的工厂方法时，我的膝盖便中了一箭，构造函数需要参数！而且不同的实例的构造函数所需的参数个数不同！可见，简单工厂不是万能工厂。）