面试题：Go语言中接口优点在实际项目中的量化体现

Question

在一个小型的Go语言微服务项目中，使用接口来实现不同数据存储方式（如内存存储和数据库存储）的切换。请分析使用接口后，在代码的可维护性、扩展性方面有哪些具体的量化提升？例如，新增一种存储方式时，代码修改行数与未使用接口时的对比等。

Answer 1

可维护性方面的量化提升

1. 代码修改行数对比：
   • 未使用接口：假设项目中有多个地方直接使用了内存存储方式，例如在业务逻辑函数 processData 中直接调用内存存储的写入函数 writeToMemory。如果要切换到数据库存储，不仅需要修改 writeToMemory 函数为数据库写入函数 writeToDatabase，还需要在所有调用 writeToMemory 的地方进行修改。若有 n 个调用点，那么需要修改的行数可能为 n + 1（1 为函数定义处）。
   • 使用接口：定义一个接口 DataStorer 包含 Write 方法，内存存储和数据库存储结构体都实现这个接口。在 processData 函数中接收 DataStorer 接口类型参数。当要切换存储方式时，只需在创建存储实例的地方修改，例如从 memStorer := &MemoryStorer{} 改为 dbStorer := &DatabaseStorer{}，修改行数为 1。所以使用接口后，新增或切换存储方式时，代码修改行数大大减少，可维护性显著提升。
2. 理解和定位问题难度：
   • 未使用接口：不同存储方式的实现代码可能分散在多个文件和函数中，当存储相关功能出现问题时，开发人员需要在众多与存储相关的代码片段中查找问题，假设项目代码文件数量为 m，涉及存储操作的文件可能有 k 个（k < m），定位问题的难度较大，时间复杂度可能为 (O(k))。
   • 使用接口：因为存储相关的操作都通过接口进行抽象，问题通常集中在接口实现处，只有 2 个（内存存储和数据库存储的接口实现）地方可能出现问题，定位问题的时间复杂度为 (O(1))，大大降低了理解和定位问题的难度，提高了可维护性。

扩展性方面的量化提升

1. 新增存储方式的代码修改行数对比：
   • 未使用接口：新增一种存储方式（如文件存储）时，需要在所有涉及数据存储的业务逻辑中添加对文件存储的判断和调用逻辑。假设业务逻辑函数有 p 个，每个函数平均需要添加 q 行代码来支持新的文件存储方式，那么总共需要添加的代码行数为 p * q。
   • 使用接口：只需要定义文件存储结构体并实现 DataStorer 接口，假设实现接口方法需要 r 行代码（一般较少），然后在创建存储实例的地方添加创建文件存储实例的代码 1 行。所以新增存储方式时，使用接口需要添加的代码行数为 r + 1，相比未使用接口，代码修改量大幅减少，扩展性更好。
2. 对现有业务逻辑的影响程度：
   • 未使用接口：新增存储方式会对现有业务逻辑产生较大影响，因为需要在业务逻辑代码中添加大量新的存储方式相关的判断和调用代码，破坏了原有业务逻辑的封装性和简洁性。
   • 使用接口：现有业务逻辑不受影响，只需要在实例化存储对象的地方进行调整，业务逻辑仍然通过接口进行调用，保持了原有业务逻辑的稳定性和封装性，扩展性得到极大提升。