@assiadamo 那我基本确定了，你可能没太理解 interface 的本质 Go 里的 interface 就是为你说的这种应用场景准备的 你不需要给每个协议都生成一个 Process ， 只需要定义个 interface ，再定义单独一个 Process ，用这个 interface 当参数类型 然后在框架里给每个协议定义好 interface 需要用到的方法就行 这样就是业务完全不需要管框架里怎么实现 Process ， 直接定义一个协议结构体变量，然后 Process 它即可

我曾经也这么想过，后来彻底理解了组合优于继承之后，就再也没动过这个念头 真的，抛弃继承吧，仔细想想，你只是为了要其中的几个函数而已，组合个 interface 就可以了，没必要要求依赖那个 struct

@povsister 我理解 register 需要开发者自己做，就兴趣缺缺

@povsister 我预想的使用方式是开发者定义好协议，这个协议可能带 package 信息，然后 go generate ，所有的模板都生成好了，开发者只需要打开一个生成的 go 文件写业务代码就行

@NessajCN 我理解一下，如果有代码例子就更好了

@assiadamo #23 你这才叫毒瘤… 改 go generate 代码真不是碳基生物能想的活，不要滥用 generate 和开发脚手架。

注入一个 process interface 就好了...

@povsister 因为以前用过这样的框架，觉得用起来非常爽，现在也算是体验到了框架开发者的心情

我有两个想法： - 编译时方案，可以交给外部 preprocessor 当作模板来处理，后续代码生成之后再用 Go 编译，当然这个外部工具也可以用 go 写。目前来看基本上都要用特定的模板写法，而不是 Go 代码。 - 运行时方案，理论上这个需求和 hot reloading 应该差不多，对于 JIT 来说是比较好实现的，对于 Go 应该比较难。像 C 没有 runtime 是可以做到的，如果 Go 要实现类似的功能我估计需要魔改 runtime 才行。

@assiadamo 譬如我现在定义两个 struct, 或者按你的说法是协议 type EncStr struct { Raw string Encoded string } type DecStr struct { Encrypted string Decoded string } 我要在业务里 Process 他俩，譬如打印出人能看到的信息，也就是在 EncStr 里的 Raw 或 DecStr 里的 Decoded 那我在业务里先定义一个 interface type Protocol interface { Print() } 再定义一个 func Process(p Protocol) { p.Print() } 这时候业务里只有他俩就够了 回到前面定义协议的地方，加上下面的内容 func (e *EncStr)Print() { fmt.Println(e.Raw) } func (d *DecStr) Print() { fmt.Println(d.Decoded) } 然后你在业务里调用 Process 函数就行了 https://go.dev/play/p/IaPb1GktEsS