我们正在重建我们的产品,并在短期内做出许多关键决策.

在做我自己的一些工作时,我注意到我们有一些内部的C类来抽象一些POSIX API(线程,互斥,信号量和rw锁)和其他实用程序类.请注意,这些类是基本的,并且尚未从Linux移植(可移植性是重建的一个因素.)我们也使用POCO C库.

我把它引起了我的同事的注意,并建议我们放弃我们的内部课程以支持他们的POCO等价物.我想充分利用我们已经使用的库.他们建议我们应该使用POCO实现我们的内部类,并根据需要进一步抽象出额外的POCO类,以便不依赖于任何特定的C库(引用未来的未知数 – 如果我们想要使用不同的lib /框架,那该怎么办？ QT或提升,如果我们选择的那个结果不好或开发变得不活跃,等等.)

他们也不想重构遗留代码,并且通过使用我们自己的类抽象POCO的部分,我们可以实现其他功能(经典OOP.)我可以理解这两个参数.但是,我认为,如果我们正在进行重新编码,我们应该变大,或者回家.现在是重构的时候了,它确实不应该那么糟糕,特别是考虑到我们的类和POCO(线程等)之间的相似性我不知道对于第二点说什么 – 我们应该只使用需要功能的扩展类？

我的同事也不想在整个地方乱丢POCO命名空间.我认为我们应该选择一个库/框架/工具包,并坚持下去.充分利用其功能.这不是典型的做法吗？我见过的唯一一个抽象整个框架的项目是Freeswitch(它为APR提供了自己的接口.)

一个建议是我们彼此暴露的API和潜在客户应该没有POCO,但它会出现在实现中(这是有意义的.)

我们中没有人真正拥有这些设计决策的经验,并且它在当前的产品中显示出来.从我年轻的时候就一直在这里,我有一些直觉让我来到这里,但也没有实际经验.我真的想避免解决已经解决的问题.

我认为我的问题归结为：在构建产品时,我们是否应该a)选择一个支配大部分代码的主导框架,以及b)期望该框架与产品紧密结合？这不是框架的重点吗？ (框架或库是否更适合POCO？)