我们正在使用其他人提供的图书馆.最近由于该库的变化,我们的项目有500个错误.迁移到新库时,我们发现只有15个API失败,500个错误重复(这15个错误的倍数出现,因为同一次调用被多次使用).
因此,对于迁移,我建议创建另一个内部静态包装类,它包装那些库API调用.因为如果要再次更改库,我们将需要更少的代码来进行更改,因此将来代码变得更容易维护.而且通过包装调用,我们可以避免人为错误(或非预期的(重载的)API使用).
但是这里的一些人,没有看到另一个包装类的重点,他们认为这是完全没必要的.他们争论的唯一的一点是,由于大多数API的变化只是一个衬里,我们可以使用CTRL + H(查找和替换)经常改变它们.而且他们也说,我建议这种额外的抽象,带走了可读性(因为它背后隐藏的另一种方法的名称(即使有意义的)实际API调用)的编码器/读写器.
什么是最好的方法？我的建议错了吗？
使用自定义包装器包装不稳定的API和库是一种相对常见的做法.例如,一个常见用途是将该库的例外转换为您的例外术语.
更一般地说,这些包装器被称为适配器,虽然适配器(IMHO)更多的意思是提供一方所需的功能,同时隐藏另一方的确切"语言",而不是因为另一方不稳定.
你提到静态的使用 - 我通常不是使用它们的忠实粉丝.恕我直言,有时候有一个界面代表你需要的功能,然后在这些子类型中的一个使用第三方库时具有该界面的子类型.这样做的好处是,有一天可以切换到另一个供应商,而无需更改系统中的每个调用.
无论哪种方式,你通常都在正确的轨道上.恕我直言,任何认为CTRL-H是一个有效的重构工具的人都在寻找麻烦.他们至少在代码中使用getter和setter(如果适用)吗？
此外,可读性部分对我来说还不清楚.具有可读名称的适配器与具有可读名称的原始API一样好.
| 归档时间： |
|
| 查看次数： |
377 次 |
| 最近记录： |