2020年11月_贤子磊

原创设计模式详解（二十二）——备忘录模式

一、场景问题某手游公司经营一款中国象棋游戏，在用户的反馈中发现一些用户由于屏幕操作失误经常出现下错棋的情况，但是系统并未提供撤销的功能，现需要设计一套撤销的功能可以回退棋子状态可以取消回退请设计一条切实可用的程序。二、传统解决方案一种解决思路就是每个棋子对象存储自己走过的快照信息，根据不同的时间恢复到指定的状态。这种方式简单可行，但是过多的信息混合到实体对象中，导致对象臃肿，违背单一职责原则。针对这种情况，我们可以进行指责分离，抽出一个单独的备忘录来优化。这就引出了本文的主题——备忘录模式。

2020-11-12 18:52:37 326

原创设计模式详解（二十一）——访问者模式

一、场景问题某公司人事部门和财务部门都会处理员工的基础数据。财务部门：会访问员工的薪水情况人事部门：会访问员工的出勤情况员工分为正式员工和临时工二、传统解决方案定义抽象部门接口，财务部门和人事部门为其实现子类，分别在各自的类中处理逻辑，这种方式也能很方便解决问题，至于访问者模式，会导致代码抽象，晦涩难懂，不建议使用访问者模式。下文仅仅作为模式的案例展示。三、模式剖析1、模式定义访问者模式(Visitor Pattern)：将作用于某种数据结构中的各元素的操作分离出来封装成独立的类，使

2020-11-10 19:22:12 242

原创设计模式详解（二十）——迭代器模式

一、场景问题在激烈的市场竞争中，为了提高自己的硬实力，A公司和B公司决定合并。现在目前二者的员工信息都存放在不同的数据库中，且存储的方式不同，请设计出统一的读取所有员工（A、B公司之和）信息的接口。为了简化问题，假定A公司使用List集合存储员工信息B公司使用数组存储员工信息二、传统解决方案最直观的做法是分别查询出来二者的员工数据，采用其中一种格式转化为另一种格式的方式来遍历读取。这种方式处理起来最简单，也最容易理解，但是没有考虑以后的扩展性。如果新增一种采用另外的数据结构存储用户信息，需要

2020-11-10 18:55:11 289

原创设计模式详解（十九）——中介者模式

一、场景问题设计一套买房与卖房的交互程序。二、传统解决方案最直观的做法是定义卖方和买方的实体，二者直接进行信息交互。但是随着买方和卖方的人数新增，实体之间的交互会变得错综复杂，直接交互的设计方案会导致系统的通信链路交错复杂，且实体之间耦合过多，维护困难。因此我们可以采用中间层（中介）的方式来简化交互流程。即每个客户都只与中介交互，由中介来负责传递消息，使得各个实体间解耦，较少交互上的不便性。（即现在的房地产中介公司，当然缺点就是增加了中介费）。三、模式剖析1、模式定义中介者模式(Mediato

2020-11-09 19:53:48 334 2

原创设计模式详解（十八）——观察者模式

一、场景问题设计一套报纸发布/订阅的程序设计报亭：发布内容，并分发到各个订阅者读者：订阅报纸，也可取消订阅二、传统解决方案一种解决方式是报刊只负责生产报纸，发布内容。由各个订阅者自己去报亭拿自己的报纸。这种方式会导致各个订阅者需要不间断地轮询报亭取报纸，造成资源的浪费。所以这类问题一般会采用观察者模式来实现。三、模式剖析1、模式定义观察者模式(State Pattern)：指多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这种模式有

2020-11-04 18:50:58 331

原创设计模式详解（十七）——状态模式

一、场景问题某银行需要设计一套信用卡账户管理系统，其中账户大约分为三种状态正常状态账户余额大于等于0，即不存在欠款情况。此时用户可以存款，也可以取款。透支状态账户余额小于0，且欠款金额小于5000。用户可以存款，也可以取款。受限状态账户的欠款金额大于等于5000，用户无法继续取款，仅仅能够存款。请设计一套可用的信用卡账户存钱取款程序。二、传统解决方案1、解决思路每次存款取款校验状态判断是否可操作代码展示账户类public class Account {

2020-11-03 19:07:56 328

原创设计模式详解（十六）——职责链模式

一、场景问题某公司决定设计一套线上的费用报销的审核机制，其中金额在1000以内只需要由项目经理审批即可金额在1000~5000则需要由部门经理审批金额大于5000则必须由总经理审批请设计一套程序实现上述逻辑二、传统解决方案1、解决思路根据不同的金额走不同的审批分支代码展示报销单实体public class FeeForm { /** * 报销单号 */ private Integer id; /** * 报销金额

2020-11-02 19:35:55 183

weixin_41951205的博客