随笔分类 - 设计模式
摘要：笔者所发表的设计模式系列的随笔一共包含15篇，归纳总结了《Head First 设计模式》一书中的内容。在这些随笔中，尽量用简洁、概括的语言说明每个模式的概念、特点、用法，并配以图片（类图、流程图）给读者一种直观、具体的印象。看了这么多设计模式，我们再来回顾一下“模式”的概念，以及我们应该怎样来应用这些模式。模式：是在某情景（context）下，针对某问题的某种解决方案。……
阅读全文
摘要：复合模式 复合模式结合两个或以上的模式，组成一个解决方案，解决一再发生的一般性问题。MVCMVC是数个设计模式结合起来的模式MVC是复合模式，结合了观察者、策略模式和组合模式。1、模型使用观察者模式，以便观察者（对模型状态改变有兴趣的对象都可注册成为观察者）更新，同时保持两者之间解耦。 （模型不知道视图、控制器的存在）2、控制器是视图的策略，视图可以使用不同的控制器实现，得到不同的行为。3、视图使用组合模式。MVC与Webweb工作流程：②Servlet扮演控制器，处理请求，通常回向模型发出请求，处理结果往往以javaBean的形式打包。③④控制器将控制器交给视图，JSP从JavaBean..
阅读全文
摘要：代理模式 为另一个对象提供一个替身或占位符以控制对这个对象的访问。1、使用代理模式创建代表（representative）对象，让代表对象控制某个对象的访问，被代理的对象可以是远程的对象，创建开销大的对象或需要安全控制的对象。类图1、Subject：Proxy和RealSubject都实现此接口，客户可以像处理RealSubject一样处理Proxy对象。2、Proxy：持有Subject类型的引用（指向RealSubject）。Proxy会控制对RealSubject的访问。代理模式在结构上类似装饰者，但是目的不同，装饰者为对象加上行为，而代理则是控制访问。(一)远程代理（RMI过程）（二）
阅读全文
摘要：状态模式 允许对象在内部状态改变时，改变它的行为，对象看起来好像修改了它的类。 （因为不同的状态，对用一个操作，有不同的处理）1、将状态封装成独立的类，每个状态下的行为都放在各自状态的类中。2、状态机建模：定义一个状态集合；创建用一个变量持有当前状态对象；当动作被调用时，它就被委托给当前的状态对象。类图：1、Context（上下文）持有一些内部状态，只要有人调用Context的request() 方法，它就会被委托到状态来处理。2、State 接口定义了一个所有状态的共同接口，任何状态都实现这个接口，以便状态之间可以相互替换。3、每个ConcreteState都提供了它自己对于请求的实现。..
阅读全文
摘要：组合模式 允许你将对象组合成树形结构来表现“整体/部分”的层次结构。组合能让客户以一致的方式处理个别对象及对象组合。 换句话说，在大多数情况下，我们可以忽略 对象组合 和 个别对象 之间的差别。树形结构：类图1、Component（组件）为组合中的所有对象定义一个接口，不管是组合还是叶节点包含其他组件的组件 为组合对象没有包含其他组件的组件为 叶节点对象2、Composite（组合）具有子节点，内部含有一个容器3、Leaf（叶结点）中有些方法没有意义，可以抛出异常。不需要操心面对的是组合对象还是叶节点对象，只需对整体结构调用一个方法就可以。（转载请注明出处 ^.^）
阅读全文
摘要：迭代器模式 提供一种方法顺序的访问一个聚合对象中的各个元素，而又不暴露其内部的表示。 把在元素之间游走的责任交给迭代器，而不是聚合对象。类图：1、迭代器接口Iterator 定义了遍历集合的方法。2、具体迭代器ConcreteIterator 负责管理目前遍历的位置。3、具体聚合类ConcreteAggregate 持有一个对象的集合，负责实例化一个具体迭代器。设计原则：9、单一责任，一个类应该只有一个引起变化的原因当一个模块或一个类被设计成只支持一组相关功能，我们说它具有高内聚。（转载请注明出处 ^.^）
阅读全文
摘要：模板方法模式“封装算法” 在一个方法中定义了一个算法的骨架，而将一些步骤延迟到子类中。 模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。模板就是一个方法，将算法定义成一组步骤，其中的任何步骤都可以是抽象的，由子类负责实现。模板一般不是完整的，有部分实现在子类中类图：1、该抽象类中包含一个模板方法，模板方法在实现算法过程中，用到了下面两个原语操作（可以为具体的，也可以为抽象方法）2、可能有多个具体类，每个都实现了模板方法所需要的全部操作。3、当创建一个模板方法时，如果子类“必须”提供算法中某个方法的实现是，就使用抽象方法。4、如果算法的这个部分是可选的，就用钩子。对于..
阅读全文
摘要：外观模式 提供了一个统一的接口，用来访问子系统的一群接口。外观定义了一个高层接口，让子系统更容易使用。类图：设计原则：7、最少知识原则：只和你的密友谈话在设计中，不要让太多的类耦合在一起例如：public float getTemperature(){ return station.getThermometer().getTemperature()；//依赖了三个类}应该采用以下方案：public float getTemperature(){ return station.getTemperature()；//依赖了两个类，需要向station中添加getTemperature()方法...
阅读全文
摘要：适配器模式 将一个类的接口，转换成客户希望的另一个接口。适配器让原本接口不兼容的类可以合作无间。类图：（转载请注明出处 ^.^）
阅读全文
摘要：命令模式 将“请求”封装成对象，以便使用不同的请求、队列或日志来参数化其他对象。命令模式也支持撤销的操作。 encapsulates a request as an object, thereby letting you parameterize other objects with different request, queue or log requests, and support undoable operations.一个封装的请求：1、封装的请求：命令模式将动作和接收者包进对象中。2、从外面看，其他对象不知道哪个接收者进行了哪些动作，只知道调用了execute() 方法，请求..
阅读全文
摘要：单例模式 确保一个类只有一个实例，并提供一个全局访问点。往往用单个实例管理共享的资源，如数据库连接和线程池。经典的单例模式实现：public class Singleton{ private static Singleton uniqueInstance; //静态的变量来记录Singleton类的唯一实例 private Singleton(){} //私有构造器，只有类内部可以调用 public static Singleton getInstance(){//静态方法，返回实例 if( uniqueInstance==null ) uniqueInstan...
阅读全文
摘要：抽象工厂模式 提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。抽象工厂模式类图：1、Client : 客户的代码中只涉及抽象工厂，运行时使用具体的工厂实例。2、AbstrackFactory : 抽象工厂，定义了一组创建产品的方法。3、ConcreteFactory1ConcreteFactory2: 具体工厂生产不同的产品家族。4、AbstractProductAAbstractProductB ： 产品家族，每个具体工厂只能生产一组产品。工厂方法模式、抽象工厂模式对比共同： 1、都是用来封装对象的创建 2、通过减少应用程序和具体类之间的依赖，促进松耦合不同： 工...
阅读全文
摘要：工厂方法模式 定义了一个创建对象的接口，但是由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。使用new时，是针对实现编程，依赖具体类工厂方法模式将产品的“实现”从“使用”中解耦“工厂”封装实例化的行为设计原则6、要依赖抽象，不要依赖具体类工厂方法类图：1、PizzaStore类实现操纵产品的方法，但不实现工厂方法，由子类实现。public abstract class PizzaStore {abstract Pizza createPizza(String item);//工厂方法为抽象方法 public Pizza orderPizza(String type) { Pi.
阅读全文
摘要：装饰者模式： 动态的将责任附加到对象上。想要扩展功能，装饰者提供了有别于继承的另外一种选择。设计原则：5、对扩展开放，对修改关闭。示例类图：以《Head First Design Patterns》中的咖啡为例。有双摩卡、豆浆、奶泡的House Blend咖啡，价格计算：Java JDK中的装饰者模式:（转载请注明出处 ^.^）
阅读全文
摘要：观察者模式：在对象之间定义一对多的依赖。这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并自动更新。设计原则：4、为交互对象之间的松耦合设计而努力。示例类图：以《Head First Design Patterns》中气象站为例。1、所有依赖主题的观察者都应该实现Observer接口，这样主题状态信息发生改变，需要通知观察者时，就有了一个共同的接口。2、可以使用推（push）或拉（pull）的方式传送数据。通过update接口传入主题的引用；在Observer对象构造时，通过构造函数传入主题引用；把主题的信息以参数的形式直接通过update接口传入；（转载请注明出处 ^.^）
阅读全文
摘要：软件开发的一个不变真理是：change！库与框架无法帮助我们将应用组织成容易理解、容易维护、具有弹性的架构，所以需要设计模式策略模式 定义了算法族，分别封装起来（封装在一组类中，可以被轻易的扩充与改变），让它们之间可以相互替换。此模式让算法的改变独立于使用算法的客户。设计原则：1、“封装变化”。找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码放在一起。2、针对接口编程，而不是针对实现编程。3、对用组合，少用继承。（组合是运行时动态调用，可以在运行时动态改变行为，因为我们可以更换不同的实现。继承是编译时静态决定了的）组 合 、继 承 对比1、组合（优点）：不破坏封装，整体类
阅读全文