命令模式（Command Pattern）是一种行为型设计模式，它将请求和处理分开，使得请求发送者和接收者解耦，从而降低系统的耦合度。在命令模式中，请求被封装为一个独立的对象，并且将其参数化，以便在不同的请求中传递不同的参数。 命令模式的核心原理 在命令模式中，请求被封装为一个对象，从而可以将请求的调用者与实现者分离开来。这降低了系统的耦合度，使得不同的调用者可以发送不同的请求给同一个接收者，而不需要修改接收者的代码。同时，命令模式还提供了对事务进行建模的方法，可以实现对事务的撤销、重做等操作。其核心角色主要有以下几个核心组成部分：
在一些业务场景下，为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。在责任链模式中，多个处理器（也就是刚刚定义中说的“接收对象”）依次处理同一个请求。一个请求先经过A处理器处理，然后再把请求传递给B处理器，B处理器处理完后再传递给C处理器，以此类推，形成一个链条。链条上的每个处理器各自承担各自的处理职责，所以叫作职责链模式。
迭代器模式（Iterator pattern）是一种对象行为型设计模式，它提供了一种方法来顺序访问聚合对象中的元素，而又不暴露该对象的内部表示，同时也可以将迭代逻辑与聚合对象的实现分离，增强了代码的可维护性和可扩展性。 迭代器模式的特征如下： - 迭代器模式允许一个聚合对象公开它的每一个元素，而又不暴露其内部表示，即它提供了一种方法来遍历聚合对象中的每一个元素，而不需要了解该对象的内部结构或实现。 - 迭代器模式的主要目的是将迭代逻辑封装在迭代器对象中，而不是将该逻辑嵌入到聚合对象中。这样可以将迭代逻辑与聚合对象的实现分离，使得它们可以独立地改变和扩展。 - 迭代器模式是通过定义一个迭代器接口来实现的。该接口提供了访问和遍历聚合对象的元素的方法。聚合对象则需要实现一个能够创建相应迭代器的接口。
观察者模式是一种对象行为模式，它定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。在观察者模式中，主题是通知的发布者，它发出通知时并不需要知道谁是它的观察者，可以有任意数目的观察者订阅并接收通知。
在模板方法模式中，抽象类负责给出算法的轮廓和骨架（由一个或多个模板方法组成），而实现类则负责实现抽象类中所定义的抽象方法和钩子方法。模板方法模式相当于定义了一个操作中的算法的骨架，具体的特定步骤的实现延迟到子类中去定义，使得子类可以不更改一个算法的结构，就可以重新定义算法的某些特定步骤。
策略模式是一种行为型设计模式，它定义了一系列算法，并将每个算法封装起来，使它们可以相互替换。策略模式的主要目的是将算法的行为和环境分开，将一系列算法封装在策略类中，并在运行时根据客户端的需求选择相应的算法。策略模式适用于需要使用多种算法，且算法之间可以相互替换的情况。在策略模式中，算法的变化不会影响到使用算法的客户端。
享元模式是一种对象结构型模式，享元模式通过存储这些共享实例对象的地方称为享元池(Flyweight Pool)，可以避免频繁的创建销毁对象，大幅度减少需要创建的对象数量，避免大量相似类的开销，从而提高系统资源的利用率。一般和单例模式配合使用，将享元工厂声明为一个单例类来池化享元对象。享元模式要求能够共享的对象必须是细粒度对象，因此它又称为轻量级模式。
组合模式（Composite Pattern）是一种结构型设计模式，它创建了对象组的树形结构，将对象组合成树状结构以表示“整体-部分”的关系。组合模式使得用户对单个对象和组合对象的访问具有一致性，即：组合能让客户以一致的方式处理个别对象以及组合对象
桥梁模式的核心原理是将抽象化（Abstraction）与实现化（Implementation）脱耦，使得二者可以独立地变化。 具体来说，桥梁模式通过组合或聚合关系来建立抽象和实现之间的关系，而不是使用继承关系。这样可以降低抽象和实现之间的耦合度，使得它们可以独立地变化。
门面模式是一种结构型设计模式，它提供了一个统一的接口，用来访问子系统中的一群接口。它定义了一个高层接口，让子系统更容易使用。这种模式常用于将一个复杂的子系统封装成一个简单的接口，使得客户端可以方便地使用子系统的功能，而不需要了解子系统的具体实现细节。
代理模式是一种设计模式，它为其他对象提供一种代理以控制对该对象的访问。即用户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。代理模式给某一个对象提供一个代理对象，并由代理对象控制原对象的引用。通俗的来讲代理模式就是我们生活中常见的中介。通过代理类，起到了中介隔离作用，代理类除了是客户类和委托类的中介隔离作用之外，我们还可以通过给代理类增加额外的功能来扩展委托类的功能，这样做我们只需要修改代理类，而不需要在修改委托类，符合代码设计的开闭原则。代理类主要负责为委托类预处理消息、过滤消息、把消息转达给委托类，以及时候对返回结果的处理等。代理类本身不真正实现服务，而是通过调用委托类的相关方法，来提供特定的服务。例如，购买火车票不一定要去火车站买，可以通过 12306 网站或者去火车票代售点买。又比如找女朋友、找保姆、找工作等都可以通过找中介完成
装饰器模式是一种结构型设计模式，它允许向一个现有的对象动态添加功能，而不需要修改其源代码。这种模式的核心思想是使用装饰器类来包装原始类，并在保持类方法签名完整性的前提下，提供额外的功能。每个装饰器都包装了原始组件，并添加了新的功能。这些装饰器可以被嵌套，以实现更多的功能组合。使用装饰器模式的好处之一是在运行时动态添加或删除功能，而不会对原始组件的代码产生影响。这种灵活性使得装饰器模式非常适用于大型项目中的代码重构和维护。
适配器模式的核心是将一个类的接口转换成客户端所期望的另一种接口，从而使原本因接口不匹配而导致无法在一起工作的两个类能够一起工作。适配器模式是一种结构型设计模式，它通过引入一个适配器类来将不兼容的接口转换为兼容的接口。
原型模式是一种创建型模式，它允许通过复制现有对象来创建新对象，而无需从头开始创建全新的对象。这种模式在软件系统中应用很广泛，特别是在需要创建大量相似或相同对象的情况下。 这种模式的主要想法是，在某个类（称为“原型类”）中定义一个方法，该方法用于创建并返回该类的另一个实例。这个新实例是原型的复制品，通过复制现有的对象来创建，而不是通过使用构造函数来创建新的对象。
建造者模式的核心思想是通过步骤化的构建过程来创建复杂对象。具体来说，当需要创建一个复杂对象时，客户端通过实例化一个具体建造者对象，并将其传递给指挥者。指挥者根据特定的构建步骤和顺序，逐步调用具体建造者的方法来构建产品。最终，指挥者返回构建好的产品给客户端。
单例模式是一种常用的软件设计模式，其主要作用是保证某一个类只能有一个实例，并提供对该实例的全局访问点。 单例模式有三个要点： 1.某个类只能有一个实例。 2.它必须自行创建这个实例。 3.它必须自行向整个系统提供这个实例。 单例模式的分类 单例设计模式在具体实现上有，分为两类： 1.饿汉式：在类加载的时候就已经创建好实例，不存在多线程并发访问的问题。 2.懒汉式：在类加载的时候不创建实例，当调用 getInstance 方法的时候才判断实例是否存在，如果不存在才创建实例，存在就返回已有的实例。此种方式需要考虑线程安全问题。
抽象工厂模式是一种创建型的工厂模式，它提供了一个接口，使客户端可以在不指定具体产品的情况下创建多个产品组中的产品对象。当存在多个抽象角色时，抽象工厂模式可以用来创建一个工厂，该工厂能够根据需要生成相应类型的产品。这种模式将产品的生成和使用解耦，使得客户端无需了解具体产品的实现细节。 抽象工厂模式的核心思想是将工厂封装成了一个抽象接口，通过这个接口来创建产品。它允许客户端通过调用抽象工厂的接口来生成多个产品族中的产品对象，而无需知道每个产品族的实现细节。抽象工厂模式适用于存在多个产品族的情况，这些产品族具有不同的实现，但是客户端需要使用多个产品族中的产品。通过使用抽象工厂模式，客户端可以灵活地使用不同的产品族，而无需对代码进行大量修改。
工厂方法模式是一种类创建型模式，它定义了一个用于创建对象的接口，让子类决定将哪一个类实例化。工厂方法模式简称为工厂模式，又可称为虚拟构造模式或多态工厂模式。 在工厂方法模式中，抽象产品是定义产品的接口，它是工厂方法模式所创建对象的超类型，也就是产品对象的公共父类。具体工厂是抽象工厂的子类，实现了抽象工厂中定义的工厂方法，并可由客户端调用，返回一个具体产品类的实例。 基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够让工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节完全封装在具体工厂内部。所有的具体工厂类都具有同一个抽象父类。
UML类图看和画其实很简单，看懂就更简单了：第一，简单了解一下UML类图是干什么用的； 第二了解一UML类图的主要描述对象是什么； 第三，UML类图描述的对象之间有哪些关系；最后，了解一下，这些关系怎么用图形化的符号来描述它。类是具有相似结构，属性和行为的一组对象的统一描述，UML类图就是用一系列如箭头，实线，虚线等图形符号来描述类之间关系的图形。行话说，一图胜千言，在实际业务设计开发过程中，清晰的UML类图可以快速让我们搞清楚类之间的关系，也方便于沟通交流。
实际业务开发中，集合的判断和操作也是经常用到的，Spring也针对集合的判断和操作封装了一些方法，但是最令我惊讶的是，我在梳理这些内容的过程中发现了一些有趣的现象，我的第一反应是不敢相信，再想一想，没错，我是对的。所以强烈建议大家可以认真看完这篇文章，这一篇绝对有价值，因为有趣的是我我竟然发现了Spring的两个bug。
在实际的业务开发中，除了经常有针对对象的判断或操作以外，经常也会遇到的就是字符串的判断和操作。比如判断字符串是否为空、是否以某个字符结尾、去除头部和尾部的空白字符、字符的查找和替换。在Spring的核心包中存在这样一个类org.springframework.util.StringUtils，它提供了常见的关于字符串的判断和操作的静态方法。下面咱们针对一些常见的一块学习一下，顺便再把前面说的断言给复习一下：
Spring内置的工具类里，最喜欢用的就是文件读写这一部分，虽然原生的写法也没几句，但是就是懒，不想循环、判断什么的，直接调用现成的静态方法，多高效，哈哈，这就是懒人必备。
简单工厂模式是一种属于创建型模式的设计模式，又叫做静态工厂方法（Static Factory Method）模式。简单工厂模式的核心是一个工厂类，它负责实现创建所有产品实例的内部逻辑。这个工厂类提供了一个或多个静态的工厂方法，根据参数的不同返回不同类的实例。这些被创建的实例通常都具有共同的父类。
ReflectionUtils应该是Springboot内置工具类梳理的最后一篇了，可以很多人都没有听说过这个工具类。这个类封装的是一些与java反射相关的静态工具方法，可能很多人知道反射，却不怎么经常使用反射。其实反射是一个很用的技术点，我认为是可以和AOP比肩的，甚至有过之而不及。大家都知道AOP是面向切面编程，可以在定义的切面前、后执行一些操作，但是反射更厉害，它可以在程序运行时，对已装载的任意类的属性和方法进行操作，这就是java的反射机制。
在实际业务开发中，有时候经常需要判断对象是否为空、数组是否为空、两个对象是否相等，数组中是否包含某个元素，往数组中追加元素等这些操作，每次都手写太麻烦，然后很多人的选择是封装成util工具类，实际上类似这些东西，如果项目使用了spring的框架，根本不需要封装，org.springframework.util.ObjectUtils类中已经封装好了各种的静态方法供你调用。那就一起来学习一下吧。
程序员如何提高代码能力？个人认为代码能力比较强的程序员应该具备良好的编码习惯并可以输出高质量的代码实现的特征。那么程序员如何提高代码能力的问题，就变成了怎么才能成为一个具备良好编码习惯并可以输出高质量代码实现的程序员。其实很简单，首先，要知道高质量的代码具备哪些特性，良好的编码习惯有哪些，然后就是如何在编码过程中满足这些特性，并通过有意识的训练养成好的编码习惯。
可以这么理解断言：在输出结果后，对结果集定义一个期望值，如果满足了期望值，则正常通过断言；如果不满足期望值，则会触发断言，触发断言的结果就是会抛出一个IllegalArgumentException异常，这个异常属于运行时异常。最后，再搞一个异常的统一处理，简直不要太完美。 另外断言肯定不止这几个，这里只是对用到频率比较高的作一个抛砖引玉，更多更好玩的断言使用可以从org.springframework.util.Assert类探索一翻。
要知道设计模式就是软件工程的方法经验的总结，也是可以认为是过去一段时间软件工程的一个最佳实践，要理解，不要死记硬背。掌握这些方法后，可以让你的程序获得以下好处： • 代码重用性（相同功能的代码，不用多次编写） • 可读性（编程规范性，便于其他程序员的阅读和理解） • 可扩展性（当需要增加新的功能时，非常的方便，称为可维护） • 可靠性（当我们增加新的功能后，对原来的功能没有影响） • 使程序呈现高内聚，低耦合的特性。 当然设计是有限度的，不能无限的考虑未来的变更情况，否则就会陷入设计的泥潭而无法自拔。方法是死的，人是活，用的时候一定灵活运用，才能发挥它的作用。设计模式中六大设计原则，这些原则可以认为是设计模式的灵昏。下面先对六大设计原则简单梳理一下，然后再详细分析每一个设计原则。
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
