设计模式

本博客大部分内容来于免费在线学习设计模式 1：代理模式(Proxy)代理模式是一种结构型设计模式，让你能够提供对象的替代品或其占位符。代理控制着对于目标对象的访问，并允许在将请求提交给对象前后进行一些处理。 2：代理模式问题为什么要控制对于某个对象的访问呢？举个例子：有这样一个消耗大量系统资源的巨型对象，你只是偶尔需要使用它，并非总是需要。 或者给对象添加功能：在理想情况下，我们希望将代码直接放入对象的类中进行修改，但这并非总是能实现：比如类可能是第三方封闭库的一部分。所以我们也需要代理对象来添加功能 3：代理模式解决方案代理模式建议新建一个与原目标对象接口相同的代理类，然后更新应用以将代理对象传递给所有原始对象客户端。代理类接收到客户端请求后会创建实际的目标对象，并将所有工作委派给它。 这有什么好处呢？ 如果需要在类的主要业务逻辑前后执行一些工作，你无需修改类就能完成这项工作。 由于代理实现的接口与原类相同，因此你可将其传递给任何一个使用实际服务对象的客户端。 例： 信用卡是银行账户的代理，银行账户则是一大捆现金的代理。它们都实现了同样的接口，均可用于进行支付。你通过信用 ...

本博客大部分内容来于免费在线学习设计模式 1：享元模式享元模式是一种结构型设计模式， 它摒弃了在每个对象中保存所有数据的方式， 通过共享多个对象所共有的相同状态， 让你能在有限的内存容量中载入更多对象。 2：享元模式问题在面向对象程序设计过程中，有时会面临要创建大量相同或相似对象实例的问题。创建那么多的对象将会耗费很多的系统资源，它是系统性能提高的一个瓶颈。例如，围棋和五子棋中的黑白棋子，图像中的坐标点或颜色，局域网中的路由器、交换机和集线器，教室里的桌子和凳子等。这些对象有很多相似的地方，如果能把它们相同的部分提取出来共享，则能节省大量的系统资源，这就是享元模式的产生背景。 3：享元模式解决方案在黑白棋子，坐标点这些类中，你会发现一些成员变量储存的值是相同的，而每个粒子的另一些状态（坐标，颜色等）是不同的。 对象的常量数据通常被称为内在状态（即不会随着环境的改变而改变的可共享部分）， 其位于对象中，其他对象只能读取但不能修改其数值。而对象的其他状态常常能被其他对象 “从外部” 改变，因此被称为外在状态（随环境改变而改变的不可以共享的部分）。 享元模式建议不在对象中存储外在状态，而 ...

本博客大部分内容来于免费在线学习设计模式 1：组合模式组合模式是一种结构型设计模式，又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象，你可以使用它将对象组合成树状结构，并且能像使用独立对象一样使用它们。 2：组合模式问题如果应用的核心模型能用树状结构表示，在应用中使用组合模式才有价值。 例如，你有两类对象：产品和盒子。一个盒子中可以包含多个产品或者几个较小的盒子。这些小盒子中同样可以包含一些产品或更小的盒子，以此类推。 在这些类的基础上你需要开发一个订单系统。订单中可以包含无包装的简单产品，也可以包含装满产品的盒子……以及其他盒子。如何计算订单的总价呢？ 在现实生活中，可以直接拆开盒子，直接计算每个产品的价格。而在程序中，你必须知道所有产品和盒子的细节，知道盒子的嵌套层数以及其他详细信息，才能计算出总价。因此直接计算是不可行。 在现实生活中，存在很多“部分-整体”的关系，例如，大学中的部门与学院、总公司中的部门与分公司、学习用品中的书与书包、生活用品中的衣服与衣柜以及厨房中的锅碗瓢盆等。在软件开发中也是这样，例如，文件系统中的文件与文件夹、窗体程序中的简单控件与容器控件 ...

本博客大部分内容来于免费在线学习设计模式 1：装饰模式装饰模式是一种结构型设计模式，允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。即在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）。 2：装饰模式问题假设你正在开发一个提供通知功能的库，其他程序可使用它向用户发送关于重要事件的通知。 库的最初版本基于通知器(Notifier)类，其中只有很少的几个成员变量，一个构造函数和一个send发送方法。该方法可以接收来自客户端的消息参数，并将该消息发送给一系列的邮箱，邮箱列表则是通过构造函数传递给通知器的。作为客户端的第三方程序仅会创建和配置通知器对象一次，然后在有重要事件发生时对其进行调用。 在不断发展后，有些用户希望使用微信通知，使用QQ通知，又或者使用短信通知。最简单的方法是： 扩展通知器类，然后在新的子类中加入额外的通知方法。现在客户端要对所需通知形式的对应类进行初始化，然后使用该类发送后续所有的通知消息。 但如果用户希望组合不同的方式，如果创建特殊子类来整合的话，代码量会迅速膨胀。而且不仅是程序库，客户端也是如此。 3：装饰模式解决方 ...

本博客大部分内容来于免费在线学习设计模式 1：适配器模式适配器模式是一种结构型设计模式，它能使接口不兼容的对象能够相互合作。它结合了两个独立接口的功能。 这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。 2：适配器模式问题例如你开发了一个程序，能从不同来源获取xml格式信息。在开发过程中，你决定整合一个第三方分析库，但是第三方分析库只兼容json格式。也许你可以修改第三方库来支持json，但是这需要修改很多代码，甚至你可能无法修改第三方库。 该如何导出数据呢？ 3：适配器模式解决方案适配器是一个特殊的对象，能够转换对象接口，使其能与其他对象进行交互。 适配器模式通过封装对象将复杂的转换过程隐藏于幕后。被封装的对象甚至察觉不到适配器的存在。 适配器不仅可以转换不同格式的数据，其还有助于采用不同接口的对象之间的合作。它的运作方式如下： 适配器实现与其中一个现有对象兼容的接口。 现有对象可以使用该接口安全地调用适配器方法。 适配器方法被调用后将以另一个对象兼容的格式和顺序将请求传递给该对象。 有时候你还可以写一个双向适配器来实现双向转换调用 例：出国旅行时，不同国家 ...

本博客大部分内容来于免费在线学习设计模式 1：外观模式外观模式是一种结构型设计模式， 能为程序库、 框架或其他复杂类提供一个简单的接口。 2：外观模式问题在现实生活中，常常存在办事较复杂的例子，例如申请一些东西，有时要同多个部门联系，这时要是有一个综合部门能解决一切手续问题就好了。 在程序设计中，当一个系统的功能越来越强，子系统会越来越多，客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变，客户端也要跟着改变，这违背了“开闭原则”，也违背了“迪米特法则”，所以有必要为多个子系统提供一个统一的接口，从而降低系统的耦合度，这就是外观模式的目标。 3：外观模式解决方案外观类为包含许多活动部件的复杂子系统提供一个简单的接口。 与直接调用子系统相比， 外观提供的功能可能比较有限， 但它却包含了客户端真正关心的功能。 例如：在淘宝下单后，商店包装，快递揽收，送达，这是一系列复杂的流程，但是你只需要下单就完成了这一系列流程的调用。 4：外观模式结构 外观 （Facade） 提供了一种访问特定子系统功能的便捷方式， 其了解如何重定向客户端请求， 知晓如何操作一切活动部件。 创建附加外观 ...

本博客大部分内容来于免费在线学习设计模式 1：桥接模式桥接模式是一种结构型设计模式， 可将一个大类或一系列紧密相关的类拆分为抽象和实现两个独立的层次结构， 从而能在开发时分别使用。 2：桥接模式问题在现实生活中，某些类具有两个或多个维度的变化，如图形既可按形状分，又可按颜色分。如何设计类似于 Photoshop 这样的软件，能画不同形状和不同颜色的图形呢？如果用继承方式，m 种形状和 n 种颜色的图形就有 m×n 种，不但对应的子类很多，而且扩展困难。 3：桥接模式解决方案问题的根本原因是我们试图在两个独立的维度——形状与颜色——上扩展形状类。这在处理类继承时是很常见的问题。 桥接模式通过将继承改为组合的方式来解决这个问题。具体来说，就是抽取其中一个维度并使之成为独立的类层次， 这样就可以在初始类中引用这个新层次的对象， 从而使得一个类不必拥有所有的状态和行为。 将颜色相关的代码抽取到拥有红色和蓝色两个子类的颜色类中，然后在形状类中添加一个指向某一颜色对象的引用成员变量。现在，形状类可以将所有与颜色相关的工作委派给连入的颜色对象。 这样的引用就成为了形状和颜色之间的桥梁。 此后 ...

本博客大部分内容来于免费在线学习设计模式 1：命令模式命令模式是一种行为设计模式， 它可将请求转换为一个包含与请求相关的所有信息的独立对象。 该转换让你能根据不同的请求将方法参数化、 延迟请求执行或将其放入队列中， 且能实现可撤销操作。 2：命令模式问题假如你当前有一个列表页面需要渲染，当页面加载时需要请求数据，点击重置按钮时也需要请求页面数据，搜索数据也可以根据这个接口来请求数据。那么你怎么处理呢？是将数据的实现类复制多次，还是用其他方法呢？ 3：命令模式解决方案很显然，在我们的实际使用中，是将数据请求和数据实现分离。将请求的所有细节（例如调用的对象、方法名称和参数列表）抽取出来组成命令类，该类中仅包含一个用于触发请求的方法。 在现实生活中，命令模式的例子也很多。比如看电视时，我们只需要轻轻一按遥控器就能完成频道的切换，这就是命令模式，将换台请求和换台处理完全解耦了。电视机遥控器（命令发送者）通过按钮（具体命令）来遥控电视机（命令接收者）。 再比如，我们去餐厅吃饭，菜单不是等到客人来了之后才定制的，而是已经预先配置好的。这样，客人来了就只需要点菜，而不是任由客人临时定制。餐厅提供 ...

本博客大部分内容来于免费在线学习设计模式 1：原型模式原型模式是一种创建型设计模式，使你能够复制已有对象，而又无需使代码依赖它们所属的类。 2：原型模式问题如果你有一个对象，并希望生成与其完全相同的一个复制品，你该如何实现呢？首先，你必须新建一个属于相同类的对象。然后，你必须遍历原始对象的所有成员变量，并将成员变量值复制到新对象中。 但是并非所有对象都能通过这种方式进行复制， 因为有些对象可能拥有私有成员变量， 它们在对象本身以外是不可见的。 3：原型模式解决方法用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型相同或相似的新对象。在这里，原型实例指定了要创建的对象的种类。用这种方式创建对象非常高效，根本无须知道对象创建的细节。例如，Windows 操作系统的安装通常较耗时，如果复制就快了很多。在生活中复制的例子非常多，这里不一一列举了。 4：原型模式解决方案 原型 （Prototype） 接口将对克隆方法进行声明。 在绝大多数情况下， 其中只会有一个名为 clone克隆的方法。 具体原型 （Concrete Prototype） 类将实现克隆方法。 除了将原始对象 ...

本博客大部分内容来于免费在线学习设计模式 1：观察者模式观察者模式是一种行为设计模式，允许你定义一种订阅机制，可在对象事件发生时通知多个“观察”该对象的其他对象。 2：观察者模式问题在现实世界中，许多对象并不是独立存在的，其中一个对象的行为发生改变可能会导致一个或者多个其他对象的行为也发生改变。拿双十一举例：如果某一商品决定在双十一当天零点进行大促销，如果他选择不通知任何人，那么他这一件商品的销量就只有听天由命了，一件都卖不去也说停；如果他选择通知所有浏览过这件商品的人，也许在这些人里有想买这件商品的人会选择购买，但是也会有很多不需要这件商品的人收到骚扰。在生活中，他们是怎么解决这件事的呢？ 3：观察者模式解决方案在生活中，这些购物软件给店铺提供了一个渠道：对于那些关注过这家店铺，或者在这家店铺购买过的商品的潜在用户。店家可以通过软件提供的消息推送方式，或者购买记录的个人信息（虽然各种短信也挺骚扰的）。告诉你：我要降价了，快来买哦。这样店家也达成通知用户提高销量的目的，买家也可以低价买入需要的物品。 观察者（Observer）模式的定义：指多个对象间存在一对多的依赖关系，当一个对象 ...