网络信息存储场景是否适配桥接设计模式？有没有更适配的设计方案？

答复 #

现有实现的合理性 #

你写的这段代码功能上完全可用，确实实现了不同网络类型对应不同网络信息结构的需求，也通过公共接口约束了所有网络信息必须携带ipv4Cidr字段，没有逻辑错误。

桥接模式的使用判断 #

你确实对桥接模式的概念有误解：
桥接模式的核心是拆分抽象和实现两个独立变化的维度，让二者可以各自扩展互不干扰。比如你有「日志输出渠道（文件、控制台、远程）」和「日志级别（调试、信息、错误）」两个完全独立的扩展维度，才需要用桥接模式。
你这个场景里只有「网络信息结构」这一个可变维度，当前的写法就是普通的多态实现，和桥接模式没有关系。

更适配的方案 #

你用的是Kotlin，密封接口（sealed interface） 是这个场景的最优选择，比你现在用的普通接口适配性高很多：

sealed interface NetworkInfo {
    val ipv4Cidr: String
}

data class BridgeNetworkInfo(
    override val ipv4Cidr: String,
    val bridgeIP: List<String>
) : NetworkInfo

data class PeeringNetworkInfo(
    override val ipv4Cidr: String,
    val customerIP: String,
    val organizeIP: String
) : NetworkInfo

// PatrickNetwork可以保留networkType也可以删掉，建议加构造校验避免类型不匹配
data class PatrickNetwork(
  @Id
  val networkId: String,
  val name: String,
  val description: String,
  val vlan: Int,
  val networkType: NetworkType,
  val networkInfo: NetworkInfo
) {
    init {
        // 构造时校验类型匹配，避免非法实例
        require(
            (networkType == NetworkType.BRIDGE && networkInfo is BridgeNetworkInfo)
            || (networkType == NetworkType.PEERING && networkInfo is PeeringNetworkInfo)
        ) {
            "networkType与networkInfo类型不匹配"
        }
    }
}

用密封接口的好处很明显：

• 编译器会限制NetworkInfo的实现类只能是你定义的这两种，后续你用when分支判断类型的时候不需要写兜底的else，漏写类型直接编译报错，减少运行时问题
• 配合构造校验可以彻底避免networkType和networkInfo类型不匹配的问题

如果后续你需要对不同类型的NetworkInfo做统一处理（比如参数校验、序列化转换），可以搭配访问者模式使用，把处理逻辑和数据结构解耦，不用每次加逻辑都修改数据类本身。

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