看看Bob叔叔的包装设计原则。 他解释了这些原则背后的原因和动机,我在下面对此进行了详细阐述:
应该将一起重用的类打包在一起,以便可以将打包包视为可供您使用的完整产品。 一起重用的那些应该与那些不重用的那些分开。 例如,您的Logging实用程序类不必与文件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 条件; 但是d取决于a。 该场景显然令人望而却步,因为很难定义层或模块等,并且您不能相对于彼此独立地进行更改。
同样,您可以打包您的类,以使如果某个层或模块发生更改,则不必一定更改其他一个或多个模块。 因此,例如,如果您决定从旧的MVC框架升级到其余的API,则仅视图和控制器可能需要更改。 您的模型没有。