实现Tokenizer与Parser包低耦合的适用设计模式及方案咨询

匿名内部类实现Token的方案合理性 #

这个方案完全合理，而且是当前场景下性价比很高的实现方式，你只需要先做一个前提调整：

1. 在Parser包下单独定义自己的Token接口，只声明你需要的getValue()、getType()两个抽象方法，完全不依赖自研Tokenizer包内的任何类
2. 在TokenizerAdapter的getToken()方法中，直接返回该接口的匿名内部类实现，所有getter方法直接代理底层Tokenizer的对应方法即可，示例代码如下：

// Parser包下自有Token接口
package com.your.parser;
public interface Token {
    String getValue();
    String getType();
}

// TokenizerAdapter中的实现
@Override
public Token getToken() {
    // 直接代理自研Tokenizer的当前值，不需要复制属性生成新对象
    return new Token() {
        @Override
        public String getValue() {
            return internalTokenizer.getCurrentValue();
        }

        @Override
        public String getType() {
            return internalTokenizer.getCurrentType();
        }
    };
}

这种实现的优势很明显：

• 完全切断Parser和自研Tokenizer Token类的耦合，Parser拿到的永远是自有包下的Token接口实例，完全感知不到底层Tokenizer的实现细节
• 没有额外的属性复制开销，只是做了一层轻量调用代理，性能比重新构造Token对象更好
• 后续换其他开源Tokenizer时，只需要在对应Adapter里用同样的方式实现Token代理即可，Parser层的代码不需要做任何修改

其他可参考的设计模式与设计原则 #

• 适配器模式：你当前的TokenReceiver+TokenizerAdapter结构就是适配器模式的标准实现，核心作用就是将不同第三方实现的异构接口，转换成你自己定义的统一抽象接口，保证上层逻辑不需要跟着底层依赖的变化调整
• 代理模式：上文提到的匿名内部类Token实现就是静态代理的简化用法，通过代理类封装对底层对象的访问，隔离上层和底层实现的直接依赖
• 依赖倒置原则：这是解耦的核心设计原则，要求高层模块（Parser）只依赖自己定义的抽象接口（TokenReceiver、Parser包的Token接口），不依赖任何具体实现类，所有具体实现的对接逻辑全部下沉到适配层处理
• 额外提个小优化：你当前贴出的TokenReceiver接口重复定义了两次getToken()方法，属于代码笔误，记得清理删除重复声明。

内容的提问来源于stack exchange，提问作者bitcasual