Devil的个人博客

Spring Cloud-Sentinel

设计模式–行为型模式之策略模式意图策略模式是一种行为设计模式， 它能让你定义一系列算法， 并将每种算法分别放入独立的类中， 以使算法的对象能够相互替换。 问题一天， 你打算为游客们创建一款导游程序。 该程序的核心功能是提供美观的地图， 以帮助用户在任何城市中快速定位。 用户期待的程序新功能是自动路线规划： 他们希望输入地址后就能在地图上看到前往目的地的最快路线。 程序的首个版本只能规划公路路线。 驾车旅行的人们对此非常满意。 但很显然， 并非所有人都会在度假时开车。 因此你在下次更新时添加了规划步行路线的功能。 此后， 你又添加了规划公共交通路线的功能。 而这只是个开始。 不久后， 你又要为骑行者规划路线。 又过了一段时间， 你又要为游览城市中的所有景点规划路线。 导游代码将变得非常臃肿。 尽管从商业角度来看， 这款应用非常成功， 但其技术部分却让你非常头疼： 每次添加新的路线规划算法后， 导游应用中主要类的体积就会增加一倍。 终于在某个时候， 你觉得自己没法继续维护这堆代码了。 无论是修复简单缺陷还是微调街道权重， 对某个算法进行任何修改都会影响整个类， 从而增加在已有正常运行代 ...

设计模式–行为型模式之状态模式意图状态模式是一种行为设计模式， 让你能在一个对象的内部状态变化时改变其行为， 使其看上去就像改变了自身所属的类一样。 问题状态模式与有限状态机 的概念紧密相关。 有限状态机。 其主要思想是程序在任意时刻仅可处于几种有限的状态中。 在任何一个特定状态中， 程序的行为都不相同， 且可瞬间从一个状态切换到另一个状态。 不过， 根据当前状态， 程序可能会切换到另外一种状态， 也可能会保持当前状态不变。 这些数量有限且预先定义的状态切换规则被称为转移。 你还可将该方法应用在对象上。 假如你有一个 文档 Doc­u­ment 类。 文档可能会处于 草稿Draft 、 审阅中 Mod­er­a­tion 和 已发布 Pub­lished 三种状态中的一种。 文档的 pub­lish发布方法在不同状态下的行为略有不同： 处于 草稿状态时， 它会将文档转移到审阅中状态。 处于 审阅中状态时， 如果当前用户是管理员， 它会公开发布文档。 处于 已发布状态时， 它不会进行任何操作。 文档对象的全部状态和转移。 状态机通常由众多条件运算符 （ if或 switch ...

设计模式–行为型模式之观察者模式意图观察者模式是一种行为设计模式， 允许你定义一种订阅机制， 可在对象事件发生时通知多个 “观察” 该对象的其他对象。 问题假如你有两种类型的对象： 顾客和 商店 。 顾客对某个特定品牌的产品非常感兴趣 （例如最新型号的 iPhone 手机）， 而该产品很快将会在商店里出售。 顾客可以每天来商店看看产品是否到货。 但如果商品尚未到货时， 绝大多数来到商店的顾客都会空手而归。 前往商店和发送垃圾邮件 另一方面， 每次新产品到货时， 商店可以向所有顾客发送邮件 （可能会被视为垃圾邮件）。 这样， 部分顾客就无需反复前往商店了， 但也可能会惹恼对新产品没有兴趣的其他顾客。 我们似乎遇到了一个矛盾： 要么让顾客浪费时间检查产品是否到货， 要么让商店浪费资源去通知没有需求的顾客。 解决方案拥有一些值得关注的状态的对象通常被称为目标， 由于它要将自身的状态改变通知给其他对象， 我们也将其称为发布者 （pub­lish­er）。 所有希望关注发布者状态变化的其他对象被称为订阅者 （sub­scribers）。 观察者模式建议你为发布者类添加订阅机制， 让每个对象 ...

设计模式–行为型模式之中介者模式 定义一个对象来封装一系列对象的交互。中介者模式使各对象之间不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间地交互 场景介绍：房产中介 假如没有总经理。下面三个部门：财务部、市场部、研发部。财务部要发工资，让大家核对公司需要跟市场部和研发部都通气；市场部要接个新项目，需要研发部处理技术、需要财务部出资金。市场部跟各个部门打交道。 虽然只有三个部门，但是关系非常乱。 实际上，公司都有总经理。各个部门有什么事情都通报到总经理这里，总经理再通知各个相关部门。 这就是一个典型的“中介者模式”，总经理起到一个中介、协调的作用 实现核心   如果一个系统中对象之间的联系呈现为网状结构，对象之间存在大量多对多关系，将导致关系及其复杂，这些对象称为”同事对象”，我们可以引入一个中介者对象，使各个同事对象只跟中介者对象打交道，将复杂的网络结构化解为星型结构。 模式动机 在用户与用户直接聊天的设计方案中，用户对象之间存在很强的关联性，将导致系统出现如下问题： 系统结构复杂：对象之间存在大量的相互关联和调用，若有一个对象发生变化，则需要跟 ...

设计模式–行为型模式之命令模式 将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销的操作 模式动机在软件设计中，我们经常需要向某些对象发送请求，但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，我们只需在程序运行时指定具体的请求接收者即可，此时，可以使用命令模式来进行设计，使得请求发送者与请求接收者消除彼此之间的耦合，让对象之间的调用关系更加灵活。 命令模式可以对发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。这就是命令模式的模式动机。 模式定义命令模式(Command Pattern)：将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。 模式结构命令模式包含如下角色： Command: 抽象命令类 抽象命令类中声明了用于执行请求的execute()等方法，通过这些方法可以调用请求接 ...

设计模式–结构型模式之代理模式 给某一个对象提供一个代理或占位符，并且代理对象来控制对原对象的访问 模式动机在某些情况下，一个客户不想或者不能直接引用一个对 象，此时可以通过一个称之为“代理”的第三者来实现 间接引用。代理对象可以在客户端和目标对象之间起到 中介的作用，并且可以通过代理对象去掉客户不能看到 的内容和服务或者添加客户需要的额外服务。 通过引入一个新的对象（如小图片和远程代理 对象）来实现对真实对象的操作或者将新的对 象作为真实对象的一个替身，这种实现机制即 为代理模式，通过引入代理对象来间接访问一 个对象，这就是代理模式的模式动机。 模式定义代理模式(Proxy Pattern) ：给某一个对象提供一个代 理，并由代理对象控制对原对象的引用。代理模式的英 文叫做Proxy或Surrogate，它是一种对象结构型模式。 模式结构代理模式包含如下角色： Subject: 抽象主题角色 声明了真实主题和代理主题的共同接口； Proxy: 代理主题角色 内部包含对真实主题的引用，从而可以在任何时候操作真实主题对象，控制和限制被代理角色的实现，并且拥有自己的处理方法（预处理和善 ...

设计模式–结构型模式之享元模式 运用共享技术有效地支持大量细粒度对象的复用 spring的常量池、数据库连接池、缓冲池等等这些都是享元模式的应用 比如：我们每次创建字符串对象时，如果每次都创建一个新的字符串对象的话，内存开销会很大，所以如果第一次创建了字符串对象“七夕“，下次再创建相同的字符串”七夕“时，只是把它的引用指向”七夕“，这样就实现了”七夕“字符串再内存中的共享。 享元拆开来讲，享，即共享，元，可以理解为元数据，内存当中的数据，对象。看来是共享对象喽 模式动机面向对象技术可以很好地解决一些灵活性或可扩展性问题，但在很多情况下需要在系统中增加类和对象的个数。当对象数量太多时，将导致运行代价过高，带来性能下降等问题。 享元模式正是为解决这一类问题而诞生的。享元模式通过共享技术实现相同或相似对象的重用。 在享元模式中可以共享的相同内容称为内部状态(IntrinsicState)，而那些需要外部环境来设置的不能共享的内容称为外部状态(Extrinsic State)，由于区分了内部状态和外部状态，因此可以通过设置不同的外部状态使得相同的对象可以具有一些不同的特征，而相同的内部 ...

设计模式–结构型模式之外观模式 为子系统的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用 模式定义外观模式(Facade Pattern)：外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。 模式结构外观模式包含如下角色： Facade: 外观角色 客户端直接调用的角色，在外观角色中可以知道相关的(一个或者多个)子系统的功能和责任，它将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理； SubSystem:子系统角色 在软件系统中可以同时有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能。 时序图 模式分析根据“单一职责原则”，在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性，一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小，而达到该目标的途径之一就是引入一个外观对象，它为子系统的访问提供 ...

设计模式–结构型模式之装饰模式 动态地给一个对象增加一些额外的职责，就扩展功能而言，装饰模式提供了一种比使用子类更加灵活的替代方案 定义有时我们希望给某个对象而不是整个类添加一些功能，虽然使用继承是添加功能的一种方式，但是不够灵活，而且会导致子类增加了无用功能，耦合性太强。一种较为灵活的方式是将对象嵌入另一个对象中，通过该对象添加功能，称这个嵌入的对象为装饰。这个装饰与被装饰的对象接口一致，它将请求转发给被装饰对象，并在转发的前后进行额外操作。 装饰模式就是动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。 结构装饰模式包含如下角色： Component: 抽象构件 定义了对象的接口，可以给这些对 象动态增加职责（方法）； ConcreteComponent: 具体构件（也可称为被装饰者） 具体构件定义了具体的构件对象，实现了 在抽象构件中声明的方法，装饰器可以给它增加额外的职责（方法）； Decorator: 抽象装饰类 抽象装饰类是抽象构件类的子类，用于给具体构件增加职责，但是具 体职责在其子类中实现； ConcreteDeco ...