大多数情况下你不需要访问者模式，但当一旦需要访问者模式时，那就是真的需要它了，这是设计模式创始人的原话。可以看出应用场景比较少，但需要它的时候是不可或缺的，这篇文章就开始学习最后一个设计模式——访问者模式。一、概念理解访问者模式概念：封装作用于某对象结构中的各元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。通俗的解释就是，系统中有一些固定结构的对象(元素)，在其内部提供一个accept()方法用来接受访问者对象的访问，不同的访问者对同一元素的访问内容不同，所以使得相同的元素可以产生不同的元素结果。比如在一个人事管理系统中，有多个工种的员工和多个老板，不同的老板对同一

在我们实际开发中，如果一个方法极其复杂时，如果我们将所有的逻辑写在一个方法中，那维护起来就很困难，要替换某些步骤时都要重新写，这样代码的扩展性就很差，当遇到这种情况就要考虑今天的主角——模板方法模式。一、概念理解模板方法模式的概念很简单，在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。既然概念叫“骨架”，那想当然的就是定义一个抽象类，这是模板方法模式的第一个角色——抽象模板角色，要有延迟子类实现骨架方法，这是模板方法的第二个角色——具体模板角色。抽象模板角色：定义了一个或多个抽象操作，以便让子类实现。这些抽象操作

在一个收银系统中，如果普通用户、中级会员、高级会员分别对应着不同的优惠策略，常规编程就要使用一系列的判断语句，判断用户类型，这种情况下就可以使用策略模式。一、概念理解策略模式的概念很好理解，它将对象和行为分开，将行为定义为一个行为接口和具体行为的实现，每个if判断都可以理解为一个策略。如果在收银系统中使用策略模式，要将普通、中级、高级会员分别定义一个具体策略类，并实现各自的方法，定义一个环境类，持有策略类的引用，由引用调用相应的策略类方法，客户端传入相应的具体策略对象就会调用各自的策略方法。学过了状态模式，很多人也把状态模式和状态模式搞混，现在就可以考虑一下为什么不使用状态模式？各个策略之间并

实际开发中订单往往都包含着订单状态，用户每进行一次操作都要切换对应的状态，而每次切换判断当前的状态是必须的，就不可避免的引入一系列判断语句，为了让代码更加清晰直观，我们引入今天的主角——状态模式。一、概念理解假设订单状态有，下单、发货、确认收货，如果用户确认收货，在常规编程中就要判断当前用户的状态，然后再修改状态，如果这种情况下使用状态模式。将各个状态都抽象成一个状态类，比如下单状态类、发货状态类、确认收货类，在状态类中处理相应的逻辑和控制下一个状态，在定义一个环境类，定义初始状态，并控制切换状态。在状态模式中应该包含着三个角色：环境类（Context）角色：也称为上下文，它定义了客户端需要的