Java那点事 | 学习●思考●分享 | Java技术交流QQ群：83753349

Java总共有23中常见的设计模式。它们主要可以分为3类，创建型，结构型以及行为型。 创建型的设计模式有： 一、Singleton,单例模式：保证一个类只有一个实例，并提供一个唯一的全局访问点。 二、Abstract Factory，抽象工厂：提供一个创建一系列相关或者互相依赖的对象的接口，而无需指定它们的具体类。 三、Factory Method,工厂方法：定义一个用于创建对象的

1、动态代理（Dynamic Proxy）　　代理分为静态代理和动态代理，静态代理是在编译时就将接口、实现类、代理类一股脑儿全部手动完成，但如果我们需要很多的代理，每一个都这么手动的去创建实属浪费时间，而且会有大量的重复代码，此时我们就可以采用动态代理，动态代理可以在程序运行期间根据需要动态的创建代理类及其实例，来完成具体的功能。　　其实方法直接调用就可以完成功能，为什么还要加个代理呢？

1.代理模式代理(Proxy)是一种设计模式,提供了对目标对象另外的访问方式;即通过代理对象访问目标对象.这样做的好处是:可以在目标对象实现的基础上,增强额外的功能操作,即扩展目标对象的功能.这里使用到编程中的一个思想:不要随意去修改别人已经写好的代码或者方法,如果需改修改,可以通过代理的方式来扩展该方法举个例子来说明代理的作用:假设我们想邀请一位明星,那么并不是直接连接明星,

前言单例(Singleton)应该是开发者们最熟悉的设计模式了，并且好像也是最容易实现的——基本上每个开发者都能够随手写出——但是，真的是这样吗？作为一个Java开发者，也许你觉得自己对单例模式的了解已经足够多了。我并不想危言耸听说一定还有你不知道的——毕竟我自己的了解也的确有限，但究竟你自己了解的程度到底怎样呢？往下看，我们一起来聊聊看~        2. 什么是单例？

策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。假设有一个模拟鸭子的游戏，游戏中会出现各种鸭子，一边游泳戏水，一边呱呱叫。这个游戏的内部设计了一个鸭子超类Duck，并让各种鸭子继承此超类。public abstract class Duck { public void quack(){ // 所有的鸭子都会呱呱

观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。客户有一个WeatherData对象，负责追踪温度、湿度和气压等数据。现在客户给我们提了个需求，让我们利用WeatherData对象取得数据，并更新三个布告板：目前状况、气象统计和天气预报。WeatherData对象提供了4个接口：getTemperature()：获取温度

抽象工厂模式提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。确保原料的一致披萨店成功的关键在于新鲜、高质量的原料。要如何确保每家加盟店使用高质量的原料？你打算建造一家生成原料的工厂，并将原料运送到各家加盟店。对于这个做法，现在还剩下一个问题：加盟店坐落在不同的区域，纽约的红酱料和芝加哥的红酱料是不一样的。加盟店之间有相同的产品家族（意式腊肠、酱料、芝士、蔬菜等等

命令模式将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。一个家电公司想邀请你设计一个家电自动化遥控器的API。这个遥控器有7个可编程的插槽，每个都可以指定到一个不同的家电装置。每个插槽都有对应的“打开”和“关闭”按钮。这个遥控器还具备一个整体的撤销按钮。现在已经有一组Java类，这些类是多家产商开发出来的，用来控制家电自动化装置，

外观模式提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。我们已经知道适配器模式是如何将一个类的接口转换成另一个符合客户期望的接口的。现在我们要看一个改变接口的新模式，但是它改变接口的原因是为了简化接口。这个模式被巧妙地命名为外观模式，之所以这么称呼，是因为它将一个或数个类的复杂的一切都隐藏在背后，只显露出一个干净美好的外观。甜蜜的家庭影

模板方法模式在一个方法中定义了一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。有些人没有咖啡就活不下去；有些人则离不开茶。两者共同的成分是什么？当然是咖啡因了！但还不只这样。茶和咖啡的冲泡方式非常相似：星巴兹咖啡冲泡法把水煮沸用沸水冲泡咖啡把咖啡倒进杯子加糖和牛奶星巴兹茶冲泡法

装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。星巴兹是以扩张速度最快而闻名的咖啡连锁店。由于扩张速度太快，他们准备更新订单系统，以合乎他们的饮料供应要求。他们原先的类设计是这样的：// Beverage(饮料)是抽象的，店内所提供的饮料都必须继承自此类public abstract class Beverage { // 由每个子

工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到了子类。预定披萨假设你有一个披萨店，预定披萨的代码可能是这么写的：Pizza orderPizza(){ Pizza pizza = new Pizza(); // 准备面皮，加调料等 pizza.prepare(); // 烘烤 pizz

单件模式确保一个类只有一个实例，并提供一个全局访问点。有一些对象我们只需要一个，比方说：线程池、缓存、对话框、处理器偏好设置和注册表的对象等等。事实上，这类对象只能有一个实例，如果制造出多个实例，就会导致许多问题产生，例如：程序的行为异常、资源使用过量，或者是不一致的结果。使用静态变量如何确保这些类只存在一个实例？利用java的静态变量可以做到，但使用静态变量有个缺点：如果

适配器模式将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。我们周围的适配器如果你需要在欧洲国家使用美国制造的笔记本电脑，你可能需要使用一个交流电的适配器。你知道适配器的作用：它位于美式插头和欧式插座的中间，它的工作是将欧式插座转换成美式插座，好让美式插头可以插进这个插座得到电力。或者也可以这么认为：适配器改变了插座的接口，以符合美式笔记本电脑

原创不易，转载请注明出处：http://blog.youkuaiyun.com/anxpp/article/details/51224293，谢谢！    文章比较长，读者可以通过顶端的目录选择要了解的模式，然后通过文章右边的按钮快速返回顶部重新选择一个新的模式浏览    博主精心准备了大量的示例代码。文章尽量提供与编程相关的例子，而不是像多数其他介绍的文章一样，提供一些感觉挺滑稽的例子（那样的例子可能看完觉...