如何将OO项目划分为包？

Question

我是一个业余程序员，在我自己的项目上工作。我用Java。

直到最近，我的平均项目只有1000 LoC。然而，我的最新项目规模更大，并开始超过1500 LoC。我估计会达到2000人左右。

我从来没有把我的课组织成一个包。所有这些都在默认的包中，并且工作正常。

然而，随着我的项目越来越多，课程的数量也越来越多，我开始感到没有条理了。

我的问题是:如何将他/她的类划分成包？我的意思是，你们按照什么标准来划分班级？

是该应用程序的“部分”吗？也就是一个包中的GUI类，另一个包中的业务逻辑，网络等等？或者是高级别的课程和低级的课程？也就是在自己的包中执行具体的、特定的工作的类，以及将所有这些类绑定在自己的包中的“体系结构”类？或者你只是简单地按照“你觉得正确和有组织的东西”的标准来划分？

例如，我正在开发一个制作音乐的应用程序。它基本上分为两个主要系统:制作音乐的系统和显示GUI并控制另一个系统的系统(即，在该系统中按下按钮可以激活另一个系统)。

音乐创作系统也被分为两个系统:创造旋律和创造和弦进步。和chord-级数生成部分，除其他外，包含一组类，这些类作为所涉及的策略模式的可交换算法(即用于特定实现细节的类)。

当然，每个系统都有较高层次和较低层次的课程。例如，进度生成系统包含一个ProgressionGenerator类，该类级别较高，并将整个系统连接在一起。它还有一个Chord类，它的级别要低得多(即负责播放特定的音符)。

我把它组织成类的方式如下：

音乐创作系统分为一个包，控制另一个系统到另一个包的GUI系统。

而不是把旋律创造成音乐创造的一个子包，创造成一个不同的子包。

在逐步创建子包中，另一个子包涉及到该系统中某个位置的用于该策略模式的类。

，这听起来像把东西组织成包的好方法吗？您根据什么标准将类划分为包？用“什么感觉对”，还是用更专业的术语？

Answer 1

一般来说，我倾向于按职责/职能组织。但这完全取决于你的具体项目和架构，这里没有一个明确的答案/指导方针。更别提个人品味在这里也起了很大的作用。

我的建议是:看看其他人/组织是怎么做的。利用开源。例如，查找github上的项目并浏览它们的源代码。你会感觉到不同的方法，并且可以决定你喜欢哪种方法。

Answer 2

您的问题没有一个答案，这取决于应用程序的体系结构。这个问题可能会结束。

2000行代码实际上很小。如何将程序划分为类是与我如何实现面向对象程序设计相同的问题。你应该从维基百科开始，然后买一本关于这个主题的书，或者在网上找到一门课程。

就指南而言，您可以从实心和包装原则开始

在包装原则中，重用-释放等效原则(REP)指出：

REP本质上意味着包必须使用可重用类创建。

也就是说，如果您不需要重用，那么就不需要将它们与应用程序分开打包。

Answer 3

组织和建模你的课程，这样你就可以得到OOP和SOLID等方面的好处。

封装和数据隐藏。有许多方法可以将事物组织成相互紧密联系的类，并且仍然满足OOP的“正式”定义。OOP语言和设计原则使其变得更容易，并为您提供了实现封装和数据隐藏的工具，而且它实际上使创建如此紧密的、依赖的混乱变得非常困难。通过理解OOP方法将来会给您带来什么，试着理解为什么要以面向对象的方式来实现它。

多态性和重用。再一次，从几乎任何‘事物’或概念中提取一些抽象的方法是有百万种的。OOP的要点是，您可以从这种哲学化中获得好处。您可以获得重用，泛化，更多功能的更少的代码。较少的维修等

这些都是好的。看看其他的OOP和实体，并决定你是否真的能实现一个好处，让它引导你进入一个自然的组织策略。

还有很多时候，OOP原则并不能真正帮助您；至少在您的产品目前的规模和成熟程度上是如此；它们只是使事情变得更加复杂。但这种“原则上”的坚持，可能会使你的产品更有前途。一个很好的例子是类似于依赖反转/注入，或者类似于工厂模式。通常情况下，过度杀戮，但当你的应用程序增长，你感谢天上的星星，你把挂钩(DI，工厂)在那里的版本1。