Java中的魔法: SPI

Java中的魔法: SPI

SPI 全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制,常用于创建可扩展、可替换组件的应用程序,是java中模块化插件化的关键。

SPI 框架包含3个基本组件:

  1. 服务接口 Service Interface
  2. 服务接口的实现类,Service Provider
  3. 服务加载器 Service Loader

Service Interface是一组定义标准的接口和类。Service Provider是服务接口的特定实现,需要实现接口,并子类化服务本身中定义的类。java.util包下的ServiceLoader类就是SPI机制的核心类,主要功能是通过相关的类加载器扫描并加载provider的jar包,并且通过反射实例化服务的实现类。服务Provider程序可以以扩展的形式安装在Java平台的实现中,也就是说,可以将provider的jar文件放置在任何常用扩展目录中,也可以通过将其jar包添加到应用程序的类路径或通过其他一些特定于平台的方式来使使用方来调用。

ServiceLoader机制允许用户在其应用程序代码保持不变的前提下扩展程序功能或者添加新功能。例如SLF4J本身只是API,日常编程中我们只需要使用LogFactory获得log实例,而不用关心底层是的日志实现框架是Logback还是Log4J;java.sql.Driver是在java中定义的标准SQL服务API,如果需要从oracal数据库切换到mysql数据库,我们的数据访问层代码不需要任何修改,只需要替换掉jdbc 驱动包即可。

JDK中包含了非常多的SPI服务功能(如servlet、邮件服务、音频服务、SQL驱动,大部分位于javax),以供不同的服务厂商或者插件商基于标准定义实现自己的方案。除了能够服务于厂商或插件商,JavaSPI 也为我们实现框架扩展提供了一个不错思路。当一个功能可能会有两种以上的实现方案时,可以在应用程序中预留出 SPI 接口,剩下的适配工作便留给了开发者,这样可以在不侵入代码的前提下,通过增删依赖来扩展框架

解密SPI

目标:实现消息推送功能,要求后期能够切换不同推送厂商的推送服务(例如极光推送、小米推送、百度推送等等)


GIT多仓库迁移合并技术方案

领导说:

​ “目前各个项目分散在不同的仓库中,不利于管理,需要将多个项目仓库合并到一个工程仓库来进行开发,要求保留各个仓库迁移前的commits 记录,最好还能对命名不规范的项目进行重命名”

恕我直言,可以实现!

Git 多仓库合并

假设要合并ABC 不同的分支到新工程X,ABC 工程作为X工程的子目录

迁移A 工程的5.0分支到新工程X的A1目录

迁移B工程的dev分支 到新工程X的B1目录

迁移C 工程的6.0分支 到新工程X的C1目录

期望:合并后的目录结构

新工程X(master分支)
.
├── A1 (原A工程的某分支)
├── B1 (原B工程的某分支)
├── C1 (原C工程的某分支)
.git
README.md


网页长截图

网页长截图

雄文十万,也挡不住管理方的删帖封号,本文就来说一下怎么通过技术的方式来保存网页内容


品牌电商如何做交叉销售组合

场景5:基于NPTB模型的交叉销售组合

NPTB模型是在已知顾客购买产品的基础上,选择顾客最有可能接受的产品对顾客进行推荐

案例:

Marry第一次购买了口红,第二次购买了睫毛膏,第三次购买了眼影粉,那么可以根据Marry的购买记录,可以给marry推送强相关的粉底


品牌电商线下导购新技术

场景6:具有客户洞察力的线下导购技术支持服务

BA: 美妆导购,可以扩展到线下导购、门店导购、线下门店中的销售人员

Clienteling零售销售人员用来根据关键客户的偏好,行为和购买数据与主要客户建立长期关系的一种技术。[1] Clienteling旨在指导员工提供更多个人和知情的客户服务[2],这可能会影响与购物频率,平均交易价值的提升以及其他零售关键绩效指标有关的客户行为。[3]从客户的角度来看,客户服务“可以在购物体验中增加一层个人风格”

案例:

Marry进入线下门店后,线下门店立刻识别和检索出Marry 资料,然后根据Marry 的客户资料、行为数据、历史交易数据,综合给出相关的商品推荐


Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×