Fatal编程技术网
  • build/
  • Build 如果可执行文件依赖于另一个依赖项已经使用的库，这是一种不好的做法吗？

Build 如果可执行文件依赖于另一个依赖项已经使用的库，这是一种不好的做法吗？

build

Build 如果可执行文件依赖于另一个依赖项已经使用的库，这是一种不好的做法吗？,build,shared-libraries,static-libraries,Build,Shared Libraries,Static Libraries,我当前的项目有两个库libAAA和libBBB。 前者，libAAA，包含我的项目的基本数学和机制（例如国际象棋规则）。后者，libBBB，依赖于libAAA，但添加了GUI元素（例如单个图形的绘制方式） 可执行文件取决于，libAAA和libBBB。例如，libBBB用于设置国际象棋游戏，而libBBB用于定义其外观（控制台、qt、gtk等） 有这样的冗余依赖关系是可以的，还是可能是不好的做法 编辑： 我这样问是因为我喜欢将GUI表示与机制解耦是多么容易。例如，如果我想更改外观或工具包，我可以

我当前的项目有两个库
libAAA
和
libBBB
。 前者，
libAAA
，包含我的项目的基本数学和机制（例如国际象棋规则）。后者，
libBBB
，依赖于
libAAA
，但添加了GUI元素（例如单个图形的绘制方式）

可执行文件取决于，
libAAA
和
libBBB
。例如，
libBBB
用于设置国际象棋游戏，而
libBBB
用于定义其外观（控制台、qt、gtk等）

有这样的冗余依赖关系是可以的，还是可能是不好的做法

编辑： 我这样问是因为我喜欢将GUI表示与机制解耦是多么容易。例如，如果我想更改外观或工具包，我可以添加
libHHH
，创建另一个可执行文件，就这样。

这很好

让我们看看一些替代方案：

  • 将所有代码从
    libAAA
    拉入
    libBBB
    ：如果
    libAAA
    不打算在其他上下文中使用，并且它们各自的大小允许以实用的方式进行此操作，则这是正常的。但是，在许多情况下，例如，如果
    libBBB
    大得多，并且
    libAAA
    是许多项目的一个小型可重用库，独立于
    libBBB
    中使用的UI框架，这将不起作用

  • 将
    libBBB使用的代码直接复制到其中：请不要。这意味着两个独立的库做了很多相同的事情，将来有两个地方需要更新，将来会给你或任何试图理解它的人带来更多的困惑，等等
  • 将
    libBBB
    代码引入应用程序本身    ：这并不总是可行或实用的，具体取决于您的开发堆栈和环境。出于性能或其他原因，许多应用程序可能还需要使用不同语言编程和编译的库

    • 我可能错过了几个其他的选择，但是在冗余的情况下保持这两个依赖似乎是我最好的选择

    正如您在编辑中所述，这还允许您将
    libBBB
    替换为另一个同样使用
    libAAA
    （或另一个库，如果需要的话）的UI库，而无需删除任何核心应用程序代码或使依赖项中的任何其他代码无效