0xZzzz的博客

第一次看到 State 设计模式我第一个想到的场景就是我们工作中经常会涉及到的“状态机”，State 模式确实比较适合处理“状态机”这样的场景，它可以使不同状态的处理逻辑更内聚。笔者最近的参与的项目中需要将门店的作业场景进行数字化，例如门店工作人员的日常拣货作业、定期库存盘点作业等。每个作业我们都会用状态来控制它的行为，例如“已领取”的作业不能被其他人领取和执行，已关闭的作业不能再次执行，已完成的作业会用于员工的薪水计算等等，所以针对作业的每个行为我们都需要进行状态的校验，并且要控制好状态流转：这是一

最近在开发过程中需要修改这样一段代码：InvoiceSubmitter invoiceSubmitter;if (isBizBook) { //图书业务 if (isVatInvoice) { //增值税专用发票 invoiceSubmitter = rjVatInvoiceSubmitter; } else { //增值税普通发票 invoiceS

最近在重构中用到了设计模式中的观察者模式，简单的跟大家分享一下观察者模式的原理和使用场景。在进入正题之前，先简单的介绍一下业务场景，交易系统中很重要的一个流程就是订单状态的流转，这次重构的就是订单完成的部分。 订单完成之后，要做很多的后续工作，比如通知用户、发起计费、扣点、通知相关系统等。重构之前的代码结构如下： class OrderMessageResolver implements M

最近在为系统做一个限流的小组件，采用漏桶算法，基于AOP+Semaphore实现，限流不是本文的重点，有兴趣的读者可以去查阅相关资料。在这个组件中用到了适配器模式，我们首先来看适配器模式的类图：...

装饰者模式是一个比较常用的模式，它可以在不改变原类文件和不使用继承的情况下动态地扩展一个对象的功能。现在我们遇到这样一个需求，我们要做一个智能货架系统，它可以根据门店的销量、坪效、客单价等等一些数据来展现一个智能的陈列方案，目的是门店可以通过这种陈列方式来提升商品的销量、坪效等指标。一个货架的品类是固定的，我们拿纯净水来举例，假如我们通过上面的一些数据经过算法计算分析过后为这节货架选择了娃哈哈、...

建造者模式是一种常见的设计模式，属于创建型模式，我们常见的工厂、单例、原型、包括《重构与模式》一书中提到的creation method都属于创建型模式。建造者适合用于构建复杂对象，它可以将创建和表示分离，使我们的代码可读性更好，更易于维护。在我们的实际开发中，经常会构建一些实体对象，比如，在笔者参与的交易系统中，会记录用户的每一笔支付，我们在创建支付实体对象时，通常会写出这样的代码：Paym...

模式简介策略模式是一种行为型模式，它定义一系列的算法，将每一种算法封装起来并可以相互替换使用，策略模式让算法独立于使用它的客户端应用而独立变化。策略模式适合解决当程序出现多个不同分支，而且每个分支的逻辑还比较复杂的场景。生产实践在笔者参与的交易系统中，需要支持多种支付方式，如支付宝、微信、现金、银行卡等等，每一种支付方式的处理逻辑都不通，对接的系统也不一样，所以程序中需要根据用户选择的支付方...