什么是设计模式?
一些经验总结的最佳实践!
是不是必须要用?
并不是,但是既然已经说是最佳实践了,该用的地方,你不用,就有些违背常理了。
这个或许是最最最常见,也是最最最常用的了。
为什么要用单例模式?
因为只需要一个对象就够了(有时候只能有一个,有时候是不需要有多个)。
对象的创建和销毁也是成本。
比如,你要发 kafka 消息,你要创建一个 Producer 对象,因为是 Producer 线程安全的,所以一般创建一个对象就够了。
借用官方的一个建议:
Spring 容器管理的对象默认创建模式为单例。当然你也可以根据实际业务对不同的对象设置不同的创建模式。
singleton: (Default) Scopes a single bean definition to a single object instance for each Spring IoC container.
需要说明的是,这个单例只是针对一个容器。
使用 Guava 本地缓存来加速业务响应。这个对于一个业务模块也只需要创建一个,否则就会发生混乱了。
grpc 的线程池。
门面模式或者也叫外观模式。
意在屏蔽复杂性,通过一个简洁的门面与外界进行交互。
比如,另外一个客服系统需要调取系列的用户信息,包括基本信息,注册、登录信息,粉丝、关注信息,认证信息等等。
对于业务组来说,可能每一项都有现成的接口输出。
但是,如果直接将这么老多接口直接丢出去,似乎也显得有些不合适:信息整合容易出问题;繁多的接口交互浪费网络资源,影响业务响应时延,也容易破坏信息展现的完整性。
这里就可以将所需的不同信息接口逻辑进行整体的封装,输出一个单一的功能接口来做门面接口。
Channel是一个接口,而且是一个很大的接口,我们称之为“大而全”,囊括了server端及client端接口所需要的接口。
Channel是一个门面,封装了包括网络I/O及相关的所有操作。
Channel聚合了包括网络读写、链路管理、网络连接信息、获取EventLoop、Pipeline等相关功能类;统一分配,调度实现相应场景的功能。
BeanDefinitionLoader 用于从底层资源加载 bean 定义信息,包括 xml、JavaConfig。
是基于 AnnotatedBeanDefinitionReader、XmlBeanDefinitionReader、ClassPathBeanDefinitionScanner 的门面模式。
当对象间存在一对多关系时,则使用观察者模式(Observer Pattern)。比如,当一个对象被修改时,则会自动通知它的依赖对象。观察者模式属于行为型模式
用户信息修改后刷新整体缓存。
为什么使用它?
首先是异步需求:同步有针对性的信息修改。整体刷新逻辑作为缓存一致性数据保障不应该占用同步业务逻辑。
其次是解耦:用户信息比较冗繁,相应的 reload 逻辑牵涉业务甚多。所以将这部分逻辑进行解耦分离。
Spring ApplicationListener 应用事件监听接口,基于标准的 EventListener 接口,观察者模式实现。
ApplicationContext 通过 ApplicationEvent 类及 ApplicationListener 接口来处理事件。容器内实现了 ApplicationListener 接口的对象能够获取任何 ApplicationEvent 发布的事件。
将军,我这里有锦囊三个,你且随身带着,路遇天门,打开锦囊一,得扣天门;路遇地门,打开锦囊二,得扣地门;路遇人门,打开锦囊三,得扣人门。
策略模式针对同一应用场景存在多种处理方式的情景。
一个公司会接很多外部短信通道,阿里、Tencent、Twilio 等。
发送方可能会指定特定的短信通道;发送手机号可能地属国内或者或外;
针对这种应用场景,就可以根据相应的入参选取不同的短信通道执行相应的发送操作。
针对不同用户风险特征,执行不同的安全级别验证。
极验验证的滑块、点选、语序、空间推理等。
Collections.sort(List list, Comparator<? super T> c)
根据传入的 Comparator 比较器对相应的列表进行排序