摘要：设计模式之间的关系： 设计模式总概况：一、设计原则1、单一职责原则 一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。from：百度百科2、开闭原则（Open Close Principle） 开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我 阅读全文

摘要：一、开篇 上一篇我们讲述了结构型模式中的代理模式。本篇，我们将会开始讲述行为型模式中的命令模式，在设计模式的这些基本的模式完成后，我将会将一些经常用的其他的一些扩展的模式进行讲解，希望能够引起大家的共鸣。 我们先来看看命令模式的定义吧： 命令模式是将一类对象的功能操作进行抽象，一般来说，这些对象有相同的方法，所以这类对象有着类似的操作，我们通过抽象，就可以定义出一个命令对象，通过这样的方式，用户程序在使用的时候，只与该命令对象打交道，而不用与一类对象打交道，降低了耦合性，提高了程序设计的灵活性。 命令模式适应于一组对象他们的操作形式非常的类似，这个时候我们可以把对象的行为进行抽象，抽象成命令对 阅读全文

摘要：一、上篇回顾 很久没有更新设计模式系列的文章了，有了很多热心朋友的反馈，我决定继续将这个系列赶快写完，最近由于过年了，有很多相关的事宜要做，所以没有时间来写，也是对大家的说下抱歉，感觉写文章的时间越来越少了，不过我会努力，尽快将这个系列写完，与大家共勉，希望大家有什么意见或建议，都可以帮我提出来，我好改进，谢谢！。 本文主要是讲述设计模式中的结构性模式中的最后一个本系列讲述的模式，也是经常用到的模式，代理模式，由于目前我们在很多的技术中都会用到这个代理模式，所以对我们来说，代理模式是必须掌握的模式之一。我们先来看看代理的思路及原理： 通过上面的图片，我们可以看到，通过增加代理来解耦A与C之间的 阅读全文

摘要：一、上篇回顾 通过上篇的简单描述，我们知道了桥接模式主要是为了解决，一个对象的多个维度的变化因素的变化太快，难以控制的问题，我们通过将每个维度的变化因素进行抽象， 然后我们的对象只要依赖于抽象即可，具体的实现调用我们不关心，通过对象组合的方式，我们就能组合出我们想要的对象。无疑这是一种非常灵活的也是满足设计模式的原则的，抽象和实现分离，使他们各自发生变化都不受对方的影响。而且我们也讲述了，使用桥接模式的几个典型的场景，现在我们的实际项目中就有这样的问题，我也是在项目的使用过程中加深对桥接模式的理解的，桥接模式为系统在多个维度的变化的适应性方面提供了很好的参考，特别适合底层框架的开发过程中使用， 阅读全文

摘要：一、上篇回顾 通过上篇的讲述，我们知道装饰模式，特别适合对某个类型的对象，动态的增加新的职责，应用程序就像使用原来的对象一样使用对象新增的装饰后的功能，装 饰模式就好像是穿了一层层的外壳，这样的方式避免了通过继承来为类型添加新的职责的形式可取，通过继承的方式容易造成子类的膨胀，但是当装饰类太多的时 候，也是个难以维护的问题，至少是在装饰对象的时候，我们可能需要多步操作来完成对象的装饰，这时候我们可以同上面提出的改进的方案，来完成自动配置装饰 模式，记录操作模式的状态，可以进行有效的回滚操作，以完成撤销操作。 我们先来回顾下装饰模式的使用场景： 1、当我们需要为某个现有的对象，动态的增加一个新的 阅读全文

摘要：一、上篇回顾 上篇我们讲述了比较常用的适配器模式，并且分析了适配器的一般使用场景： 1、我们在使用第三方的类库，或者说第三方的API的时候，我们通过适配器转换来满足现有系统的使用需求。 2、我们的旧系统与新系统进行集成的时候，我们发现旧系统的数据无法满足新系统的需求，那么这个时候，我们可能需要适配器，完成调用需求。 3、我们在使用不同数据库之间进行数据同步。(我这里只是分析的是通过程序来说实现的时候的情况。还有其他的很多种方式[数据库同步])。 并且讲述了对象适配器和类适配器的区别： 对象适配器：不是通过继承的方式，而是通过对象组合的方式来进行处理的，我们只要学过OO的设计原则的都知道，组合相 阅读全文

摘要：一、上篇回顾 通过上篇的简单讲解，我们知道了，组合模式意图是通过整体与局部之间的关系，通过树形结构的形式进行组织复杂对象，屏蔽对象内部的细节，对外展现统一的方式来操作对象，是我们处理更复杂对象的一个手段和方式。本文以查询控件为例，说明了，查询控件内部的组成元素，及如何操作内部的组成元素，包括添加元素，删除和处理相应事件的Handler，当然组合模式的作用远比这些强大，后面我们肯定会在一些实例代码中运用到组合模式的。组合模式如果在条件允许的情况下，我们尽量使用组合模式来处理复杂对象，远比通过继承出来的对象来的有效。 组合模式-强调的是如何组织整体和局部之间的结构，将整体和局部之间的关系，通过树形 阅读全文

摘要：一、上篇回顾上篇我们主要讲述了创建型模式中的最后一个模式-原型模式，我们主要讲述了原型模式的几类实现方案，和原型模式的应用的场景和特点，原型模式适合在哪些场景下使用呢？我们先来回顾一下我们上篇讲述的3个常用的场景。 1、我们在运行态的时候，动态的创建一个动态类型的对象的时候，可能我们使用原型模式，可以动态的创建指定类型的副本，这无疑是好的选择，否则如果通过我们前面讲述的几个创建型模式来实现的话，效率和代价上是非常大的。 2、有的时候我们需要对比一个对象在处理前和处理后进行对象状态的对比，对比是否处理后对象的状态是否发生变化，或者是其他的要求。这个时候通过原型模式来克隆对象的副本，远比通过引入其 阅读全文

摘要：一、上篇回顾 我们上篇主要讲述了结构型模式中的外观模式，外观模式作为结构型模式中的一个简单又实用的模式，外观模式通过封装细节来提供大粒度的调用，直接的好处就是，封装细节，提供了应用写程序的可维护性和易用性。外观模式一般应用在系统架构的服务层中，当我们是多个不同类型的客户端应用程序时，比如一个系统既可以在通过Web的形式访问，也可以通过客户端应用程序的形式时，可能通过外观模式来提供远程服务，让应用程序进行远程调用，这样通过外观形式提供服务，那么不管是什么样的客户端都访问一致的外观服务，那么以后就算是我们的应用服务发生变化，那么我们不需要修改没一个客户端应用的调用，只需要修改相应的外观应用即可。我 阅读全文

摘要：一、上篇回顾 上篇创建者模式中，我们主要讲述了创建者的几类实现方案，和创建者模式的应用的场景和特点，创建者模式适合创建复杂的对象，并且这些对象的每个组成部分的详细创建步骤可以是动态的变化的，但是每个对象的组装的过程来说可能是相对固定的或者说是对象的创建的过程是固定的，那么通过创建者模式可以很好的解决这类复杂对象的创建，而在我们的生活中或者是项目中可能会有这个方面的需求，那么使用创建者模式无疑是好的选择。 创建者模式中的每个对象组成部分的构建都是对象本身提供的内部方法，具体的创建者只是调用要创建的对象的内部的相应组成部分的构建方法，组织这些对象内部构建方法的执行顺序，完成对象的完整构建。当我们的 阅读全文

摘要：一、上篇回顾 上篇我们主要讲述了抽象工厂模式和工厂模式。并且分析了该模式的应用场景和一些优缺点，并且给出了一些实现的思路和方案,我们现在来回顾一下： 抽象工厂模式：一个工厂负责所有类型对象的创建，支持无缝的新增新的类型对象的创建。这种情况是通过配置文件来实现的，通过字典映射的方式来实现，不过可能效率上有点低下，可以通过优化的方式来做，上篇中我们也给出了委托的工厂实现形式，相比之前的简单工厂模式和工厂模式有了更好的灵活性，并且对具有依赖关系或者组合关系的对象的创建尤为适合。 上篇中，有不少的朋友提出了一些意见和建议，首先很感谢大伙的支持和鼓励，有朋友提出来，我画的图不够专业，专业人士应该用UML 阅读全文

摘要：一、上篇回顾 上篇我们主要讲述了简单工厂模式和工厂模式。并且分析了每种模式的应用场景和一些优缺点，我们现在来回顾一下： 简单工厂模式：一个工厂负责所有类型对象的创建，不支持无缝的新增新的类型对象的创建。 工厂模式：多个工厂负责多个类型对象的创建，每个工厂只负责具体类型对象的创建，支持无缝的新增类型对象的创建，需要实现工厂接口类和具体的类型对象类。 我们来简单的对比下这2个模式的优缺点：模式名称优点缺点简单工厂模式一个工厂负责所有对象的创建，简单灵活不符合高内聚的原则，不支持无缝的扩展工厂模式可以无缝的新增类型，每个工厂职责单一，符合高内聚的原则工厂类太多，难以维护。 工厂模式，很优雅的解决了应 阅读全文

摘要：一、开篇 一个多月没有写文章了，一方面是由于家庭的原因，还有一方面是因为工作上的原因，所以在这里给大家说抱歉了，这段时间也是有很多热心的朋友，一直询问我，什么时候能把相关的系列文章写完，其实我也特别的想赶快的把相关的文章书写完毕，不过现在真的是有时候力不从心，家庭和工作上的事情需要都处理好，所以属于个人思考的时间可能就会相对的少一些了，不过我会继续努力，出时间来把下面的这几个系列写完： 1、系统架构技能之设计模式-系列索引 2、系统架构师-基础到企业应用架构-系列索引 3、Step by Step-构建自己的ORM系列 当然可能在我写的过程中又会产生新的想法或者思路，我会提出来，并且给出相应的 阅读全文

摘要：一、开篇 其实我本来不是打算把系统架构中的一些设计模式单独抽出来讲解的，因为很多的好朋友也比较关注这方面的内容，所以我想通过我理解及平时项目中应用到的一些常见的设计模式,拿出来给大家做个简单讲解，我这里只是抛砖引玉，如果某个地方讲解的不正确或者不详细，请大家批评指出。园子里面的很多的大牛写的设计模式都非常的经典，我这里写可能有点班门弄斧的感觉，不过我还是决定把它写出来，希望能对初学者有一定的帮助和指导的作用。当然我这里如果说某个地方解释的有问题或者说是某个地方写的不符合逻辑之处，还请大家多多指出，提出宝贵意见。 软件工程中其实有很多总结性的话语，比如说软件=算法+数据结构等等这样的描述，当然我 阅读全文