如何组织包(并防止依赖循环)？

我一直在我的Java项目上运行一些指标,显然包之间有很多依赖循环.我真的不知道如何将东西组织成包裹,所以我只是做了对我有意义的事情,这显然是错误的.

我的项目是一个神经网络框架.神经网络具有神经元,它们通过连接相互连接.他们需要相互依赖.然而,也有不同类型的神经元,所以我认为将它们全部放在自己的'神经元'包中是个好主意.显然,Connection不是神经元,所以它不应该在包中,但由于它们彼此引用,我现在有一个循环依赖.

这只是一个例子,但我有更多这样的情况.你如何处理这些情况？

另外,我读到包层次结构中更高层的包中的类不应该引用更深层的包中的类.这意味着包'nn'中的NeuralNetwork类不能引用包'nn.neurons'中的Neuron.你们遵循这个原则吗？如果我将NeuralNetwork转移到'nn.networks'或其他什么怎么办？在这种情况下,它将指代一个兄弟包而不是一个孩子.这是更好的做法吗？

该antcontrib VerifyDesign任务将帮助你做你想要什么:

例如,如果一个源树中有三个包

* biz.xsoftware.presentation
* biz.xsoftware.business
* biz.xsoftware.dataaccess

自然呈现应该只依赖于业务包,业务应该依赖于dataaccess.如果以这种方式定义设计并且违反了,则在调用verifydesign ant任务时,构建将失败.例如,如果我在biz.xsoftware.presentation中创建了一个类,并且该类依赖于biz.xsoftware.dataaccess中的类,则构建将失败.这确保了设计实际遵循记录的内容(至少在某种程度上).这对于自动构建尤其有用

因此,一旦确定了应该如何组织事物,您就可以在编译时强制执行这些要求.您还可以获得精细控制,以便您可以允许某些情况打破这些"规则".所以你可以允许一些周期.

根据您的工作方式,您可能会发现"utils"包有意义.

对于你引用的特殊情况......我可能会这样做:

package nn包含Nueron和Connection

package nn.neurons包含Nueron的子类

Neuron和Connection都是NeuralNetowrk中使用的高级概念,因此将它们放在一起是有意义的.Neuron和Connection类可以互相引用,而Connection类不需要知道Neuron子类.

首先,你是理所当然的,因为包之间的循环依赖是坏的.随之而来的问题随着项目的规模而变得越来越重要,但没有理由按时解决这种情况.

您应该通过将在同一个包中一起重用的类放在一起来组织您的类.因此,如果您有例如AbstractNeuron和AbstractConnection,则将它们放在同一个包中.如果您现在已经实现了HumanNeuron和HumanConnection,那么您可以将它们放在同一个包中(例如*.network.human).或者,您可能只有一种类型的连接,例如BaseConnection和许多不同的神经元.原则保持不变.您将BaseConnection与BaseNeuron一起放置.HumanNeuron与HumanSignal以及VirtualSignal等一起使用自己的包.您说:"显然连接不是神经元,所以它不应该在包中......".这不是那么明显,也不准确.

你说你把所有的神经元放在同一个包里.除非您重复使用所有实现,否则这两者都不正确.再次,看看我上面描述的方案.您的项目非常小,您可以将所有项目放在单个包中,或者按照描述开始组织包.有关更多详细信息,请参阅共同重用原则:

包装中的类别一起重新使用.如果你重新使用一个套餐中的一个,你可以重新使用它们.

我不认为像你描述的那样的循环依赖必须是坏的.只要相互依赖的概念处于相同的抽象级别并且与架构的相同部分相关,则可能没有必要将它们彼此隐藏.神经元和连接符合我的理解.

减少这种耦合的一个常见方法是提取接口,甚至可能将它们放在一个单独的模块中.简单地通过单个项目内的包进行组织不允许您充分隐藏实现细节.允许您真正隐藏实现的常见模式如下:

客户端代码---->接口<---实现

在此模式中,您从客户端代码隐藏"实现"模块,这意味着"客户端代码"模块中的代码甚至看不到实现代码.

包的嵌套有多种用途:某些项目可能具有以包的形式组织的域模型.在这种情况下,包反映了域的一些分组,并且引用可以上/下包.当涉及服务实施等事情时,您建议的模式非常普遍,并且是一件好事.包层次结构越深,您认为该类就越具体.

我们在谈论哪种代码大小？如果只有10-20个类，则可能不必（也不应该）仅出于此目的将代码过度组织到包中。

随着项目的发展，您要做出的第一个区别是将用户界面代码与基础数据模型和逻辑分开。为了能够进行正确的单元测试，使层干净地分开是至关重要的。

如果您在摆脱循环依赖方面遇到麻烦，则可能是类实际上是相互依赖的，并且应该驻留在同一包中。

在设计整体代码结构时，使抽象层正确可能是最重要的方面之一。

你如何处理这些情况？

循环依赖本身并不坏.实际上,这有时可能是"治愈比疾病更糟糕"的情况:提取界面会增加代码的复杂程度并增加另一层间接性.对于非常简单的关系来说,这可能不值得.