设计模式优缺点及应用场景
- 格式:docx
- 大小:24.84 KB
- 文档页数:23
设计模式的优缺点设计模式是一种被广泛应用于软件设计领域的解决问题的思维方式,它包括了一系列的解决方案,帮助开发人员快速地解决一些常见的软件设计问题。
然而,在使用设计模式时,我们也需要认清它的优点和缺点。
优点1. 可维护性提高设计模式将软件拆分成多个独立的组件,这些组件之间具有低耦合性和高内聚性,这使得维护变得更加容易。
在软件需求发生变化时,只需要修改一个组件而不影响其他组件,同时也使得代码重用变得更加容易,大大提高了软件的可维护性。
2. 可扩展性提高当软件需求发生变化,我们可以很方便地往软件中加入新的组件,修改现有的组件,使得软件的功能得到扩展。
设计模式将组件之间的关系更加清晰,使得扩展变得更加容易。
3. 代码重用性提高设计模式将模块划分为不同的组件,每个组件都有自己的职责和功能,这使得组件可以在不同的软件中进行复用,避免了代码重复的情况出现,提高了软件的编写效率。
4. 提高代码可读性设计模式的使用有助于提高代码的可读性。
由于每个组件职责单一而明确,所以代码的逻辑结构变得更加清晰,使得代码更加易于维护和理解。
5. 软件质量提高通过设计模式,软件稳定性更高、可靠性更强,避免了出现一些常见的错误,同时,设计模式的使用也使得软件的架构更加合理,功能更加完善,从而提高了软件的质量。
缺点1. 学习和使用门槛较高设计模式是一种高级的软件设计思维方式,学习和使用门槛较高,需要有一定的编程经验和对软件设计的理解。
同时,在实际使用中,需要将其应用到实际场景中,设计合理的组件结构,这也需要一定的技术经验和实践经验。
2. 可能会影响软件性能设计模式在增加软件的灵活性和可扩展性的同时,可能也会增加代码的复杂性,导致软件性能的下降。
因此,在使用设计模式时,需要在可维护性和性能之间做出平衡,根据实际情况选择合适的方案。
3. 可能会导致过度工程化由于设计模式有助于提高软件可维护性、可扩展性和代码可读性,因此在使用过度的情况下,可能会导致代码变得过于复杂和冗长,增加开发人员的工作量,同时也可能会对软件的开发周期和成本造成影响。
单例设计模式优缺点及使⽤场景单利模式的优缺点和使⽤场景⾸先介绍⼀下单例模式:单例模式(Singleton),也叫单⼦模式,是⼀种常⽤的软件设计模式。
在应⽤这个模式时,单例对象的类必须保证只有⼀个实例存在。
许多时候整个系统只需要拥有⼀个的全局对象,这样有利于我们协调系统整体的⾏为。
⽐如在某个服务器程序中,该服务器的配置信息存放在⼀个⽂件中,这些配置数据由⼀个单例对象统⼀读取,然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。
这种⽅式简化了在复杂环境下的配置管理。
实现单例模式的思路是:⼀个类能返回对象⼀个引⽤(永远是同⼀个)和⼀个获得该实例的⽅法(必须是静态⽅法,通常使⽤getInstance这个名称);当我们调⽤这个⽅法时,如果类持有的引⽤不为空就返回这个引⽤,如果类保持的引⽤为空就创建该类的实例并将实例的引⽤赋予该类保持的引⽤;同时我们还将该类的构造函数定义为私有⽅法,这样其他处的代码就⽆法通过调⽤该类的构造函数来实例化该类的对象,只有通过该类提供的静态⽅法来得到该类的唯⼀实例。
需要注意的地⽅:单例模式在多线程的应⽤场合下必须⼩⼼使⽤。
如果当唯⼀实例尚未创建时,有两个线程同时调⽤创建⽅法,那么它们同时没有检测到唯⼀实例的存在,从⽽同时各⾃创建了⼀个实例,这样就有两个实例被构造出来,从⽽违反了单例模式中实例唯⼀的原则。
解决这个问题的办法是为指⽰类是否已经实例化的变量提供⼀个互斥锁(虽然这样会降低效率)。
优点:1.在单例模式中,活动的单例只有⼀个实例,对单例类的所有实例化得到的都是相同的⼀个实例。
这样就防⽌其它对象对⾃⼰的实例化,确保所有的对象都访问⼀个实例2.单例模式具有⼀定的伸缩性,类⾃⼰来控制实例化进程,类就在改变实例化进程上有相应的伸缩性。
3.提供了对唯⼀实例的受控访问。
4.由于在系统内存中只存在⼀个对象,因此可以节约系统资源,当需要频繁创建和销毁的对象时单例模式⽆疑可以提⾼系统的性能。
软件设计模式及应用场景分析随着计算机技术的不断发展和应用范围的扩大,软件开发变得越来越复杂、庞大,软件设计的可靠性和可维护性也随之变得更加重要。
为了解决这些问题,软件设计模式应运而生。
软件设计模式被定义为一组可用于解决特定问题的重复性方案。
它们旨在提高软件开发的效率和可重用性,并增加代码的可读性和可维护性。
设计模式是编程中的一种有力工具,它们提供了一种有效的方法,用于解决复杂问题和设计灵活的、可扩展的解决方案。
常见的设计模式以下是一些常见的软件设计模式:1. 工厂模式:一种创建对象的方式,它隐藏了对象的创建细节,使得代码更加灵活和可扩展。
2. 单例模式:一种确保一个类只有一个实例并提供全局访问的方式。
3. 观察者模式:一种在对象之间建立一种订阅和发布关系的方式,当一个对象状态发生改变时,其他对象都会被通知并执行相应的操作。
4. 策略模式:一种在 runtime 时选择执行哪种算法的方式。
5. 适配器模式:一种将一个接口转换为另一个接口的方式,从而让原来不兼容的对象能够协同工作。
6. 模板方法模式:一种通过定义算法骨架来提供代码复用的方式,允许子类在不改变算法基本框架的情况下重新定义算法的某些步骤。
7. 装饰者模式:一种在运行时动态扩展一个对象的功能的方式,通过将一个装饰类包装在一个现有对象的外部来实现对该对象的扩展。
8. 迭代器模式:允许客户端遍历容器中的元素,而无需了解容器的内部实现,从而提供更好的代码抽象。
应用场景以下是几个适合使用设计模式的场景:1. 软件系统需要大量的复杂对象。
2. 软件系统需要扩展性高,可维护性好。
3. 软件系统需要在运行时动态改变算法。
4. 软件系统需要隐藏对象的创建细节。
总结软件设计模式是一种帮助开发人员提高软件开发效率和代码可读性的重要工具。
它们不仅提供了一种解决特定问题的方法,还提供了一种通用解决方案,能够帮助开发人员更好地组织和管理代码。
在选择使用设计模式时,需要考虑到软件系统的需求以及其未来的发展方向。
10种常见的软件体系架构模式分析以及它们的用法、优缺点有没有想过要设计多大的企业规模系统?在主要的软件开发开始之前,我们必须选择一个合适的体系结构,它将为我们提供所需的功能和质量属性。
因此,在将它们应用到我们的设计之前,我们应该了解不同的体系结构。
根据维基百科中的定义:
架构模式是一个通用的、可重用的解决方案,用于在给定上下文中的软件体系结构中经常出现的问题。
架构模式与软件设计模式类似,但具有更广泛的范围。
在本文中,将简要地解释以下10种常见的体系架构模式,以及它们的用法、优缺点。
一. 分层模式
这种模式也称为多层体系架构模式。
它可以用来构造可以分解为子任务组的程序,每个子任务都处于一个特定的抽象级别。
每个层都为下一个提供更高层次服务。
一般信息系统中最常见的是如下所列的4层。
•表示层(也称为UI层)•应用层(也称为服务层)•业务逻辑层(也称为领域层)•数据访问层(也称为持久化层)
使用场景:•一般的桌面应用程序•电子商务Web应用程序
二. 客户端-服务器模式
这种模式由两部分组成:一个服务器和多个客户端。
服务器组件将为多个客户端组件提供服务。
客户端从服务器请求服务,服务器为这些客户端提供相关服务。
此外,服务器持续侦听客户机请求。
使用场景:•电子邮件,文件共享和银行等在线应用程序
三. 主从设备模式
这种模式由两方组成;主设备和从设备。
主设备组件在相同的从设备组件中分配工作,并计算最终结果,这些结果是由从设备返回的结果。
使用场景:•在数据库复制中,主数据库被认为是权威的来源,并且要与之同步•在计算。
一、表述三个及以上的设计模型,并比较其各自优缺点1、瀑布模型:瀑布模型(Waterfall Model)是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好“返回”上一个阶段并进行适当的修改,项目开发进程从一个阶段“流动”到下一个阶段,这也是瀑布模型名称的由来。
包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
瀑布模型的优点:(1)为项目提供了按阶段划分的检查点(2)当前一阶段完成后,您只需要去关注后续阶段(3)可在迭代模型中应用瀑布模型瀑布模型的缺点:(1)开发过程一般不能逆转,否则代价太大;(2)实际的项目开发很难严格按该模型进行;(3)客户往往很难清楚地给出所有的需求,而该模瀑布模型的使用范围:型却要求如此。
(4)软件的实际情况必须到项目开发的后期客户才能看到,这要求客户有足够的耐心。
2、快速原型模型快速原型模型需要迅速建造一个可以运行的软件原型,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。
快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义,快速设计开发出软件系统的原型,该原型向用户展示待开发软件的全部或部分功能和性能;用户对该原型进行测试评定,给出具体改进意见以丰富细化软件需求;开发人员据此对软件进行修改完善,直至用户满意认可之后,进行软件的完整实现及测试、维护。
优点:(1)可以得到比较良好的需求定义,容易适应需求的变化;(2)有利于开发与培训的同步;(3)开发费用低、开发周期短且对用户更友好。
缺点:(1)客户与开发者对原型理解不同;(2)准确的原型设计比较困难;(3)不利于开发人员的创新。
3、增量模型增量模型是把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地分析、设计、编码和测试这些增量组件。
设计模式理解与应用设计模式是指在软件开发中,经常遇到的一些具有普遍重用价值的问题的解决方案,是对软件设计中普遍存在(反复出现)的各种问题,所提出的解决方案。
设计模式是一种高级软件解决方案,它将软件开发中的各种可重用的问题进行了通用化的抽象和描述,从而形成了一种通用的模式,可以被开发人员按照一定的规则和原则应用于具体的软件设计中。
第一章:理解设计模式设计模式的概念最早由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四个人在 1995 年提出,他们在《设计模式:可复用面向对象软件的基础》一书中介绍了 23 种常用的设计模式。
设计模式是一种经过长期验证,具有一定普遍性的解决方案,它并不把所有的问题都囊括进去,因此我们在使用时要根据实际情况去选择适合的模式。
设计模式通常分为 3 大类:创建型模式、结构型模式和行为型模式。
创建型模式主要解决对象的创建问题,包括单例模式、工厂模式、抽象工厂模式、建造者模式、原型模式。
结构型模式主要解决组合对象和对象之间的关系问题,包括适配器模式、桥接模式、装饰器模式、组合模式、外观模式、享元模式、代理模式。
行为型模式主要针对对象之间的通信问题,包括责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式。
第二章:应用设计模式设计模式的使用,可以大大提高软件的开发效率和质量,但在使用之前,必须先对设计模式进行深入的学习和理解。
在实际应用中,我们要充分评估自己的开发需求,并根据实际情况,在设计阶段中使用其中一些设计模式。
例如,当我们需要使用一个日志库来记录系统运行过程中产生的各种日志信息时,可以采用单例模式来保证系统中只有一个日志实例,这样可以避免资源的浪费,提高系统效率。
再如,当我们需要使用一个网络连接库,在不同的平台中都能够正确地实现网络连接时,可以使用抽象工厂模式,通过工厂方法来创建各种不同类型的网络连接,从而在不同平台中实现连接的正确性和可靠性。
23种设计模式范文设计模式是软件开发中常用的解决方案模式,它们代表了在面对特定问题时的最佳实践和经验总结。
设计模式可以帮助我们更好地组织和设计代码,提高代码的可读性、可维护性和可扩展性。
在本文中,我们将介绍23种常用的设计模式,并分别讨论它们的实现原理和在实际开发中的应用场景。
1. 单例模式(Singleton Pattern)单例模式是最简单的设计模式之一,它确保一个类只有一个实例,并提供一个全局访问点。
在实现上,可以通过将构造函数私有化,然后提供一个静态方法返回实例来实现单例。
应用场景:在需要实现全局唯一访问点的场景下,比如线程池、配置管理器等。
2. 工厂模式(Factory Pattern)工厂模式是用来创建对象的一种模式,它将对象的创建和实现分离,使得代码更易于维护和扩展。
工厂模式有简单工厂模式、工厂方法模式和抽象工厂模式等几种不同的变体。
应用场景:在需要根据不同条件创建不同对象的场景下,比如数据库连接、日志记录等。
3. 抽象工厂模式(Abstract Factory Pattern)抽象工厂模式是工厂模式的一种扩展,它提供一个创建一系列相关或相互依赖对象的接口,而无需指定实际的类。
抽象工厂模式将一组工厂类封装起来,使其可以交换或者替换。
应用场景:在需要创建一组相关对象(如界面主题、操作系统等)并且需要保持一致性的场景下。
4. 建造者模式(Builder Pattern)建造者模式是用来生成复杂对象的一种模式,它将对象的构建与其表现分离,采用逐步构建的方式生成对象,可以让客户端不需要知道具体的构建细节。
应用场景:在构造过程比较复杂,需要多个组件协同工作的场景下,比如构建复杂的UI界面。
5. 原型模式(Prototype Pattern)原型模式是用来克隆对象的一种模式,它通过复制已有对象的原型来创建新的对象,避免了通过构造函数创建对象和初始化成员变量的重复过程。
应用场景:在需要创建大量相似对象或者初始化成本较高的对象时,可以使用原型模式。
设计方案的优缺点分析报告设计方案的优缺点分析报告设计方案是指在完成某项任务或解决某个问题时所制定的一套具体的步骤和方案,它通常是经过深入研究和分析后得出的最佳解决方案。
设计方案的优缺点分析报告是对一个设计方案进行全面评价和分析的报告,旨在为决策者提供参考,帮助他们做出明智的决策。
在进行设计方案的优缺点分析之前,需要明确设计方案的目标和要求。
这样可以确保评价的准确性和客观性。
然后,可以根据设计方案的特点和实际情况,对其进行以下方面的优缺点分析:1. 创新性:设计方案的创新性是评价其优劣的重要指标。
一个创新的设计方案通常能够提供新颖的解决方案,满足用户的需求,并能够在市场中具有竞争力。
而缺乏创新的设计方案可能导致产品或服务的陈旧化,难以吸引用户。
2. 可行性:设计方案的可行性是其是否能够在实际环境中有效实施的关键。
评估一个设计方案的可行性时,需要考虑技术、经济、法律、资源等各方面的限制条件。
一个可行的设计方案应该能够充分利用有限的资源,达到预期的效果,并且能够在合理的成本范围内实现。
3. 可靠性:设计方案的可靠性是指其在长期使用和运行过程中是否能够保持稳定和高效。
一个可靠的设计方案应该具有较低的故障率,能够适应不同的环境变化和使用需求。
同时,应该具备良好的可维护性和可扩展性,以便随着需求的变化进行相应的调整和改进。
4. 用户体验:用户体验是评价设计方案优劣的重要指标之一。
一个好的设计方案应该能够提供良好的用户体验,使用户在使用过程中感到舒适、便捷和满意。
因此,在设计方案的分析中,需要考虑用户的需求和期望,并根据其特点和偏好进行相应的设计和优化。
5. 可持续性:设计方案的可持续性是指其在长期运行中是否能够持续地提供价值和效益。
一个可持续的设计方案应该能够适应社会和环境的变化,并能够在不断变化的市场中保持竞争力。
同时,还应该考虑资源的合理利用和环境的保护,以实现可持续发展的目标。
综上所述,设计方案的优缺点分析报告是对一个设计方案进行全面评价和分析的重要工具。
产品设计评估优缺点
优点
1. 用户体验优化:一个好的产品设计能够提供良好的用户体验,使用户能够轻松地理解和使用产品。
2. 功能完善:优秀的产品设计能够满足用户的需求,提供丰富
的功能和特性,从而增加产品的吸引力。
3. 界面美观:通过合理的界面设计,产品能够呈现出美观的外观,增加用户的使用欲望。
4. 创新性:好的产品设计能够带来创新性的解决方案,提供新
的使用体验和价值。
5. 可持续性:优秀的产品设计考虑到环境和社会因素,致力于
可持续发展,降低资源消耗和环境污染。
缺点
1. 成本问题:一些优秀的产品设计可能需要高昂的成本投入,
在生产和制造过程中造成较大的开销。
2. 技术限制:有时候产品设计的创意和功能受到技术限制,无
法完全实现设计者的愿景。
3. 用户反馈:有时候产品设计可能不符合用户的实际需求,导
致用户不满意或不愿意使用。
4. 时间压力:为了迅速推出新产品,可能导致产品设计过程中
出现时间压力,影响质量和创新性。
5.市场竞争:如果产品设计不能与竞争对手相比较,可能会导
致产品的市场份额下降。
总结起来,优秀的产品设计能够带来良好的用户体验、丰富的
功能、美观的界面和创新性的解决方案,但也可能面临成本、技术、用户反馈、时间压力和市场竞争等方面的挑战。
安卓中设计模式及应用场景设计模式是指在软件开发中可复用的解决问题的经验总结和最佳实践。
在安卓开发中,设计模式能帮助我们构建可维护、可扩展和可重用的应用程序。
下面将介绍几种常见的设计模式及其在安卓开发中的应用场景。
1. 单例模式(Singleton Pattern):单例模式用于确保一个类只有一个实例,并提供一个全局访问点。
在安卓开发中,有些情况下我们只需要一个全局对象,例如数据库管理器、网络请求管理器等。
通过单例模式可以确保只有一个实例存在,方便在各处进行访问。
2. 观察者模式(Observer Pattern):观察者模式定义了对象之间的一对多依赖关系,当一个对象的状态发生改变时,其依赖的对象们会收到通知并作出相应的更新。
在安卓中,我们可以利用观察者模式实现事件总线来进行组件之间的通信,例如使用EventBus库。
当某一组件的状态变化时,可以通过事件总线通知其他组件进行相应的操作。
3. 工厂模式(Factory Pattern):工厂模式定义了一个创建对象的接口,由子类决定实例化哪个类。
在安卓开发中,工厂模式经常用于创建各种不同类型的对象,能很好地实现解耦和复用。
例如在RecyclerView 的Adapter 中,在不同的情况下需要创建不同的ViewHolder,可以使用工厂模式根据需求创建不同的ViewHolder。
4. 适配器模式(Adapter Pattern):适配器模式将一个类的接口转换成客户端所期望的另一个接口,从而使得原本不兼容的类能够一起工作。
在安卓中,ListView 和RecyclerView 常常需要使用适配器来将数据源与界面进行绑定,使得数据能够正确地显示在界面上。
5. 建造者模式(Builder Pattern):建造者模式将一个复杂对象的构建过程与其表示分离,使得同样的构建过程可以创建不同的表示。
在安卓开发中,用于构建复杂的对象可以使用建造者模式。
例如,在创建一个对话框时,可以通过使用建造者模式来设置对话框的标题、按钮、样式等属性,使得创建过程更加灵活和可扩展。
设计模式在项目中的实际应用一、总览设计模式是一组可以应用在软件开发过程中的经过验证的解决方案,旨在改善和改良代码、结构和架构。
它们是由计算机科学及人工智能研究的先驱们发展出来的,他们的目的是加快开发过程,减少代码中出现的Bug,优化代码组织架构,从而带来更好的效率、可读性和可扩展性。
设计模式成为一个关键概念,它不仅仅用于软件开发,也可以应用于其他行业。
正确使用设计模式有助于提高项目的可维护性和可维护性,以及减少潜在的出错风险。
二、设计模式在项目中的实际应用1、工厂模式工厂模式是非常经典的模式,它可以解决在软件系统中重复出现的类型分类问题。
工厂模式的关键思想是,将类型的定义分离出来,定义一个用于创建具有某种共同特征的对象的抽象方法,用于构建各种类型,而无需关心这些类型的实现。
在项目中,工厂模式可以以更加灵活的方式将不同的类型和不同的实现结合起来,它可以让我们轻松地添加新类型,而不用修改任何已有代码,从而提高项目的可维护性。
2、模板方法模式模板方法模式是一种行为型设计模式,它定义了算法的步骤,并允许子类对其中的某些步骤进行替换,而不会破坏整个算法的结构。
它可以让我们把一些复杂的操作封装起来,从而使得整个业务流程更加清晰,更加可维护。
在项目中,可以使用模板方法模式来模拟一个复杂的业务流程,将细节的操作封装起来,使得系统更容易理解和操作,从而提高整个项目的可持续性。
3、单例模式单例模式是保证系统中只有一个实例的一种设计模式,它可以避免多次创建实例,从而节省系统的资源。
在项目中,单例模式可以提供一个全局的接口,在任何地方调用该接口都会返回同一个实例,这样可以保证系统中只有一个实例,从而减少内存的消耗,提高系统的效率。
4、状态模式状态模式是一种行为模式,它可以把实例的行为封装成一个个状态,并且可以在不同的状态之间进行切换。
这样可以极大程度上简化实例的操作,使得实例可以以更加优雅的方式处理复杂的逻辑。
在项目中,状态模式可以把每个状态的转换过程抽象出来,让实例能够自动地处理好复杂的状态之间的切换,从而降低了代码耦合度,增强了系统的可维护性。
23种设计模式的经典运用介绍设计模式是解决软件设计中常见问题的可重复使用的解决方案。
本文将介绍23种经典的设计模式,并给出它们在实际开发中的应用示例。
通过学习这些设计模式,您将增加对软件设计的理解,并能够更好地解决问题。
创建型设计模式1.工厂方法模式(F a c t o r y M e t h o d)工厂方法模式通过定义一个创建对象的接口,但由子类决定实例化具体类。
这种方法可以延迟实例化过程,具有更高的灵活性和可扩展性。
应用场景:-在一个系统中,希望客户端与具体类的实例化解耦。
-希望通过增加具体类的扩展来增加系统的灵活性。
2.抽象工厂模式(A b s t r a c t F a c t o r y)抽象工厂模式提供一个接口,用于创建相关或依赖对象组。
这种模式将对象的实例化推迟到子类中,从而实现了解耦。
应用场景:-当一个系统独立于其产品的创建、组合和表示时。
-当需要一个系列的相互依赖的对象而无需指定其具体类时。
3.单例模式(S i n gl e t o n)单例模式确保一个类只有一个实例,并提供一个全局访问点。
这种模式常用于控制对资源的访问,例如数据库连接或日志文件。
应用场景:-当需要一个类的唯一实例,并且该实例需要被多个客户端共享时。
-当需要限制系统中特定类的实例数量时。
4.原型模式(P r o to t y p e)原型模式通过复制现有对象来创建新对象。
这种模式对于创建需要消耗大量资源的对象非常有用,可以通过克隆现有对象来提高性能。
应用场景:-当一个系统的某些对象的创建比较昂贵时。
-当需要避免构造函数调用,而直接通过复制现有对象来创建新对象时。
5.建造者模式(B ui l d e r)建造者模式将一个复杂对象的构建过程与其表现分离,使得相同的构建过程可以创建不同的表现。
应用场景:-当想要构建一些复杂对象时,如生成器。
-当需要创建对象的过程具有多个步骤,并且每个步骤都可以按需选择或省略时。
结构型设计模式6.适配器模式(A da p t e r)适配器模式将一个类的接口转换为客户端所期望的另一个接口。
设计方案的优点缺点设计方案是指在完成一个特定项目或任务时所采用的一系列策略和方法。
无论是在建筑设计、产品设计还是网页设计等领域,设计方案都是为了达到预期的目标而制定的计划。
设计方案的优点和缺点都会直接影响到最终成果的质量和效果。
下面将就设计方案的优点和缺点展开讨论。
设计方案的优点:1. 创新性:设计方案强调创新和独特性,致力于寻找新颖的解决方案。
通过创新,设计方案可以带来全新的体验和感受,提升产品或项目的价值。
2. 个性化:设计方案可以根据不同需求进行个性化定制,满足用户或客户的具体要求。
这样可以增加用户的满意度,提高项目的成功率。
3. 综合性:设计方案综合考虑各种因素,包括功能性、美观性、可行性等。
通过综合性的设计方案,可以实现多个目标的平衡,增加项目的实际效果。
4. 提高效率:设计方案在项目开始之前就对整个过程进行了规划和安排,可以有效地提高工作效率。
通过合理的设计方案,可以避免不必要的重复工作和资源浪费。
设计方案的缺点:1. 时间成本:设计方案需要时间来进行研究和制定,可能会延长项目的周期。
特别是在需要创新和独特性的领域,设计方案的制定可能需要更多的时间和精力。
2. 成本控制:一些设计方案可能会导致成本的增加,特别是在需要高端材料或技术的情况下。
对于一些预算有限的项目,设计方案的成本可能成为制约因素。
3. 风险管理:设计方案可能存在一定的风险,特别是在面对不确定因素和市场变化时。
一些设计方案可能无法达到预期的效果,需要及时调整和改进。
4. 用户接受度:设计方案可能无法被用户或客户广泛接受。
特别是在涉及到个人喜好和文化差异的领域,设计方案可能会面临用户的不满意和拒绝。
综上所述,设计方案具有创新性、个性化、综合性和提高效率的优点,但也存在时间成本、成本控制、风险管理和用户接受度等方面的缺点。
在实际应用中,需要综合考虑各种因素,制定适合项目的设计方案,以达到最佳效果和用户满意度。
设计模式-23种设计模式整体介绍及应⽤场景、七⼤设计原则总结对象的⼀、创建型模式:都是⽤来帮助我们创建对象的!(关注(关注对象的创建过程))创建过程模式1.单例单例模式保证⼀个类只有⼀个实例,并且提供⼀个访问该实例的全局访问点。
模式("Gof book"中把⼯⼚⽅法与抽象⼯⼚分为两种模式,所以创建型模式共为⼯⼚模式2.⼯⼚五种,这⾥只是为了⽅便整理,合在了⼯⼚模式中)-简单⼯⼚模式⽤来⽣产同⼀等级结构的任意产品。
(对于增加新的产品,需要修改已有代码)-⼯⼚⽅法模式⽤来⽣成同⼀等级结构中的固定产品。
(⽀持增加任意产品)-抽象⼯⼚模式⽤来⽣产不同产品族的全部产品。
(对于增加新的产品,⽆能为⼒,⽀持增加产品族)模式3.建造者建造者模式分离了对象⼦组件的单独构造(由Builder来负责)和装配(由Director负责),从⽽可以构造出复杂的对象。
模式原型模式4.原型通过new产⽣⼀个对象需要⾮常繁琐的数据准备或访问权限,则可以使⽤原型模式。
耦合,从⽽可以松耦合,从⽽可以扩⼤扩⼤结构上实现上实现松⼆、结构型模式:是从程序的、结构型模式:是从程序的结构对象和和类的组织)类的组织)(关注对象解决更⼤的问题。
(关注整体的类结构,⽤来整体的类结构,⽤来解决更⼤的问题。
模式1.适配器适配器模式⼯作中的场景:经常⽤来做旧系统改造和升级;如果我们的系统开发之后再也不需要维护,那么很多模式都是没必要的,但是不幸的是,事实却是维护⼀个系统的代价往往是开发⼀个系统的数倍。
学习中见过的场景:java.io.InputStreamReader(InputStream); java.io.OutpuStreamWriter(OutputStream)模式2.代理代理模式核⼼作⽤:通过代理,控制对对象的访问!可以详细控制访问某个(某类)对象的⽅法,在调⽤这个⽅法前做前置处理,调⽤这个⽅法后做后置处理。
(即:AOP的微观实现!)AOP(Aspect Oriented Programming⾯向切⾯编程)的核⼼实现机制!开发框架中应⽤场景:structs2中拦截器的实现;数据库连接池关闭处理;Hibernate中延时加载的实现;mybatis中实现拦截器插件;AspectJ的实现;spring中AOP的实现(⽇志拦截,声明式事务处理);web service;RMI远程⽅法调⽤模式桥接模式3.桥接实际开发中应⽤场景:JDBC驱动程序;AWT中的Peer架构;银⾏⽇志管理:格式分类:操作⽇志、交易⽇志、异常⽇志距离分类:本地记录⽇志、异地记录⽇志⼈⼒资源系统中的奖⾦计算模块:奖⾦分类:个⼈奖⾦、团体奖⾦、激励奖⾦。
设计模式之观察者模式(Observer)详解及代码⽰例⼀、模式的定义与特点 观察者(Observer)模式的定义:观察者模式⼜被称为发布-订阅/模型-视图模式,属于⾏为型设计模式的⼀种,是⼀个在项⽬中经常使⽤的模式。
指多个对象间存在⼀对多的依赖关系,当⼀个对象的状态发⽣改变时,所有依赖于它的对象都得到通知并被⾃动更新。
⼆、观察者模式优缺点 观察者模式是⼀种对象⾏为型模式,其主要优点如下:降低了⽬标与观察者之间的耦合关系,两者之间是抽象耦合关系。
⽬标与观察者之间建⽴了⼀套触发机制。
它的主要缺点如下:⽬标与观察者之间的依赖关系并没有完全解除,⽽且有可能出现循环引⽤。
当观察者对象很多时,通知的发布会花费很多时间,影响程序的效率。
三、观察者模式的实现 实现观察者模式时要注意具体⽬标对象和具体观察者对象之间不能直接调⽤,否则将使两者之间紧密耦合起来,这违反了⾯向对象的设计原则。
观察者模式的主要⾓⾊如下。
抽象主题(Subject)⾓⾊:也叫抽象⽬标类,它提供了⼀个⽤于保存观察者对象的聚集类和增加、删除观察者对象的⽅法,以及通知所有观察者的抽象⽅法。
具体主题(Concrete Subject)⾓⾊:也叫具体⽬标类,它实现抽象⽬标中的通知⽅法,当具体主题的内部状态发⽣改变时,通知所有注册过的观察者对象。
抽象观察者(Observer)⾓⾊:它是⼀个抽象类或接⼝,它包含了⼀个更新⾃⼰的抽象⽅法,当接到具体主题的更改通知时被调⽤。
具体观察者(Concrete Observer)⾓⾊:实现抽象观察者中定义的抽象⽅法,以便在得到⽬标的更改通知时更新⾃⾝的状态。
观察者模式的结构图如图所⽰: 代码如下:public class ObserverPattern{public static void main(String[] args){Subject subject=new ConcreteSubject();Observer obs1=new ConcreteObserver1();Observer obs2=new ConcreteObserver2();subject.add(obs1);subject.add(obs2);subject.notifyObserver();}}//抽象⽬标abstract class Subject{protected List<Observer> observers=new ArrayList<Observer>();//增加观察者⽅法public void add(Observer observer){observers.add(observer);}//删除观察者⽅法public void remove(Observer observer){observers.remove(observer);}public abstract void notifyObserver(); //通知观察者⽅法}//具体⽬标class ConcreteSubject extends Subject{public void notifyObserver(){System.out.println("具体⽬标发⽣改变...");System.out.println("--------------");for(Object obs:observers){((Observer)obs).response();}}}//抽象观察者interface Observer{void response(); //反应}//具体观察者1class ConcreteObserver1 implements Observer{public void response(){System.out.println("具体观察者1作出反应!");}}//具体观察者1class ConcreteObserver2 implements Observer{public void response(){System.out.println("具体观察者2作出反应!");}} 测试结果为:具体⽬标发⽣改变...--------------具体观察者1作出反应!具体观察者2作出反应!四、观察者模式的应⽤实例 接下来再看⼀个关于上下课打铃,⽼师同学上下课的⽰例:public class BellEventTest{public static void main(String[] args){BellEventSource bell=new BellEventSource(); //铃(事件源)bell.addPersonListener(new TeachEventListener()); //注册监听器(⽼师) bell.addPersonListener(new StuEventListener()); //注册监听器(学⽣)bell.ring(true); //打上课铃声System.out.println("------------");bell.ring(false); //打下课铃声}}//铃声事件类:⽤于封装事件源及⼀些与事件相关的参数// EventObject: The root class from which all event state objects shall be derived. class RingEvent extends EventObject{private static final long serialVersionUID=1L;private boolean sound; //true表⽰上课铃声,false表⽰下课铃声public RingEvent(Object source,boolean sound){super(source);this.sound=sound;}public void setSound(boolean sound){this.sound=sound;}public boolean getSound(){return this.sound;}}//⽬标类:事件源,铃class BellEventSource{private List<BellEventListener> listener; //监听器容器public BellEventSource(){listener=new ArrayList<BellEventListener>();}//给事件源绑定监听器public void addPersonListener(BellEventListener ren){listener.add(ren);}//事件触发器:敲钟,当铃声sound的值发⽣变化时,触发事件。
设计模式优缺点及应⽤场景看完发现有不太对的地⽅告诉我下各设计模式优缺点总结1桥接模式优点:1将实现予以解耦,让它和界⾯之间不再永久绑定2抽象和实现可以独⽴扩展,不会影响到对⽅3对于“具体的抽象类”所做的改变,不会影响到客户。
缺点:1.增加了复杂度⽤途:1.适合使⽤在需要跨越多个平台的图形和窗⼝上2.当需要⽤不同的⽅式改变接⼝和实现时,你会发现桥接模式很好⽤。
具体实例:跨平台的软件,不同电视机和不同的遥控器。
2⽣成器模式(建造者模式)优点:1.将⼀个复杂对象的创建过程封装起来2.允许对象通过多个步骤来创建,并且可以改变创建过程3.向客户隐藏内部的表现4.产品的实现可以被替换,因为客户只看到⼀个抽象的接⼝缺点:1.与⼯⼚模式相⽐,采⽤⽣成器模式创建对象更复杂,其客户,需要更多的知识领域。
⽤处:⽤来创建组合结构。
典型例⼦:想不起典型例⼦还是扯那个画⼩⼈,构建⼩⼈分画头,画⾝体,画双⼿,黄双脚等不同构建部分,全部放在⼀起构建。
3职责链模式优点:1.将请求的发送者和接收者解耦2.可以简化你的对象,因为它不需要知道链的结构3.通过改变链内的成员或调动他们的次序,允许你动态地新增或删除责任缺点:1.并不保证请求⼀定会被执⾏,如果没有任何对象处理它的话,它可能会落到链尾端之外2.可能不容观察运⾏时的特征,有碍于除错。
⽤途:经常被使⽤在窗⼝系统中,处理⿏标和键盘之类的事件。
当算法牵涉到⼀种链型运算,⽽且不希望处理过程中有过多的循环和条件选择语句,并且希望⽐较容易的扩充⽂法,可以采⽤职责链模式。
1)有多个对象处理请求,到底怎么处理在运⾏时确定。
2)希望在不明确指定接收者的情况下,向多个对象中的⼀个提交请求。
3)可处理⼀个请求的对象集合应该被动态指定。
典型例⼦:⼀个请求发送给前台,前台表⽰我⽆权管理,将请求传递给财务部门,财务部门再……4蝇量模式(享元)优点:1.减少运⾏时对象实例的个数,节省内存2.将许多“虚拟”对象的状态集中管理缺点:⼀旦你实现了它,单个的逻辑实现将⽆法拥有独⽴⽽不同的⾏为⽤途:当⼀个类有许多的实例,⽽这些实例能被同⼀⽅法控制的时候,我们就可以使⽤蝇量模式。
软件开发中的设计模式及其应用随着计算机技术的快速发展,需要在开发软件时使用一些标准化的技巧和方法。
设计模式就是这些技巧和方法中的一个,它是编写高质量、易于维护和可重用的代码的利器。
设计模式将重复性的问题进行分类,并提供了一组通用的解决方案,这使得软件开发人员可以更快、更轻松地编写出高质量的代码。
在本文中,我们将介绍一些常用的设计模式,以及它们在实际软件开发中的应用。
1. 工厂模式(Factory Pattern)工厂模式是一种创建型设计模式,用来创建对象。
它将创建具体对象的过程委托给子类,由子类完成对象的创建过程,并返回对象。
使用工厂模式的好处是,它可以将对象的实现与客户端代码完全分离开来。
客户端只需要知道调用工厂方法(创建对象),而无需关心具体实现细节。
工厂模式适用于需要创建大量对象的开发场景,可以有效地降低系统的内存开销。
它还能够通过工厂的配置,动态地改变对象的创建方式,提高系统的灵活性和可扩展性。
2. 单例模式(Singleton Pattern)单例模式是一种创建型设计模式,它用来确保在整个应用程序中,一个类只有一个实例,并提供一个全局访问点。
单例模式在需要管理全局资源或共享状态时非常有用。
单例模式有多种实现方式,最常用的方法是通过私有构造函数和静态方法来实现。
这种方法可以确保只有一个类的实例,并提供一个全局访问点。
3. 装饰器模式(Decorator Pattern)装饰器模式是一种结构型设计模式,它提供了一种动态地将责任添加到对象上的方法。
装饰器模式允许我们通过在运行时添加新的功能,而不是通过编写新的子类来实现这些功能。
装饰器模式的基本思想是,创建一个装饰器类,该类包装了要装饰的对象,并提供了与原始对象一致的接口。
装饰器类可以在运行时添加新的行为,而不影响原始对象。
使用装饰器模式的好处是,它可以让我们动态地添加功能,而不需要从头开始重新设计类的结构。
此外,装饰器模式遵循单一责任原则,因此可以将不同的装饰器组合在一起,构建出复杂的对象。
设计模式案例在软件开发中,设计模式是一种被广泛应用的解决问题的方法论,它可以帮助开发人员更好地组织和管理代码,提高代码的可读性和可维护性。
设计模式不仅可以解决一些常见的问题,还可以为开发人员提供一些通用的解决方案,让他们在面对类似的问题时能够更加快速地找到解决方法。
本文将通过一些具体的案例来介绍设计模式在实际开发中的应用。
案例一,单例模式。
单例模式是一种常见的设计模式,它保证一个类只有一个实例,并提供一个全局访问点。
在实际开发中,我们经常会遇到需要保证某个类只有一个实例的情况,比如数据库连接池、线程池等。
在这种情况下,使用单例模式可以确保我们只创建一个实例,从而节省系统资源,并且可以避免一些潜在的问题,比如多个实例之间的数据不一致等。
案例二,工厂模式。
工厂模式是一种常见的创建型模式,它提供了一种统一的接口来创建对象,而不需要关心具体的实现细节。
在实际开发中,我们经常会遇到需要根据不同的条件来创建不同的对象的情况,比如根据用户的权限来创建不同的菜单,或者根据用户的地区来创建不同的支付方式等。
在这种情况下,使用工厂模式可以让我们更加灵活地创建对象,而且可以很容易地扩展新的对象类型,而不需要修改已有的代码。
案例三,观察者模式。
观察者模式是一种常见的行为型模式,它定义了一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都会得到通知并自动更新。
在实际开发中,我们经常会遇到需要实现对象之间的解耦的情况,比如一个主题对象需要通知多个观察者对象,而且这些观察者对象可能是动态变化的。
在这种情况下,使用观察者模式可以让我们更加灵活地实现对象之间的通信,而且可以很容易地扩展新的观察者对象,而不需要修改已有的代码。
结语。
设计模式是一种非常重要的编程思想,它可以帮助我们更好地组织和管理代码,提高代码的可读性和可维护性。
在实际开发中,合理地应用设计模式可以让我们更加快速地解决问题,而且可以让我们的代码更加灵活和易于扩展。
看完发现有不太对的地方告诉我下各设计模式优缺点总结1桥接模式优点:1将实现予以解耦,让它和界面之间不再永久绑定2抽象和实现可以独立扩展,不会影响到对方3对于“具体的抽象类”所做的改变,不会影响到客户。
缺点:1.增加了复杂度用途:1.适合使用在需要跨越多个平台的图形和窗口上2.当需要用不同的方式改变接口和实现时,你会发现桥接模式很好用。
具体实例:跨平台的软件,不同电视机和不同的遥控器。
2生成器模式(建造者模式)优点:1.将一个复杂对象的创建过程封装起来2.允许对象通过多个步骤来创建,并且可以改变创建过程3.向客户隐藏内部的表现4.产品的实现可以被替换,因为客户只看到一个抽象的接口缺点:1.与工厂模式相比,采用生成器模式创建对象更复杂,其客户,需要更多的知识领域。
用处:用来创建组合结构。
典型例子:想不起典型例子还是扯那个画小人,构建小人分画头,画身体,画双手,黄双脚等不同构建部分,全部放在一起构建。
3职责链模式优点:1.将请求的发送者和接收者解耦2.可以简化你的对象,因为它不需要知道链的结构3.通过改变链内的成员或调动他们的次序,允许你动态地新增或删除责任缺点:1.并不保证请求一定会被执行,如果没有任何对象处理它的话,它可能会落到链尾端之外2.可能不容观察运行时的特征,有碍于除错。
用途:经常被使用在窗口系统中,处理鼠标和键盘之类的事件。
当算法牵涉到一种链型运算,而且不希望处理过程中有过多的循环和条件选择语句,并且希望比较容易的扩充文法,可以采用职责链模式。
1)有多个对象处理请求,到底怎么处理在运行时确定。
2)希望在不明确指定接收者的情况下,向多个对象中的一个提交请求。
3)可处理一个请求的对象集合应该被动态指定。
典型例子:一个请求发送给前台,前台表示我无权管理,将请求传递给财务部门,财务部门再……4蝇量模式(享元)优点:1.减少运行时对象实例的个数,节省内存2.将许多“虚拟”对象的状态集中管理缺点:一旦你实现了它,单个的逻辑实现将无法拥有独立而不同的行为用途:当一个类有许多的实例,而这些实例能被同一方法控制的时候,我们就可以使用蝇量模式。
(这话什么意思啊,HF书上原话,是这话有问题还是我理解能力有问题?!)具体场景:五子棋中的黑白子,改变坐标状态(x,y),但用同一个实体。
5解释器模式(这个模式我真没仔细看)优点:1.将每一个语法规则表示成一个类,方便事先语言。
2.因为语法由许多类表示,所以你可以轻易地改变或扩展此语言3.通过在类结构中加入新的方法,可以在解释的同时增加新的行为,例如打印格式的梅花或者进行复制的程序验证。
缺点:当语法规则数目太大时,这个模式可能会变得非常繁琐。
用途:1.当你需要实现一个简答的语言时,使用解释器2.当你有一个简单的语法,切简单比效率更重要时,使用解释器3.可以处理脚本语言和编程语言典型例子:正则表达式6中介者模式优点:1.通过将对象彼此解耦,可以增加对象的复用性。
2.通过将控制逻辑集中,可以简化系统维护3.可以让对象之间传递的消息变得简单而且大幅减少缺点:1.如果设计不当,中介者对象本身会变得过于复杂用途:常常被用来协调相关的GUI组件(HF设计模式上的原话,这书附录A部分真的有点敷衍)经典例子:我租房,但没有户主信息,我和户主不能直接交替。
没关系,中介者类有我和户主的信息,private我,private户主。
而我和户主都认识中介者。
我将信息传递给中介者,在我中调用中介者.获取信息()方法,中介者获取信息后,再由中介者传递给户主。
7备忘录模式优点:1.将被存储的状态放在外面,不要和关键对象混在一起,可以帮助维护内聚2.保持关键对象的数据封装3.提供了容易实现的恢复能力缺点:1.储存和恢复状态的过程可能相当耗时用途备忘录模式用于存储状态,在java中可以使用序列化。
经典例子:游戏中途保存游戏,这时候可以调用保存当前状态方法,再读取的时候调用读取。
Java序列化机制在这方面非常的方便。
8原型模式优点:1.向客户隐藏制造新实例的复杂性2.提供让客户能够产生未知类型对象的选项3.在某些环境下,复制对象比新建对象更有效缺点:复制对象有时相当复杂用途:在一个复制的类层次中,当系统必须从其中的许多类型创建新对象时,可以考虑原型模式。
经典例子:随便拿一个类,给这个类写一个克隆方法,复制当前对象。
或者直接用反序列化。
9访问者模式优点:1.允许你对组合结构加入新的操作,无需改变结构本身2.想要加入新的操作相对容易3.访问者所进行的操作,其代码是集中在一起的缺点:1.会打破组合类的封装2.因为游走的功能牵涉其中,随意对组合结构的改变就更加困难。
用途:有比较稳定的数据结构,又有易于变化的算法的话,使用访问者模式就是比较合适的,因为访问者模式使得算法操作的增加变得容易。
经典场景:特么访问者模式和翻译器模式,一个看不懂,一个怎么也不想看,到时候要是让我说这两个模式,我就自认倒霉。
10简单工厂模式优点:工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。
而不必管这些对象究竟如何创建及如何组织的.明确了各自的职责和权利,有利于整个软件体系结构的优化。
缺点:由于工厂类集中了所有实例的创建逻辑,违反了高内聚责任分配原则,将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。
当系统中的具体产品类不断增多时候,可能会出现要求工厂类根据不同条件创建不同实例的需求.这种对条件的判断和对具体产品类型的判断交错在一起,很难避免模块功能的蔓延,对系统的维护和扩展非常不利;用途:工厂类负责创建的对象比较少;客户只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心;由于简单工厂很容易违反高内聚责任分配原则,因此一般只在很简单的情况下应用。
经典例子:没啥好说的,这不是一个真正的设计模式11策略模式优点:1.提供了一种替代继承的方法,而且保持了继承的优点,比继承更独立(算法独立,可以任意扩展)2.避免程序使用多重条件转移语句,使系统更灵活,并易于扩展3.遵守大部分常用设计原则,高内聚,低耦合缺点:1.每个具体策略类都会产生一个新类,所以会增加系统需要维护的类的数量。
可以使用工厂方法来解决。
用途:各个不同地区不同的纳税方法,HF中不同鸭子的方法。
有多种鸭子,每个鸭子都有自己的行为,fly,quaak之类的。
行为有行为类,继承同一接口实现不同操作,以此实现算法互换。
12装饰模式优点:1.装饰模式与继承关系的目的都是要扩展对象的功能,但是装饰模式可以提供比继承更多的灵活性。
2.通过使用不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为的组合。
3.有着比继承更加灵活的特性缺点:由于使用装饰模式,可以比使用继承关系需要较少数目的类。
使用较少的类,当然使设计比较易于进行。
但是,在另一方面,使用装饰模式会产生比使用继承关系更多的对象。
更多的对象会使得查错变得困难,特别是这些对象看上去都很相像。
用途:当需要给一个类添加新的行为的时候,但基于开闭原则,就使用装饰模式。
经典例子:我穿衣服使用draw()方法,在我穿好衣服后,我还打算再寄领带,而寄领带就是装饰类,我们可以把装饰类和对象(穿衣服类)继承于同一个接口,在装饰类的draw()方法中调用super.draw(),然后再在这个方法里加上自己的特征。
13代理模式优点:向客户端隐藏了访问某个对象的细节及复杂性;可以动态地调用一个对象中的方法,且无需实现固定的接口。
缺点:(个人见解切勿当真)总觉得代理者不够可靠,不能得到有效的保证,要是对象代理者在维护的时候,或者其他的做出了变动,对被代理的人来说可能带来损失。
使用场景:1.远程代理,可以隐藏一个对象存在于不同地址空间的事实2.虚拟代理,比如html页面刷新的图片,图片一张嘴下载后才能看就是通过虚拟代理来替代了真实的图片,此时代理存储了真实图片的路径和尺寸3.安全代理,用来控制真实对象的访问权限。
一般用于对象应该有不同的访问权限的时候4.智能指引,当调用真实的对象时,代理处理另外一些事。
经典例子:我玩wow,但又没有时间精力投入到里面,于是我请了个人来代练,代练的人和我都继承于玩家类。
而代练者是认识我的,当代练的人开始刷副本的时候,调用代练者.刷副本()方法,此时他在这个方法中实际调用的是我.刷副本()。
14工厂方法模式优点:1.良好的封装性,代码结构清晰。
一个对象创建是有条件约束的,如一个调用者需要一个具体的产品对象,只要知道这个产品的类名(或约束字符串)就可以了,不用知道创建对象的艰辛过程,减少模块间的耦合。
2.工厂方法模式的扩展性非常优秀。
在增加产品类的情况下,只要适当地修改具体的工厂类或扩展一个工厂类,就可以完成“拥抱变化”。
例如在我们的例子中,需要增加一个棕色人种,则只需要增加一个BrownHuman类,工厂类不用任何修改就可完成系统扩展。
3.屏蔽产品类。
这一特点非常重要,产品类的实现如何变化,调用者都不需要关心,它只需要关心产品的接口,只要接口保持不表,系统中的上层模块就不要发生变化,因为产品类的实例化工作是由工厂类负责,一个产品对象具体由哪一个产品生成是由工厂类决定的。
在数据库开发中,大家应该能够深刻体会到工厂方法模式的好处:如果使用JDBC连接数据库,数据库从MySql切换到Oracle,需要改动地方就是切换一下驱动名称(前提条件是SQL语句是标准语句),其他的都不需要修改,这是工厂方法模式灵活性的一个直接案例。
4.工厂方法模式是典型的解耦框架。
高层模块值需要知道产品的抽象类,其他的实现类都不用关心,符合迪米特原则,我不需要的就不要去交流;也符合依赖倒转原则,只依赖产品类的抽象;当然也符合里氏替换原则,使用产品子类替换产品父类,没问题!缺点:待补充用途:第一种情况是对于某个产品,调用者清楚地知道应该使用哪个具体工厂服务,实例化该具体工厂,生产出具体的产品来。
JavaCollection中的iterator()方法即属于这种情况。
第二种情况,只是需要一种产品,而不想知道也不需要知道究竟是哪个工厂为生产的,即最终选用哪个具体工厂的决定权在生产者一方,它们根据当前系统的情况来实例化一个具体的工厂返回给使用者,而这个决策过程这对于使用者来说是透明的。
典型例子:车子继承vehicle(车)类,有小汽车卡,公交车bus等,车子工厂实现工厂接口,工厂接口有抽象方法vehicleproducevehicle(Stringtype)方法,车子工厂中实现工厂方法vehicleproducevehicle (StringType),方法中根据需要new新的车子。