【问题标题】:How to correctly organize a set of concrete classes implementing an interface in different packages?如何正确组织一组在不同包中实现接口的具体类?
【发布时间】:2012-05-21 07:36:15
【问题描述】:

我已经定义了一个我的系统将依赖的接口:

IMethodCall

我创建了一堆实现IMethodCall的类:

AbstractMethodCall
ConstructorCall
TargetConstructorCall
VoidMethodCall
TargetVoidMethodCall
NonVoidMethodCall
TargetNonVoidMethodCall

它们是实现的细节,我的系统不知道(或者至少不需要知道)。

根据我当时手头的一组数据选择要实例化的实现背后有一些棘手的逻辑,所以我决定创建一个工厂来将所有逻辑分组在一个地方:

MethodCallFactory

我试图了解这里使用的包结构应该是什么。我最初的想法是将所有具体的类放在一个methodCalls 包中,并将它们设置为受包保护,这样没人会知道它们的存在。然后我会让IMethodCallMethodCallFactory 在外面,这样我系统的用户就可以使用它们。问题是,如果我将具体类作为包保护,那么工厂也必须在它们的包中,这反过来看起来有点奇怪,因为对于外部查看者来说,它看起来像是一个只存在包含的包工厂。

目前我认为最好的权衡是将具体类公开,但我想知道你们通常如何处理这种情况?

【问题讨论】:

  • 公开它们有什么害处吗?
  • 公开它们的危害在于它们可以直接访问,这显然是作者想要防止的,因为使用工厂的本质。

标签: java oop package


【解决方案1】:

您可以将您的工厂类和接口放在公共包中,并将实现的类放在内部包中。

不鼓励使用内部包,内部包中的类可能随时更改。用户应调用公共包中的 api。

例如:

一个公共包是 org.feeling.ui.dialogs

一个内部包是 org.feeling.internal.ui.dailogs

【讨论】:

  • Java 不强制区分这些。如果您希望编译器强制执行您的实现的私有性,这种方法将不起作用。
【解决方案2】:

当我遇到这种情况时,我会将具体实现类和工厂放在同一个包中,并将实现类包私有化。

您提到这种方法似乎很奇怪,因为外部观点。我不同意外部用户不知道有实现类。大多数 IDE 将显示包中的类,即使它们不可访问。此外,如果程序员尝试使用您的实现类,编译器将暗示该类存在,但不允许访问。

我也不同意只有一个包含工厂并且它是私有实现的包是很奇怪的。这组类紧密相关,因此将它们组合在一个地方是合乎逻辑的。

【讨论】:

    猜你喜欢
    • 2011-11-27
    • 1970-01-01
    • 2019-05-10
    • 2015-01-29
    • 2023-03-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-11-04
    相关资源
    最近更新 更多