优快云_LiMingfly的博客

除了推广营销以外，确实有很多人的视频讲解非常优秀，例如李永乐老师的短视频课，可以在一个黑板上把那么复杂的知识，讲解的那么容易理解，那么透彻。比如：不同类型的交易方式(信用卡、支付宝、微信)、生成唯一ID策略(UUID、DB自增、DB+Redis、雪花算法、Leaf算法)等，都可以使用策略模式进行行为包装，供给外部使用。以上的策略模式案例相对来说并不复杂，主要的逻辑都是体现在关于不同种类优惠券的计算折扣策略上。结构相对来说也比较简单，在实际的开发中这样的设计模式也是非常常用的。这也是方法的不好扩展性问题。

但在高体量、高并发的业务场景下，每一次的压测优化，性能提升，都像在研究一道数学题一样，反复的锤炼，压榨性能。不断的深究，找到最合适的设计。这样的案例场景在实际的业务开发中其实不多，因为这是将这种思想运用在中间件开发上，而很多小伙伴经常是做业务开发，所以对Spring的bean定义以及注册和对代理以及反射调用的知识了解的相对较少。2：使用过的一些中间件例如；RPC框架，在拿到jar包对接口的描述后，中间件会在服务启动的时候生成对应的代理类，当调用接口的时候，实际是通过代理类发出的socket信息进行通过。

不改变原有类，可能有的小伙伴会想到继承、AOP切面，当然这些方式都可以实现，但是使用装饰器模式会是另外一种思路更为灵活，可以避免继承导致的子类过多，也可以避免AOP带来的复杂性。就像夏天热你穿短裤，冬天冷你穿棉裤，雨天挨浇你穿雨衣一样，你的根本本身没有被改变，而你的3：需求却被不同的装饰而实现。2：装饰器实现的重点是对抽象类继承接口方式的使用，同时设定被继承的接口可以通过构造函数传递其实现类，由此增加扩展性并重写方法里可以实现此部分父类实现的功能。1：抽象构件角色(Component) - 定义抽象接口。

那么这个时候你就可以使用组合模式进行构建服务，对于不同类型的调用方配置不同的组织关系树，而这个树结构你可以配置到数据库中也可以不断的通过图形界面来控制树结构。但这样的不考虑扩展性的实现，很难让后续的需求都快速迭代，久而久之就会被陷入恶性循环，每天都有bug要改。1：从以上的决策树场景来看，组合模式主要解决的是一系列简单逻辑节点或者扩展的复杂逻辑节点在不同结构的组织下，对于外部的调用是仍然可以非常简单的。除了我们说的扩展性和每次的维护以外，这样的代码实现起来是最快的。而且从样子来看也很适合新人理解。

2：从桥接模式的实现形式来看满足了单一职责和开闭原则，让每一部分内容都很清晰易于维护和拓展，但如果我们是实现的高内聚的代码，那么就会很复杂。所以在选择重构代码的时候，需要考虑好整体的设计，否则选不到合理的设计模式，将会让代码变得难以开发。很多时候你写出来的ifelse都是没有考虑使用设计模式优化，就像：同类服务的不同接口适配包装、同类物料不同组合的建造、多种奖品组合的营销工厂等等。1：模拟微信与支付宝两个支付渠道在不同的支付模式下，刷脸、指纹、密码，的组合从而体现了桥接模式的在这类场景中的合理运用。

那么这个时候做这样一个系统就会接收各种各样的MQ消息或者接口，如果一个个的去开发，就会耗费很大的成本，同时对于后期的拓展也有一定的难度。使得用户方便使用，就像我们提到的万能充、数据线、MAC笔记本的转换头、出国旅游买个插座等等，他们都是为了适配各种不同的口，做的兼容。这个类里的方法非常重要，主要用于把不同类型MQ种的各种属性，映射成我们需要的属性并返回。2：尤其是我们对MQ这样的多种消息体中不同属性同类的值，进行适配再加上代理类，就可以使用简单的配置方式接入对方提供的MQ消息，而不需要大量重复的开发。

B:使用CAS的好处就是不需要使用传统的加锁方式保证线程安全，而是依赖于CAS的忙等算法，依赖于底层硬件的实现，来保证线程安全。相对于其他锁的实现没有线程的切换和阻塞也就没有了额外的开销，并且可以支持较大的并发性。目前此种方式的单例确实满足了懒加载，但是如果有多个访问者同时去获取对象实例你可以想象成一堆人在抢厕所，就会造成多个同样的实例并存，从而没有达到单例的要求。以上这种方式在我们平常的业务开发中非常常见，这样静态类的方式可以在第一次运行的时候直接初始化Map类，同时这里我们也不需要到延迟加载再使用。

原型模式主要解决的问题就是创建大量重复的类，而我们模拟的场景就需要给不同的用户都创建相同的试卷，但这些试卷的题目不便于每次都从库中获取，甚至有时候需要从远程的RPC中获取。但从一部分可以上机考试的内容开始，在保证大家的公平性一样的题目下，开始出现试题混排更有做的好的答案选项也混排。这个这个工具类的操作就是将原有Map中的选型乱序操作，也就是A的选项内容给B，B的可能给C，同时记录正确答案在处理后的位置信息。两个append()，对各项题目的添加，有点像我们在建造者模式中使用的方式，添加装修物料。

一个项目的上线往往要经历业务需求、产品设计、研发实现、测试验证、上线部署到正式开量，而这其中对研发非常重要的一环就是研发实现的过程，又可以包括为；一级&二级吊顶、多乐士涂料、圣象地板、马可波罗地砖等等，按照不同的套餐的价格选取不同的品牌组合，最终再按照装修面积给出一个整体的报价。无论承接什么样的需求，是不是身边总有那么几个人代码写的烂，但是却时常有测试小姐姐过来聊天(求改bug)、有产品小伙伴送吃的(求写需求)、有业务小妹妹陪着改代码(求上线)，直至领导都认为他的工作很重要，而在旁边的你只能蹭点吃的。

那么这个设计模式满足了；并且这里还有一点非常重要，由于集群A和集群B在部分方法提供上是不同的，因此需要做一个接口适配，而这个适配类就相当于工厂中的工厂，用于创建把不同的服务抽象为统一的接口做相同的业务。A:在代理类的实现中其实也非常简单，通过穿透进来的集群服务进行方法操作另外在invoke中通过使B:用获取方法名称反射方式，调用对应的方法功能，也就简化了整体的使用。研发自我能力的提升远不是外接的压力就是编写一坨坨代码的接口，如果你已经熟练了很多技能，那么可以在即使紧急的情况下，也能做出完善的方案。

但这样也会带来一些问题，比如有非常多的奖品类型，那么实现的子类会极速扩张。由于营销场景的复杂、多变、临时的特性，它所需要的设计需要更加深入，否则会经常面临各种紧急CRUD操作，从而让代码结构混乱不堪，难以维护。这种设计模式也是 Java 开发中最常见的一种模式，它的主要意图是定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。A:从上面可以看到每一种奖品的实现都包括在自己的类中，新增、修改或者删除都不会影响其他奖品功能的测试，降低回归测试的可能。