基本介绍：    命令模式，顾名思义就是将命令抽象化，然后将请求者和接收者通过命令进行绑定。   而命令的请求者只管下达命令，命令的接收者只管执行命令。   从而实现了解耦，请求者和接受者二者相对独立。   单独理解起来比较困难，咱们还是通过具体实例来说明吧。 举例说明：   生活中遥控控制电器就是命令模式，比如智能开关控制一盏灯。   首先将灯的开和关封装成一个命令，然后将这个命令绑定到智能开关上。   智能开关的执行其实就是灯开关的执行，灯和智能开关是通过命令来进行交互的。   这个时候如果想控制电视的开关，那就可以将电视的开关封装成一个命令。   然后将这个命令绑定到智能开关上...

基本介绍：   “责任链”顾名思义，是指一个需要负责处理请求的链条。   每个链条节点都是一个单独的责任者，由责任者自己决定是否处理请求或交给下一个节点。   在设计模式中的解释则为：为请求创建了一个接收者对象的链。适用于有多个对象可以处理同一个请求，但具体由哪个对象处理则在运行时动态决定的情况。   俗话说起来就是一群领导组成了一个上下级链路关系，每个领导的职责各不相同，老百姓办事情的时候肯定没办法知道该找哪个领导。   这个时候就可以把需要办的事情交给接待人员，由接待人员自行判断是不是可以处理或者交给上级处理，至于是谁给我负责，那我这个小老百姓并不关心，只要办了就可以了。   老百姓办的事...

基础介绍：   将抽象部分与它的实现部分分离，使它们都可以独立地变化。适用于不希望在抽象和实现部分之间有固定的绑定关系的情况，或者类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充的情况。   将抽象部分与实现部分分离，使它们都可以独立地变化。   其实两个都是抽象的部分，更准确的说，是将一个事物中多个维度的变化分离。   比如不用软件运行在不同的操作系统上。   操作系统是一个维度，分为ios、Android、Windows等。   软件系统是一个维度，分别为微信、QQ、酷狗音乐等。   一个维度可以认为是抽象部分，另一个维度可以认为是实现部分，而这两个维度可以独立扩充和维护。   单...

基本介绍：   “代理”顾名思义指以他人的名义，在授权范围内进行处理事情的意思。   在编程语言中的则解释为：为其他对象提供一种代理以控制对这个对象的访问。   从释义上不难解读，代理本质就是一个中介，客户通过中介来访问原对象。本质就是在原对象基础上包了一层封装。   那么问题来了，为什么不直接使用原对象，反而多此一举的创建这个第三者出来呢。下面就通过一些例子来具体说明。 举例说明：   场景一：使用第三方登录时，比如QQ、微信登录，我们不可能直接引用第三方那边的任何源代码的东西，但可以通过封装第三方暴露出来的api才进行开发。       在这个场景里，第三方的api就是原对象，我们做封装的...

基础介绍：   组合模式用于表示部分-整体的层次结构。适用于希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象的情况。   顾名思义，什么叫部分-整体，比如常见的前端UI，一个DIV标签中可以存在多个A标签、P标签、DIV标签等等。   相较于DIV这个容器整体而言，其中所含的A标签、P标签甚至是DIV标签都是单个的部分。   而显示的时候却是一视同仁，不分部分还是整体。   这就是典型的组合模式。   再比如WinForms应用程序中，Label、TextBox等这样简单的控件，可以理解为节点对象，它们中无法再插入其他控件，它们就是最小的。   而比如GroupBox...

基础介绍：   动态地给一个对象添加一些额外的职责。适用于需要扩展一个类的功能，或给一个类添加多个变化的情况。   装饰器，顾名思义就是在原有基础上添加一些功能。   大家都只知道如果想单纯的给原有类增加一些功能，可以直接继续该类生成一个子类就可以。   举个例子，如果现在有个手机类，想给手机贴膜，传统的做法就是新建一个手机类的子类（手机贴膜子类），继承自手机类。   使用这个子类就可以完成对手机的贴膜操作。   那如果又想给手机按保护壳的话，传统做法有两种，可以继续新建一个手机类的子类（手机保护壳子类），继承自手机类。   使用这个子类可以给手机按保护壳，但也就失去了给手机贴膜的功能。另一种...

基础介绍：   想象这样一个场景，原项目中接口返回的数据是XML格式的数据，但现在来了一个新客户，它期望接口返回的数据类型为json格式的。   想要实现要么就是改原有接口，但这样就违反了开闭原则，容易出现未知bug，影响到老客户的正常使用。   而如果写一个适配器类也就是转换类（第三方类），将原本返回的XML格式数据转换成json格式数据，而具体数据是怎么来的则直接用原有接口方法就可以。   新客户只需要调用适配器类就可以了，而老客户这边也不会进行任何修改处理。   如果再有新的客户要求其他类型的返回，只需要在适配器类中增加相应的转换处理就可以了。   再思考一个问题，现实生活中空调插头一般...

基础介绍：   具体可分为2个角色：     Prototype（原型类）：声明一个Clone自身的接口；     ConcretePrototype（具体原型类）：，实现一个Clone自身的操作。 　　在原型模式中，Prototype通常提供一个包含Clone方法的接口，具体的原型ConcretePrototype使用Clone方法完成对象的创建。     本质：通过拷贝这些原型对象创建新的对象。   根据其本质可以理解，原型本身就是通过一个自身的Clone方法来进行自我复制，从而产生新的对象。   比如，孙猴子吹猴毛变化多个克隆体时，就是用了原型模式，通过对自身的自我复制从而生产...

基础介绍：   将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。   说白了就是将一个复杂的对象拆分成一个一个零件，然后按照既定顺序和规则进行组装，最终形成这个相对复杂的对象。   具体可分为4个角色：     Product（产品）：复杂对象本身。     Builder（抽象建造者）：既可以是抽象类也可以是接口，主要是为了约束和规范具体建造者有哪些零件，并提供一个方法返回组装后的复杂对象。     ConcreteBuilder（具体建造者）：它继承自Builder（抽象建造者），主要是具体实现父类中的那些零件。也就是说在这个类里就要实际去创建各个零件的具体功能了...

基本介绍：   享元模式的定义：运用共享技术有效地支持大量细粒度的对象重复使用。适用于大量小粒度的对象造成的运行效率和内存使用效率低下的情况。   “享元”顾名思义，“享”共享的意思，“元”单元，最小对象，零部件的意思。   即从字面意思不难看出，该模式旨在共享一些零部件供其使用。   想要实现对这些零部件的重复使用，那必然需要一个类来统筹安排，负责它们的创建、使用和维护。   如果想要实现一个零部件的使用，可以使用单例模式，所以享元模式其实也可以看做是单例模式的复数模式。   它们都是在一个固定类中对对象进行创建和维护。 举例说明：   比如五子棋游戏，构成游戏的组件，无非就是无数个黑棋和白...

基础介绍：   确保一个类只有一个实例，并提供一个全局访问点。   适用于需要频繁实例化然后销毁的对象，创建对象消耗资源过多，但又经常用到的对象，频繁访问数据库或文件的对象。   其本质就是保证在整个应用程序的生命周期中，任何一个时刻，单例类的实例都只存在一个。 特性和功能：确保一个类只有一个实例，并提供一个全局访问点。 使用环境：当类只需要一个实例，且易于访问，且实例应在整个应用程序中共享时。 注意事项：需要注意线程安全问题。 优点：可以确保一个类只有一个实例，减少了内存开销。 缺点：没有接口，扩展困难。   应用场景：   单例模式通常适用于在整个应用程序中只需要一个实例化对象的场景，...

总体介绍：   工厂模式主要有三种类型：简单工厂、工厂方法和抽象工厂，该模式用于封装和管理对象的创建，是一种创建型模式。   万物皆对象，创建对象时必然需要new该对象，当需要更改对象时，需要把项目中所有地方都修改一遍，这显然违背了软件设计的开闭原则。   如果使用工厂来生成对象，那么我们只需要跟工厂打交道就可以了。如果要更新对象时，直接在工厂里更换即可。这就实现了对象解耦。   所以工厂模式主要用来解耦代码，将对象的创建和使用分离，使得代码更加灵活和可维护。   定义创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。   适用于创建对象需要大量重复的步骤...