最近换了一份新工作，全新的开始，一切还在奋斗的道路上，自己给自己打个气!
设计模式系列很久没有更新了，废话不多说，开始今天的桥接模式。
定义：
何为Bridge模式？我们知道，实现与抽象之间总是存在着强依赖，Bridge模式的意义就是解耦实现与抽象，这意味着实现与抽象不再有着静态的依赖关系，它们彼此可以拥有独立的变化，从而互不影响。
桥接模式 (Bridge Pattern)-结构型模式第五篇
代理模式 (Proxy Pattern)-结构型模式第四篇
过去的大半年时间，日子过的忙忙碌碌！今天奉献一篇设计模式系列的新文章，挑选再三，始终觉得Proxy模式是很好的选择，Let’s Go!
定义：
Proxy模式，简言之，它像一个代理人，或者说像一个包装盒，它用来封装、控制背后真实的对象，自己可以独立提供被外界访问的能力，它与背后真实的对象派生于相同的接口，但代理人通常会将对真实对象的调用更加简单化，以便外界更加容易的使用。在客户端看来，自己似乎是直接在操作被代理的真实对象，但事实是，所有的操作都经过代理人的封装、控制、包装，而这些额外的操作，对于客户端来说，似乎是透明的。
应用：
Proxy模式，透明了对原始真实对象的调用，使我们有能力在调用真实对象的前后执行额外的动作，所以我们可以将一些与业务无关的软件基础功能添加在前后的额外动作中。比如Exception Handling, Logging, Caching等。
倘若再结合一些DI/IoC容器、编译器，有能力动态或静态地创建真实对象的代理，便无须手动去编写代理类，此时若配合一些编程语言的语法元数据(比如Java 中的@Attribute，C#中的[Attribute])，便可以在调用真实对象的方法前后执行额外的动作(通常可以称之为Interceptor 或Filter)，这便初步实现了AOP编程。
UML：
适配器模式 (Adapter Pattern)-结构型模式第三篇
祖国母亲生病了，一场突如其来的新冠病毒让这个古老的中华民族正在经历一场全民参与、没有硝烟、却生离死别的战争。每每看到抖音里的那些感人场景虽然不至于声泪俱下，却也是感慨万千、悲愤不已。大家现在都蛰伏在家，等待时机成熟破茧化蝶。相信这个春节在很多人的记忆里永远再也无法抹去，只希望所有人都安好！岁岁平安！
想起抖音里某位才人拍摄的一段视频，视频里这位仁兄使用女用卫生巾夹在普通一次性口罩中混合使用，以提高过滤功效。感叹一句，此乃神人也，有才，不得不佩服！笑归笑，这里不禁想起了设计模式中一个称之谓适配器(Adapter)的模式，所谓Adapter模式简言之，适配器能够使原本两个不兼容的接口能够协同工作。这位才人他没有将卫生巾直接戴在嘴上、卡在脸上（那可不适配），而是通过一个一次性口罩进行了转换、隐藏、适配，然后交由一次性口罩来担负起对外的形象任务，抽象一点的说其实这也算是一个适配器模式的应用：）
好吧，让我们来正式认识一下Adapter模式吧！ Continue reading “适配器模式 (Adapter Pattern)-结构型模式第三篇”
组合模式 (Composite Pattern)-结构型模式第二篇
静悄悄中时间飞逝，感叹一句最近TMD真忙真累，好在天生坚强性格阳光，不吹不黑，下面开始讲结构型模式(Structural patterns)的第2篇，Composite Pattern，中文称之为组合或复合模式。
定义：
Composite模式，能够灵活地实现循环、递归、部分-整体类的结构，使外部世界能够以一致的方式处理单体或集合。
解决的问题：
- 就像定义中所提及的那样，如何使客户端能够以一致的方式去访问某个单体或者集合，以使结构更加简洁
- 如何优雅的表达一个树形结构
怎么去解决（包含叶子Leaf的实现方式）：
- 通过定义一个接口代表集合与个体所拥有的相同属性与行为，如IComponent
- 通过定义一个类Composite，它继承自IComponent，同时通过组合的方式它拥有一个名称为Components的属性，它代表着一个IComponent集合
- Composite有能力将一个实现了IComponent接口的对象加入到Components中
- 对于Composite的任何请求，都会被重定向到属性Components中的每个个体分别去执行
- 通过定义一个类Leaf，它继承自IComponent，代表着不可再分割的个体
举个栗子，在一个树状结构中，树杆、树枝、树叉皆由Composite来表示，而Leaf代表的是末端的每片树叶。
怎么去解决（进一步抽象）：
通过分析我们能够发现在上面的解决方式中，如果有能力分辨一个IComponent是树杆还是树叶，便可以将Composite和Leaf合并为一个类型，于是我们为IComponent引入一个新的属性HasChild，并且给它换一个更贴切的名字INode，如果HasChild为True，则代表它是Composite，反之则代表它是Leaf Continue reading “组合模式 (Composite Pattern)-结构型模式第二篇”
装饰者模式 (Decorator Pattern)-结构型模式第一篇
本篇是结构型模式(Structural patterns)的第一篇，之所以选择Decorator模式第一个出场，是由于抓揪随机的结果。Decorator模式能够为行为带来灵活的组合，减少子类的数量，希望文章能够给大家带来一点帮助。
定义：
Decorator模式，能够将行为动态地添加到一个类型实例，而不会影响其它的实例。
解决的问题：
- 如何在运行时给一个对象添加新的行为
- 如何减少子类的数量
- 我们知道通过新建一个子类，也能够为类型添加新的行为，但是它存在一个明显的缺陷：随着新行为数目的不断增加，需要增加更多数目的子类，并且行为之间无法组合使用
怎么去解决：
- 通过定义一个接口代表原始对象本身，如IComponent
- 通过定义一个接口IDecorator，它继承自IComponent，同时通过组合的方式它拥有IComponent
- 对于IDecorator的任何请求，都会被重定向到IComponent，并且在重定向前后我们有能力添加新的行为
UML：
原型模式(Prototype Pattern)-创建型模式第五篇
距离发布上篇软件设计模式文章《建造者模式》稍稍地已经过去两个多月，今天来谈一下第五个创建型模式，这也将是最后一个创建型模式——原型模式(Prototype Pattern)。
定义：
Prototype模式，通过将对象自身进行复制来创建新的对象。多么简单的定义，该模式也很简单。
解决的问题：
- 在运行时如何动态创建一个对象的副本
怎么去解决：
- 通过定义一个含有Clone方法的Prototype接口
- 具体的实现类通过继承Prototype接口来创建自身的复制品
UML：
建造者模式(Builder Pattern)-创建型模式第四篇
也许得写一个段落放在文章的开头才会显得整篇没那么单调，我想写些什么，但指头落下的那一刻便忘了。简言之，设计模式犹如人生。好吧，也许这就算一个简单的开头，请让我们来看今天的主角，建造者模式(Builder Pattern)，我不确定中文称它建造者模式是否准确，偶尔也会看到有人称其构建者或生成器模式。
定义：
Builder模式，通过将对象的构造过程与其本身分离开来，以简化复杂对象的创建过程，并且能够实现相同的构造过程可以创建不同的对象。
解决的问题：
- 如何通过简单的方式创建一个复杂的对象
- 如何通过相同的过程来创建类的不同实例
怎么去解决：
- 在一个独立的Builder对象中去创建和组装复杂对象的各个部分
- 通过对Builder的抽象，在创建复杂对象的过程中委托给具有相同接口的不同Builder实现，以达到相同的过程创建不同的对象
UML：
单例模式(Singleton Pattern)-创建型模式第三篇
人坚持一件事情是挺难的，工作如此、生活如此、友情如此、亲情如此、爱情亦如此，如果有人能够坚持真心待你，请珍惜他或她。闲话不多说，让我们来看今天的主角，单例模式(Singleton Pattern)。
解决的问题：
- 如何确保一个类在应用程序生命周期中只产生一个对象。例如外观模式(Facade Pattern)往往就需要结合Singleton模式来使用，在一个应用中Facade模式通常只需存在一个实例
- 如何能让对象状态在整个应用程序生命周期内被使用，Singleton模式相对全局变量在某些语言中可能存在如下优势：
- Singleton模式可以延迟初始化和内存分配，在某些语言中（比如C++）全局变量在应用程序初始化期间内存便被分配
怎么去解决：
就像其它所有模式一样，实现Singleton模式的方法也有多种，下面例举其中一种方法。
- 通常我们可以为类定义一个公共的静态方法或属性，并在该方法或属性体中进行类的实例化，倘若发现已经存在实例化的对象，那么就直接返回这个已经存在的对象。
UML：
抽象工厂模式(Abstract Factory Pattern)-创建型模式第二篇
解决的问题：
- 如何创建一个类，使其能够独立于它所需要的对象
- 如何让相关的产品对象能够一同被创建
怎么去解决：
- 将一系列具体对象的创建封装在单独的工厂对象里，你需要定义这个工厂的接口，然后实现这个抽象的工厂
- 客户端上下文在调用时，通过工厂去创建抽象的产品从而代替直接创建具体的产品对象
定义：
我想抽象工厂的核心定义是提供一个接口，用于创建一组依赖的对象（接口），并且无需指定具体的实现对象
具体的工厂决定了怎样的一系列具体对象会被创建，方法所返回的将是一个抽象的产品接口类型。在运行时上下文中，客户端将依赖于这个抽象的产品接口指针，而不用关心具体的实现提供者是什么。 Continue reading “抽象工厂模式(Abstract Factory Pattern)-创建型模式第二篇”
工厂方法模式(Factory Method)-创建型模式第一篇
解决的问题：
- 如何创建一个对象，以便子类可以重新定义要实例化的类
- 一个类如何将实例化延迟到子类
怎么去解决：
- 为创建对象定义单独的操作方法（工厂方法）
- 通过调用工厂方法创建对象
定义：
定义用于创建对象的接口，但让子类决定要实例化哪个类。工厂方法允许类延迟实例化它使用的子类。
创建对象通常需要复杂的过程，对象的创建可能导致代码的大量重复，可能需要构成对象无法访问的信息，可能无法提供充分的抽象级别。工厂方法模式通过定义单独的方法去创建对象来处理这些问题，然后子类可以重写以满足未来创建产品的派生类型。 Continue reading “工厂方法模式(Factory Method)-创建型模式第一篇”