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