java设计模式-简单工厂模式

《java设计模式-简单工厂模式》由会员分享，可在线阅读，更多相关《java设计模式-简单工厂模式（7页珍藏版）》请在装配图网上搜索。

1、NET设计模式(1): 简单工厂模式 最近一直在看设计模式，想把自己的学习笔记与大家分享一下，如果能帮助大家的话，我会非常高兴，同时也欢迎大家指出里面的不足。园子里其实关于此类文章已经很多了，如果dudu感觉放在首页欠妥的话，可以调一下。简单工厂模式（Simple Factory Pattern）介绍：简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。因为它至少不是Gof23种设计模式之一。但它在实际的编程中经常被用到，而且思想也非常简单，可以说是工厂方法模式的一个引导，所以我想有必要把它作为第一个讲一下。引入：我们在编程的时候，每当new一个对象之后，这个对象就依赖于这个类了

2、。如果在后期的维护过程中由于某些原因需要修改一下这个类，则唯一的做法就是打开源代码，进行修改，修改所有与这个对象有关的操作。这对我们是非常不利的。问题出来了：对象不能应对“具体实例化类型”的变化解决思路：套用一下李建忠李老师的话，封装变化点，哪里变化，封装哪里。在这个例子中，要实例化的类变了，就将实例化这个操作封装起来，我们可以把new这个操作移交一个具体的类，由它去负责根据我们的条件创建具体类的实例，也就是下面要说的“简单工厂模式”。定义：专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类或接口。简单工厂模式又称为静态工厂方法（Static Factory Method）

3、模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。意图：提供一个类，由它负责根据一定的条件创建某一具体类的实例参与者： 工厂角色（Creator）是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。 抽象产品角色（Product）是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。 具体产品角色（Concrete Product）继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。 UML图：现实生活中例子：每次参加不同的聚会或者与不同的人见面，可能穿的衣服是不一样的

4、，比如，你今天上午要与你的一个新客户见面，你可能会对你的老婆说：老婆，给拿件商务装（参数），我要去见我的一个客户，你老婆（工厂类）接到你的请求（商务装参数）后，从衣柜中取出一件商务装（具体产品），交给你。整个过程就完成了。分析：你可能根据不同的条件，要的衣服是不一样的，但要的衣服都是已经在你的衣柜中存在的。并且，每件上衣它们都属于同一种抽象，即它们可以从一个抽象类或接口中继承，这此衣服各自都有一定特征，这些都是条件。然后你要的时候，就可以向你老婆说一种特征，她就会根据这个特征为你服务了。这就是典型的简单工厂模式的应用。抽象产品类代码1/*/2/抽象产品类:上衣3/4publicinterfac

5、eICoat56voidGetYourCoat();7 非常简单，是吧？这里我只是举一个仅仅能说明问题的例子，在具体的项目中，可能是很复杂的哦。具体产品类代码1namespaceSimpleFactory23/*/4/具体产品类：商务上衣5/6publicclassBusinessCoat:ICoat78publicvoidGetYourCoat()910Console.WriteLine(商务上衣);11121314/*/15/具体产品类：时尚上衣16/17publicclassFashionCoat:ICoat1819/*/20/实现ICoat中定义的方法21/22/23publicvoi

6、dGetYourCoat()2425Console.WriteLine(时尚上衣);262728简单工厂模式中最核心的部分：工厂类1namespaceSimpleFactory23/*/4/简单工厂模式中的核心部分:工厂类5/6publicclassFactory78publicICoatCreateCoat(stringstyleName)910switch(styleName.Trim().ToLower()1112casebusiness:13returnnewBusinessCoat();14casefashion:15returnnewFashionCoat();16default:

7、17thrownewException(还没有你要的那种衣服);18192021再看一下客户在调用的时候的代码1/*/2/客户类3/4classClient56staticvoidMain(stringargs)78ICoatfood;9try1011Factoryfactory=newFactory();1213Console.Write(我要的是时尚上衣t);14food=factory.CreateCoat(fashion);15food.GetYourCoat();161718catch(Exceptionex)1920Console.WriteLine(ex.Message);212

8、223到这里，代码就完成了。在客户端的代码中有我们就可以根据具体的参数，返回我们希望返回的对象，将new操作推迟到工厂类中实现。这里，参数我直接写上了，我们其实可以将这个参数写到一个xml文件中，如app.config文件中，动态的读出来，需要穿另外一种衣服了，只需要打开app.config文件，修改里面的值就行了，不需要项目重新编译。这样这个小程序就能够适应一定的变化了（在上传上去的代码中我会修改一下）。其实它也是设计模式正要解决的问题，在不修改代码的情况下，使项目能够适应一定的客户需求变化。注意，是一定的，并非全部。优点： 简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对

9、象。通过它，外界可以从直接创建具体产品对 象的尴尬局面中摆脱出来。 外界与具体类隔离开来，偶合性低。 明确区分了各自的职责和权力，有利于整个软件体系结构的优化。 缺点： 工厂类集中了所有实例的创建逻辑，容易违反GRASPR的高内聚的责任分配原则 虽然简单工厂模式能够适应一定的变化，但是它所能解决的问题是远远有限的。它所能创建的类只能是事先教考虑到的，如果需要添加新的类，则就需要改变工厂类了。（这个问题在下一个工厂方法模式将得到很好的解决） 应用情景 工厂类负责创建的对象比较少 客户只知道传入了工厂类的参数，对于始何创建对象（逻辑）不关心 参考资料 深入浅出设计模式(C#/Java版) 清华大学

10、出版社 MSDN Webcast C#面向对象设计模式纵横谈 李建忠老师 源程序下载：/Files/anlyren/SimpleFactory.rarBY-fangang在上一章（原创）一个优秀软件开发人员的必修课：GRASP（2）低耦合中我聊了聊低耦合，今天我想再聊聊与低耦合休戚相关、GRASP的另一个重要的模式：高内聚。2.高内聚（High Cohesion）高内聚是另一个普遍用来评判软件设计质量的标准。内聚，更为专业的说法叫功能内聚，是对软件系统中元素职责相关性和集中度的度量。如果元素具有高度相关的职责，除了这些职责内的任务，没有其它过多的工作，那么该元素就具有高内聚性，反之则为低内聚性

11、。高内聚要求软件系统中的各个元素具有较高的协作性，因为在我们在完成软件需求中的一个功能，可能需要做各种事情，但是具有高内聚性的一个元素，只完成它职责内的事情，而把那些不在它职责内的事情拿去请求别人来完成。这就好像，如果我是一个项目经理，我的职责是监控和协调我的项目各个阶段的工作。当我的项目进入需求分析阶段，我会请求需求分析员来完成；当我的项目进入开发阶段，我会请求软件开发人员来完成；当我的项目需要测试的时候，我会请求测试人员。如果我参与了开发，我就不是一个高内聚的元素，因为开发不是我的职责。我们的项目为什么要高内聚呢？我觉得可以从可读性、复用性、可维护性和易变更性四个方面来理解。1可读性一个人

12、写文章、讲事情，条理清晰才能易于理解，这同样发生在读写软件代码上。如果一堆代码写得一团乱麻，东一个跳转西一个调用，读它的人会感觉非常头疼。这种事情也许一直在写程序的你我都曾经有过经历。如果一段程序条理非常清晰，每个类通过名称或说明都能清楚明白它的意义，类的每个属性、函数也都是易于理解的它所应当完成的任务和行为，这段程序的可读性必然提高。在软件产业越来越密集，软件产业中开发人员协作越来越紧密、分工越来越细的今天，软件可读性的要求相信也越来越为人们所重视。2复用性在软件开发中，最低等级的复用是代码拷贝，然后是函数的复用、对象的复用、组件的复用。软件开发中最懒的人是最聪明的人，他们总是想到复用。在代

13、码编写的时候突然发现某个功能是曾经实现过的功能，直接把它拷贝过来就ok了。如果这段代码在同一个对象中，那么就提出来写一个函数到处调用就行了。如果不是在同一个对象中呢，就将其抽象成一个对象到处调用吧。如果不在一个项目中呢，那就做成组件给各个项目引用吧。代码复用也使我们的代码在复用的过程中不断精化、不断健壮、提高代码质量。代码的复用的确给我们的开发带来了不少便利，但是一段代码能否在各个需要的地方都能复用呢？这给我们的软件开发质量提出了新的要求：好的代码可以复用，不好的则不行。软件中的一个对象如果能保证能完成自己职能范围内的各项任务，同时又不去理会与自己职能无关的其它任务，那么它就能够保证功能的相对

14、独立性，也就可以脱离自己所处的环境而复用到其它环境中，这是一个具有内聚性的对象。3可维护性和易变更性在前面如何在struts+spring+hibernate的框架下构建低耦合高内聚的软件中我提到，我们现在的软件是在不断变更的，这种变更不仅来自于我们的客户，更来自于我们的市场。如果我们的软件通过变更能及时适应我们的市场需求，我们就可以在市场竞争中获胜。如何能及时变更以适应我们的市场呢，就是通过调整软件的结构，使我们每次的变更付出的代价最小，耗费的人力最小，这种变更才最快最经济。高内聚的软件，每个系统、模块、类的任务都高度相关，就使每一次的变更涉及的范围缩小到最小。比如评审表发生了变更，只会与评

15、审表对象有关，我们不会去更改其它的对象。如果我们能做到这一点，我们的系统当然是可维护性好、易变更性好的系统。 那么，我们如何做到高内聚呢？就拿前面我提到的评审项目举例。我现在要为“评审表”对象编写一段填写并保存评审表的代码。评审表对象的职责是更新和查询评审表的数据，但是在显示一个要填写的评审表的时候，我需要显示该评审计划的名称、该评审计划有哪些评审对象需要评审。现在我如何编写显示一个要填写的评审表的代码？我在评审表对象的这个相应的函数中编写一段查询评审计划和评审对象的代码吗？假如你这样做了，你的代码就不是高内聚的，因为查询评审计划和评审对象的数据不是它的职责。正确的方法应当去请求“评审计划”对

16、象和“评审对象”对象来完成这些工作，而“评审表”对象只是获取其结果。另外，如果一个对象要完成一个虽然在自己职责范围内，但过程非常复杂的任务时，也应当将该任务分解成数个功能相对独立的子函数来完成。我曾经看见一个朋友写的数百行的一个函数，让人读起来非常费劲。同时这样的函数中一些相对独立的代码，本可以复用到其它代码中，也变成了不可能。所以我给大家的建议是，不要写太长的函数，超过一百行就可以考虑将一些功能分解出去。与“低耦合”一样，高内聚也不是一个绝对，而是一个相对的指标，应当适当而不能过度。正如我们在现实生活中，如果在一个十来人的小公司，每个人的分工可能会粗一些，所分配的职责会广一些杂一些，因为其总

17、体的任务少；而如果在一个一两百人的大公司，每个人的分工会细一些，所分配的任务会更加专一些，因为总体任务多，更需要专业化的分工来提高效率。软件开发也是一样，如果“评审计划”对象完成的业务功能少，并且不复杂，它完全可以代理它的子表“评审对象”和“评审者”的管理。但是“评审计划”对象需要完成的“对评审计划表的管理”这个基本职责包含的业务功能繁多或者复杂，它就应当将“对评审对象表的管理”交给“评审对象”对象，将“对评审者表的管理”交给“评审者”对象。同样，高内聚的可维护性好、易变更性好只能是一个相对的指标。如果一个变更的确是大范围的变更，你永远不可能通过内聚就不进行大范围的变更了。同时内聚也是要付出代价的，所以你也不必要去为了一个不太可能的变更去进行过度设计，应当掌握一个度。过度的内聚必将增加系统中元素之间的依赖，提高耦合度。所以“高内聚”与“低耦合”是矛盾的，必须权衡利弊，综合地去处理。在李洋等人翻译的UML和模式应用中，将内聚和耦合翻译为软件工程中的阴与阳，是中国人对内聚和耦合的最佳解释。综上所述，“高内聚”给软件项目带来的优点是：可读性强、易维护和变更、支持低耦合、移植和重用性强