设计模式解析(1-6)

设计模式：常用设计模式及其应用设计模式是在软件设计中常见问题的解决方案的一种反复使用的经验总结。

它们是已经被证明有效的经典解决方案，可以帮助我们在开发过程中避免重复设计。

本文将介绍一些常用的设计模式及其应用。

1.单例模式单例模式是一个创建型的设计模式，它会确保一个类只有一个实例。

这在需要共享资源或控制唯一资源访问的场景下非常实用，例如线程池、日志记录器等。

2.工厂模式工厂模式是一种用于创建对象的创建型设计模式。

它定义了一个接口来创建对象，但将创建实例的过程延迟到子类中。

这样可以避免在代码中直接使用new操作符，增加了代码的灵活性和可维护性。

3.观察者模式观察者模式是一种行为型的设计模式，它定义了一对多的依赖关系。

当一个对象的状态发生变化时，它会自动通知它的依赖对象。

观察者模式常用于事件处理、GUI编程等场景。

4.装饰器模式装饰器模式是一种结构型的设计模式，它允许你通过将对象包装在一个装饰器对象中来动态地添加新的功能。

装饰器模式可以避免使用子类化的复杂性，提供了比继承更加灵活的方式来扩展功能。

5.策略模式策略模式是一种行为型的设计模式，它定义了一系列算法，并将每个算法封装在可以相互替换的策略对象中。

这使得算法可以独立于客户端的使用，提高了代码的灵活性。

6.适配器模式适配器模式是一种结构型的设计模式，它允许不兼容的接口之间进行适配。

适配器模式可以通过创建一个适配器类来实现两个不兼容接口之间的交互。

7. MVC模式MVC（Model-View-Controller）是一种架构模式，它将应用程序分为三个主要部分：模型、视图和控制器。

模型表示应用程序的数据和逻辑，视图负责显示数据，控制器接收用户输入并对模型和视图进行协调。

8.组合模式组合模式是一种结构型的设计模式，它将对象组合成树状结构以表示“整体/部分”层次结构。

组合模式使得用户对单个对象和组合对象的使用具有一致性，可以用来处理树形结构的问题。

9.迭代器模式迭代器模式是一种行为型的设计模式，它提供一种访问容器中各个元素的方法，而不需要暴露容器的内部结构。

设计模式（1、创造型2、结构型、3⾏为型）
设计模式六⼤原则：单⼀职责、⾥⽒替换、依赖倒置、最⼩接⼝、迪⽶特、开闭
这些只能叫原则,叫建议,没有实际的招数
23种设计模式，就是具体的招数，他们可以分成三⼤类。

1、创造型2、结构型、3⾏为型。

创造型设计模式关注对象的创建。

就是咱们的new().单例模式、原型模式、⼯⼚⽅法、抽象⼯⼚、建造者模式
结构型设计模式关注类与类之间的关系。

继承或者组合。

说⽩了就是包⼀层。

适配器模式、代理模式、装饰器模式、外观模式、组合模式、桥接模式、享元模式
⾏为型设计模式关注对象和⾏为的分离。

流程⽤的多些，说⽩了就是把逻辑丢出去，具体逻辑上端⾃⼰实现，下端只做流程。

模板⽅法设计模式、观察者模式、责任链模式
23种设计模式是前辈们总结出来的。

是为了解决具体的⼀类问题总结出来的，我遇到好多⼩伙伴觉得设计模式很⽜逼。

其实没那么伟⼤。

某种设计模式解决⼀类问题也会带来另⼀种问题。

所以合理应⽤才是最好的。

所以，有些设计模式不是必须应⽤进去。

不必强求。

我也是后来者，对前辈们总结的⼀些理解，学习和应⽤。

希望也能帮到看到这⾥的求学者。

下⾯⼏章。

都是对这23种设计模式的解读，不过我是总结成三⼤类。

尽量⽤最普通的话去阐述。

详解23种设计模式设计模式（Design Patterns） ⾸先说⼀下我对设计模式的理解，设计模式是⼀种在软件内部优化代码的技巧。

注意，是代码的内部，也就是在⼀个局部范围内优化设计。

这⼀点和软件的架构是完全不同的，软件架构是全局的优化，讲的是怎么对软件进⾏切分以及对切开之后的内容进⾏重组的⼀个过程。

软件的设计模式强调的是代码，软件架构强调的是结构。

在⾯向对象的编程思想中，这就体现在怎么解决类与类之间的关系。

能处理好类与类之间的关系，优化设计就搞好了。

下⾯这段话是软件设计模式的定义： 设计模式（Design pattern）是⼀套被反复使⽤、多数⼈知晓的、经过分类编⽬的、代码设计经验的总结。

使⽤设计模式是为了可重⽤代码、让代码更容易被他⼈理解、保证代码可靠性。

毫⽆疑问，设计模式于⼰于他⼈于系统都是多赢的，设计模式使代码编制真正⼯程化，设计模式是软件⼯程的基⽯，如同⼤厦的⼀块块砖⽯⼀样。

项⽬中合理的运⽤设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每⼀个模式描述了⼀个在我们周围不断重复发⽣的问题，以及该问题的核⼼解决⽅案，这也是它能被⼴泛应⽤的原因。

设计模式是⼀代⼜⼀代的编程⼤师总结出来的，我们应该重视，不能束之⾼阁，应当合理利⽤。

关键是要搞清楚哪种情况⽤哪种设计模式。

⼀、设计模式的分类总体来说设计模式分为三⼤类：创建型模式，共五种：⼯⼚⽅法模式、抽象⼯⼚模式、单例模式、建造者模式、原型模式。

（还有⼀种叫简单⼯⼚模式，是⼯⼚模式的变形，不满⾜单⼀职责，设计不太合理，所以就没列出来）结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

⾏为型模式，共⼗⼀种：策略模式、模板⽅法模式、观察者模式、迭代⼦模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

⼆、设计模式的七⼤原则设计模式的七⼤原则堪称经典，这七条原则是我们在设计软件的过程中必须准守的，当然不遵守的话，你的⽼板可能就会“嘿嘿”你，你懂得！这七条原则指导了23种设计模式，可以这么说，23种设计模式就是在这七条原则在不同场景之下的应⽤。

设计模式分类（创建型模式、结构型模式、⾏为型模式）1．创建型模式前⾯讲过，社会化的分⼯越来越细，⾃然在软件设计⽅⾯也是如此，因此对象的创建和对象的使⽤分开也就成为了必然趋势。

因为对象的创建会消耗掉系统的很多资源，所以单独对对象的创建进⾏研究，从⽽能够⾼效地创建对象就是创建型模式要探讨的问题。

这⾥有6个具体的创建型模式可供研究，它们分别是：简单⼯⼚模式（Simple Factory）⼯⼚⽅法模式（Factory Method）抽象⼯⼚模式（Abstract Factory）创建者模式（Builder）原型模式（Prototype）单例模式（Singleton）说明：严格来说，简单⼯⼚模式不是GoF总结出来的23种设计模式之⼀。

2．结构型模式在解决了对象的创建问题之后，对象的组成以及对象之间的依赖关系就成了开发⼈员关注的焦点，因为如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。

对象结构的设计很容易体现出设计⼈员⽔平的⾼低，这⾥有7个具体的结构型模式可供研究，它们分别是：外观模式/门⾯模式（Facade门⾯模式）适配器模式（Adapter）代理模式（Proxy）装饰模式（Decorator）桥梁模式/桥接模式（Bridge）组合模式（Composite）享元模式（Flyweight）3．⾏为型模式在对象的结构和对象的创建问题都解决了之后，就剩下对象的⾏为问题了，如果对象的⾏为设计的好，那么对象的⾏为就会更清晰，它们之间的协作效率就会提⾼，这⾥有11个具体的⾏为型模式可供研究，它们分别是：模板⽅法模式（Template Method）观察者模式（Observer）状态模式（State）策略模式（Strategy）职责链模式（Chain of Responsibility）命令模式（Command）访问者模式（Visitor）调停者模式（Mediator）备忘录模式（Memento）迭代器模式（Iterator）解释器模式（Interpreter）。

安卓常⽤的6种设计模式总结最近看到两篇博客，觉得很不错，记录⼀下由于项⽬变更的频繁性，作为⼀名程序员，我们需要掌握设计模式的必要性，就不⾔⽽喻~~，下⾯就是⼀些我⾃⼰学习的设计模式总结。

接下来，主要是针对⼏个⽐较常⽤模式进⾏讲解，主要是以下⼏种：观察者模式适配器模式代理模式⼯⼚模式单例模式命令模式1.观察者模式（Observer Pattern）释义：观察者模式定义了⼀种⼀对多的依赖关系，让多个观察者对象同时监听某⼀个主题对象，这个主题对象在状态上发⽣变化时，会通知所有观察者对象，使他们能够⾃动更新⾃⼰。

故事理解：观察者想知道公司所有MM的情况，只要加⼊公司的MM情报邮件组就⾏了，tom负责搜集情报，当发现新情报时，不⽤⼀个⼀个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦。

常见实例：1.BaseAdapter.registerDataSetObserver和BaseAdapter.unregisterDataSetObserver两⽅法来向BaseAdater注册、注销⼀个DataSetObserver ; 2.使⽤ContentObserver去监听数据库变化。

适⽤场景：1.当对⼀个对象的改变需要同时改变其他对象，⽽不知道具体有多少对象有待改变；2.当⼀个对象必须通知其它对象，⽽它⼜不能假定其它对象是谁.观察者模式主要有观察者和被观察者2个对象，在该模式中，Observable表⽰被观察者，这个对象是⼀个抽象类，只能被继承。

Observer表⽰观察者，他是⼀个接⼝，所以观察者可以有多个，实现了该接⼝的类都是属于观察者。

这是⽹上⼀个⽣动细致的demo：被观察者：public class MyPerson extends Observable {private int age;private String name;private String sax;public int getAge() {return age;}public void setAge(int age) {this.age = age;setChanged();notifyObservers();}public String getName() {return name;}public void setName(String name) { = name;setChanged();notifyObservers();}public String getSax() {return sax;}public void setSax(String sax) {this.sax = sax;}@Overridepublic String toString() {return "MyPerson [age=" + age + ", name=" + name + ", sax=" + sax + "]";}}MyPerson是被观察者，类中调⽤了setChange()以及notifyObservers()两个⽅法，前者是告知数据改变，后者是发送信号通知观察者。

如何理解这6种常见设计模式？简介：设计模式能够帮助我们优化代码结构，让代码更优雅灵活。

有哪些常见的设计模式？如何合理运⽤？本⽂分享作者对⼯⼚模式、单例模式、装饰模式、策略模式、代理模式和观察者模式的理解，介绍每种模式的模式结构、优缺点、适⽤场景、注意实现及代码实现。

⼀前⾔最近在改造⼀些历史的代码，发现⼀个很明显的特点，⼤部分代码是记叙⽂，按照事件的发展过程将故事平铺直叙的讲解出来。

这种⽅式的好处是⽐较符合⼈类的思维习惯，⼀条主线讲到底，代码阅读起来没有太⼤难度，只要顺着藤就能摸到⽠，但是缺点也很明显，⼀旦故事线中需要插⼊⼀些新的元素，⽐如：加⼊⼀个新的⼈物⾓⾊、新的时间线，都会需要⼤量更改故事线以配合这个新元素的融⼊，甚⾄对原有⽂章造成破坏性的影响。

为了解决这个问题，⼈们总结出了很多种⽂章结构，例如：总-分结构，并列结构，总-分-总结构等等，有了这些结构，在加⼊新元素的时候，甚⾄不必考虑新元素与原故事情节的关联性，直接单拉⼀个分⽀故事线独⽴去讲就好了，只要能够在整体故事结束前，与汇聚到主线故事就可以了（是不是很像git？）。

在软件开发领域，也有很多这样的⾮常有⽤的实践总结，我们称之为设计模式。

对于设计模式，⼤家都不陌⽣，随便找个⼈，估计都能讲出N个设计模式来，但是除了这些设计模式的概念，很多⼈不知道如何灵活运⽤这些设计模式。

所以借这篇⽂章和⼤家共同学习设计模式的思想。

⼆理解设计模式我尽量⽤最通俗易懂的⽰例和语⾔来讲述我理解的设计模式，希望能对⼤家有所帮助。

另外也⽆需精通所有的设计模式，只要能够融汇贯通常见的设计模式，就能让你的代码变得优雅。

就像程咬⾦只会三板斧，但是熟练度⽆⼈能及，照样能横⾏天下。

1 ⼯⼚模式(Factory)简单⼯⼚(Simple Factory)⼩明追妹⼦的时候，请她喝了不少咖啡，她爱喝卡布奇诺，每次去咖啡店，只要跟服务员说“来杯卡布奇诺”就⾏了，⼩明追妹⼦的时候，请她喝了不少咖啡，她爱喝卡布奇诺，每次去咖啡店，只要跟服务员说“来杯卡布奇诺”就⾏了，虽然各家的⼝味有些不同，但是不管是星爸爸还是Costa，都能够提供卡布奇诺这种咖啡。

二十三种模式图解1. 创建型模式1.1 ABSTRACT FACTORY（抽象工厂）提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们的类。

在以下情况下可以使用Abstract Factory 模式：一个系统要独立于它的产品的创建、组合和表示时；一个系统要由多个产品系列中的一个来配置时；当你要强调一系列相关的产品对象的设计以便进行联合使用时；当你提供一个产品类库，而只是显示它们的接口而不是实现时。

1.2 BUILDER (生成器)将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

Builder模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。

它可以强制实行一种分步骤进行的建造过程。

以下情况适用于Builder模式：当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时；当构造过程必须允许被构造的对象有不同的表示时。

1.3 FACTORY METHOD (工厂方法)定义一个用于创建对象的接口，让子类决定实例化哪一个类。

Factory Method使一个类的实例化延迟到其子类。

核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

下列情况下可以使用Factory Method模式：当一个类不知道他所必需创建的对象的类别的时候；当一个类希望由他的子类来指定它所创建的对象的时候；当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。

1.4 PROTOTYPE (原型)用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

原型模式允许动态的增加或减少产品种类，产品类不需要非得有任何事先确定的等级结构，其适合于任何的等级结构。

缺点是每一个类必须配备一个克隆方法。

Prototype模式用于以下的情况：当要实例化的类在运行时刻制定时，例如动态装载；为了避免创建一个与产品层次平行的工厂类层次时；当一个类的实例只能有几个不同状态组合中的一种时。

设计模式六⼤规则1.单⼀职责原则（六⼤规则中的⼩萝莉，⼈见⼈爱）：描述的意思是每个类都只负责单⼀的功能，切不可太多，并且⼀个类应当尽量的把⼀个功能做到极致。

2.⾥⽒替换原则（六⼤原则中最⽂静的姑娘，但却不太招⼈喜欢）：这个原则表达的意思是⼀个⼦类应该可以替换掉⽗类并且可以正常⼯作。

3. 接⼝隔离原则（六⼤原则当中最挑三拣四的挑剔⼥，胸部极⼩）：也称接⼝最⼩化原则，强调的是⼀个接⼝拥有的⾏为应该尽可能的⼩。

4.依赖倒置原则（六⼤原则中最⼩鸟依⼈的姑娘，对抽象的东西⾮常依赖）：这个原则描述的是⾼层模块不该依赖于低层模块，⼆者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。

5.迪⽶特原则（六⼤原则中最害羞的姑娘，不太爱和陌⽣⼈说话）：也称最⼩知道原则，即⼀个类应该尽量不要知道其他类太多的东西，不要和陌⽣的类有太多接触。

6.开-闭原则（六⼤原则中绝对的⼤姐⼤，另外五姐妹⼼⽢情愿⾂服）：最后⼀个原则，⼀句话，对修改关闭，对扩展开放。

《简介》说到设计模式，当初第⼀次听到时，第⼀反应就是很深奥，完全理解不了这个概念到底是什么意思，下⾯我先从⽹上摘录⼀份定义。

设计模式（Designpattern）是⼀套被反复使⽤、多数⼈知晓的、经过分类编⽬的、代码设计经验的总结。

上⾯是百度当中的解释，来解释⼀下这句简单的话的含义，⼏个关键词。

反复使⽤：这个不⽤过多解释，设计模式被使⽤太多了，上个系列spring源码当中就出现了很多模式，记忆中⽐较深刻的有模板模式，代理模式，单例模式，⼯⼚模式等等。

多数⼈知晓：这个就不需要过多解释了。

分类编⽬：就是说可以找到⼀些特征去划分这些设计模式，从⽽进⾏分类。

代码设计经验：这句很重要，设计经验的总结，也就是说设计模式，是为了指导设计⽽从经验中总结出来的套路。

还有⼀种说法是说，设计模式是可以解决特定场景的问题的⼀系列⽅法，其实我觉得这个解释更贴切⼀点。

《为何学习设计模式》上⾯简单的介绍，是让各位⾸先搞清楚设计模式是什么，下⾯我们来说说为什么要学习设计模式，学习总要有个驱动⼒。

编程中的设计模式：8个常见模式解析设计模式是软件开发中常见的一种解决问题的思想模式，它是一种经过多次实践总结出来的在特定情境下，对特定问题的解决方案。

设计模式通过将经典的经验进行抽象，然后形成模式来指导软件开发工程师进行设计和开发。

下面将介绍8个常见的设计模式。

1.工厂模式（Factory Pattern）工厂模式是一种创建型模式，用于创建对象的过程中隐藏了具体的实现细节，只暴露了一个工厂类的接口。

工厂模式可以根据不同的参数或条件，动态地返回不同的具体对象，达到解耦的效果，提高了代码的灵活性和可维护性。

2.单例模式（Singleton Pattern）单例模式是一种创建型模式，保证一个类只有一个实例，并提供全局访问点，同时对外部隐藏了具体的创建过程。

单例模式可以用于实现全局资源的管理，例如线程池、数据库连接等，避免了资源的创建和销毁过程中的开销问题。

3.观察者模式（Observer Pattern）观察者模式是一种行为型模式，定义了一种一对多的依赖关系，使得当一个对象的状态发生变化时，其相关依赖对象都能够得到通知和更新。

观察者模式可以实现松耦合的通信方式，增加了对象之间的交互性，提高了系统的可扩展性和可维护性。

4.策略模式（Strategy Pattern）策略模式是一种行为型模式，定义了一系列算法或行为，将它们封装起来并可以相互替换。

策略模式使得算法的变化不会影响到调用算法的客户端，提高了代码的可复用性和可维护性。

5.装饰器模式（Decorator Pattern）装饰器模式是一种结构型模式，可以动态地给一个对象添加一些额外的职责，而无需对原始对象进行修改。

装饰器模式通过组合的方式，将一系列装饰器对象包裹在被装饰对象的外部，从而在运行时动态地扩展对象的功能。

6.适配器模式（Adapter Pattern）适配器模式是一种结构型模式，用于将一个类的接口转换成客户端所期望的接口。

适配器模式中，适配器类是作为两个不兼容的接口之间的桥梁，将一个类的接口转换成另一个接口，从而可以让它们能够正常地协同工作。