导出第三方库依赖项是良好的编程习惯吗？答案

【问题标题】：Is exporting third party library dependencies good programming practice?导出第三方库依赖项是良好的编程习惯吗？
【发布时间】：2015-09-08 21:51:24
【问题描述】：

我使用的是 Intellij 14，在模块设置中，有一个导出依赖项的选项。

我注意到当我编写扩展特征的对象时，当其他模块尝试使用这些对象时，我需要在模块设置中选择 export。

例如，

object SomeObj extends FileIO

需要我导出 FileIO 依赖项。

但是，如果我编写一个伴随类，在调用对象时创建一个新实例，则不再需要导出。

object SomeObject {
   private val someObject = new SomeObject()
   def apply() = someObject
}

private[objectPkg] class SomeObject() extends FileIO {}

这段代码更冗长，有点像 Scala 的单例模式。 export 使用您的模块的第三方依赖项是否很好？如果不是，我的模式是 Scala 的典型解决方案吗？

【问题讨论】：

这一切都取决于你在做什么和长期目标。完全抽象出所有实现细节（例如一些第三方库来访问文件系统或数据库）可能需要更多的努力，但并不总是必要的。
@dmitry 我认为同意你的观点。你有什么时候不需要的个人指导方针吗？
一般都涉及代码设计原则。基本上，如果您以后可以切换底层的第三方库，或者您的系统必须灵活地移植到其他一些库上——那么必须将实现隐藏在某个外观后面。通常在 java/scala 中有一组现成的接口，它们在第三方中实现，您可以将这些接口用作系统其余部分的外观的一部分。如果不是这种情况 - 您将需要自己派生接口。这个价值大家根据上下文自己估计。
根据您的情况：请记住，在 java/scala 中，您导出 names，并且如果您只想以任何方式使用您的类（扩展 FileIO）外部（您的定义代码），这意味着该类可以公开访问，并且其类型也可以导出/泄漏到外部。 Scala 应该抛出编译错误，如果某些私有类超出了它的可见性范围，所以，我不确定你将如何利用你的 SomeObject.apply。怎么样？
这只是我一直用于实用程序包的一般模式。我想我明白你所说的要点。您是否介意在下面发布您的答案，以便我将其标记为正确。

标签： scala dependencies singleton

【解决方案1】：

它们通常都涉及代码设计原则。基本上，如果您以后可能会切换底层第三方库，或者您的系统必须灵活地移植到其他一些库上 - 那么必须将实现隐藏在某个外观后面。

在 java/scala 中通常有一组现成的接口，它们在第三方中实现，您可以将这些接口用作系统其余部分的外观的一部分，总的来说它是一个java 方式。如果不是这种情况 - 您将需要自己派生接口。这个价值大家根据具体情况自行估计。

根据您的情况：请记住，在 java/scala 中您导出名称，并且如果您将在定义代码之外以任何方式使用您的类（扩展 FileIO），这意味着该类可以公开访问并且它的类型也被导出/泄漏到外面。 Scala 应该抛出编译错误，如果某些私有类逃脱了它的可见范围（所以在你的 SomeObject 的第二个版本中可能是这种情况）。

考虑这个例子：我经常在我的应用程序中使用类型安全配置库。它有方便的方法，但我通常会留出空间用于可能的分离（或者更确切地说是我自己的扩展）：

package object config {
  object Config {
    private val conf: TypeSafeConfig = ConfigFactory.load()

    def toTypeSafeConfig: TypeSafeConfig = conf
  }

  @inline implicit def confToTypeSafeConfig(conf: Config.type): TypeSafeConfig = conf.toTypeSafeConfig
}

隐式转换只允许我调用我的Config 上的所有TypeSafeConfig 方法，它有很多方便的方法。理论上，将来我可以删除我在Config 对象中使用的隐式和实现方法。但我很难想象为什么我会花时间在这上面。这是一些泄露实现的例子，我认为没有问题。

【讨论】：