Go 博客
JSON-RPC：接口的故事
在此，我们举例说明 Go 的 接口 如何轻松地重构现有代码，使其更具灵活性和可扩展性。最初，标准库的 RPC 包 使用一种称为 gob 的自定义线上传输格式。对于某个特定应用，我们想使用 JSON 作为替代的线上传输格式。
我们首先定义了一对接口来描述现有线上传输格式的功能，一个用于客户端，一个用于服务器（下图所示）。
type ServerCodec interface {
ReadRequestHeader(*Request) error
ReadRequestBody(interface{}) error
WriteResponse(*Response, interface{}) error
Close() error
}
在服务器端，我们将两个内部函数签名更改为接受 ServerCodec 接口，而不是我们现有的 gob.Encoder。这是其中一个：
func sendResponse(sending *sync.Mutex, req *Request,
reply interface{}, enc *gob.Encoder, errmsg string)
变成
func sendResponse(sending *sync.Mutex, req *Request,
reply interface{}, enc ServerCodec, errmsg string)
然后，我们编写了一个简单的 gobServerCodec 包装器来重现原始功能。从那里，构建一个 jsonServerCodec 也很容易。
在对客户端进行了一些类似的更改后，这就是我们对 RPC 包所需要做的全部工作。整个过程大约花了 20 分钟！在整理和测试新代码后，最终的更改集 已被提交。
在像 Java 或 C++ 这样的面向继承的语言中，显而易见的方法是泛化 RPC 类，并创建 JsonRPC 和 GobRPC 子类。然而，如果您想在与该层次结构正交的方向上进行进一步的泛化，这种方法会变得棘手。（例如，如果您要实现一个替代的 RPC 标准）。在我们的 Go 包中，我们采取了一条在概念上更简单且需要编写或更改的代码量更少的路线。
任何代码库的一个重要品质是可维护性。随着需求的不断变化，能够轻松、干净地适应代码至关重要，否则代码将变得难以处理。我们相信 Go 轻量级、面向组合的类型系统提供了一种可扩展的代码结构。
下一篇文章：新的讲座和教程
上一篇文章：第三方库：goprotobuf 及其他
博客索引