封装结构&目录结构
在Java Web应用程序中，术语“包结构”和“目录结构”的确切含义是什么？它们不是一样的吗？我看到一些文章有这两个术语，但我不确定确切的含义和区别。
In Java web application, what is the exact meaning of the term "package structure" and "directory structure" ? Aren't they the same? I saw some articles have these two terms, but I am not sure about the exact meaning and difference.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
包是一起更改、一起使用和一起发布的代码的集合。所以 jar/war 是一个包。
包设计原则
我理解你的意思是源码包，它更像是目录结构。但我相信，目录是硬盘驱动器上的物理表示。
编辑：我三年多前就写过原始答案。但并没有改变，因为它被接受了。但现在就改变它，以便任何新访问者都可以受益，并避免链接失效。可以根据下面的讨论提取包的一些附加含义。例如，jar是包吗？
一起重用的类应该打包在一起，以便可以将包视为可供您使用的完整产品。一起重复使用的应与不重复使用的分开。例如，您的日志记录实用程序类不一定与您的文件 io 类一起使用。因此，将所有日志记录单独打包。但日志记录类可能彼此相关。因此，创建一种用于日志记录的完整产品，例如，为了需要更好的名称 commons-logging 将其打包在一个（可重复）可用的 jar 中，并为 io 实用程序创建另一个单独的完整产品，再次为了需要更好的名称，例如 commons- io.jar。如果您更新 commons-io 库以支持 java nio，那么您可能不一定要对日志记录库进行任何更改。所以把它们分开比较好。
现在，假设您希望日志记录实用程序类支持结构化日志记录，例如通过 splunk 等工具进行某种日志分析。您的日志记录实用程序的某些客户端可能想要更新到您的较新版本；其他一些人可能不会。因此，当您发布新版本时，请将需要的所有类打包在一起并重用以进行迁移。因此，实用程序类的某些客户端可以安全地删除旧的 commons-logging jar 并移动到 commons-logging-new jar。其他一些客户仍然可以使用旧的 jar。但是，客户端不需要同时拥有这两个 jar（新的和旧的），只是因为您强迫他们使用旧打包 jar 的某些类。
避免循环依赖。 a 依赖于 b； b 在 c 上； c 对 d；但 d 取决于 a。这种情况显然是令人望而却步的，因为定义层或模块等将非常困难，并且您无法相对于彼此独立地改变它们。
此外，您可以打包您的类，这样如果某个层或模块发生更改，其他模块或层不必更改。因此，举例来说，如果您决定从旧的 MVC 框架升级到 REST API，那么只有视图和控制器可能需要更改；你的模型没有。
Package is a collection of code that changes together, is used together and is shipped together. So a jar/war is a package.
Package Design Principles
I understand that you meant source package, which is more like directory structure. But I believe, a directory is a physical representation on hard drive.
EDIT: I had writtern original answer more than 3years back. But did not change as it was accepted. But changing it now so that any new visitor may benefit and also to avoid link rot. Some additional meaning of package may be extracted based on the discussion below. For example, is a jar a package?
Classes that get reused together should be packaged together so that the package can be treated as a sort of complete product available for you. And those which are reused together should be separated away from the ones those are not reused with. For example, your Logging utility classes are not necessarily used together with your file io classes. So package all logging them separately. But logging classes could be related to one another. So create a sort of complete product for logging, say, for the want of better name commons-logging package it in a (re)usable jar and another separate complete product for io utilities, again for the want of better name, say commons-io.jar. If you update say commons-io library to say support java nio, then you may not necessarily want to make any changes to the logging library. So separating them is better.
Now, let's say you wanted your logging utility classes to support structured logging for say some sort of log analysis by tools like splunk. Some clients of your logging utility may want to update to your newer version; some others may not. So when you release a new version, package all classes which are needed and reused together for migration. So some clients of your utility classes can safely delete your old commons-logging jar and move to commons-logging-new jar. Some other clients are still ok with older jar. However no clients are needed to have both these jars (new and old) just because you forced them to use some classes for older packaged jar.
Avoid cyclic dependencies. a depend on b; b on c; c on d; but d depends on a. The scenario is obviously deterring as it will be very difficult to define layers or modules, etc and you cannot vary them independly relative to each other.
Also, you could package your classes such that if a layer or module changes, other module or layers do not have to change necessarily. So, for example, if you decide to go from old MVC framework to a rest APIs upgrade, then only view and controller may need changes; your model does not.
在大多数 Java 应用程序中，包结构应与 .java 和 .class 文件的目录结构相匹配。然而，这些目录是更大目录结构的一部分，包括源和/或字节码之外的其他数据。
根据上下文，“包结构”也可能指交付包，每个交付包包含一个应用程序或一个库。
In most Java applications, the package structure should be matched by the directory structure for the .java and .class files. However these directories are part of a larger directory structure, including other data than the source and/or the bytecode.
Depending on the context, the "package structure" might also refer to delivery packages, each containing an application or a library.