c – 通常的做法是从实现中抽象库依赖项吗？
|
我对这个问题的回答是“不”.但我的同事不同意.
我们正在重建我们的产品,并在短期内做出许多关键决策. 在做我自己的一些工作时,我注意到我们有一些内部的C类来抽象一些POSIX API(线程,互斥,信号量和rw锁)和其他实用程序类.请注意,这些类是基本的,并且尚未从Linux移植(可移植性是重建的一个因素.)我们也使用POCO C库. 我把它引起了我的同事的注意,并建议我们放弃我们的内部课程以支持他们的POCO等价物.我想充分利用我们已经使用的库.他们建议我们应该使用POCO实现我们的内部类,并根据需要进一步抽象出额外的POCO类,以便不依赖于任何特定的C库(引用未来的未知数 – 如果我们想要使用不同的lib /框架,那该怎么办？ QT或提升,如果我们选择的那个结果不好或开发变得不活跃,等等.) 他们也不想重构遗留代码,并且通过使用我们自己的类抽象POCO的部分,我们可以实现其他功能(经典OOP.)我可以理解这两个参数.但是,我认为,如果我们正在进行重新编码,我们应该变大,或者回家.现在是重构的时候了,它确实不应该那么糟糕,特别是考虑到我们的类和POCO(线程等)之间的相似性我不知道对于第二点说什么 – 我们应该只使用需要功能的扩展类？ 我的同事也不想在整个地方乱丢POCO命名空间.我认为我们应该选择一个库/框架/工具包,并坚持下去.充分利用其功能.这不是典型的做法吗？我见过的唯一一个抽象整个框架的项目是Freeswitch(它为APR提供了自己的接口.) 一个建议是我们彼此暴露的API和潜在客户应该没有POCO,但它会出现在实现中(这是有意义的.) 我们中没有人真正拥有这些设计决策的经验,并且它在当前的产品中显示出来.从我年轻的时候就一直在这里,我有一些直觉让我来到这里,但也没有实际经验.我真的想避免解决已经解决的问题. 我认为我的问题归结为：在构建产品时,我们是否应该a)选择一个支配大部分代码的主导框架,以及b)期望该框架与产品紧密结合？这不是框架的重点吗？ (框架或库是否更适合POCO？) 解决方法
首先,您公开的API绝对应该没有POCO,boost,qt或任何其他不属于标准C库的类型.这是因为基本库有自己的发布周期,与库的发布周期不同.如果您的库的用户也使用boost,但是使用不同的,不兼容的版本,则他们需要花时间来解决不兼容问题.此规则的唯一例外是当您设计要作为更广泛框架的一部分发布的库时 – 例如,POCO工具包的添加.在这种情况下,库的发布与整个工具包的发布相关联.
但是,在内部,您应该避免使用自己的包装器,除非您抽象出来的库是真正的“商品库”1.这样做的原因是,当您在类后面隐藏外部库时,大多数情况下您都会模仿您隐藏的库的抽象级别.使用您的包装器的代码将编程到外部库指定的抽象级别.当您将包装器后面的实现交换为不同的框架时,您很可能(1)调整新框架以适应旧框架的抽象级别,或者(2)需要更改方式你使用你的包装器.这两种情况都非常可疑：如果你做(1),也许你不应该在第一时间切换,如果你做(2),那么你的包装被证明是无用的. 1“商品库”是指一个库,它提供了其他库中常见的抽象级别,这些抽象级别用于类似目的. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |