域名备案期间怎么做网站,广告投放行业,私域流量代运营公司,招标网站怎么做包装类型与包装类别我记得大约15年前开始学习Java的时候。 我读到了很多有关“包装”和“命名空间”的东西#xff0c;但我完全不了解。 可悲的是#xff1a;虽然包装的某些方面几乎为行业中的每个人所了解#xff0c;但其他方面却不是。 因此#xff0c;让我们看一下哪些软… 包装类型与包装类别 我记得大约15年前开始学习Java的时候。 我读到了很多有关“包装”和“命名空间”的东西但我完全不了解。 可悲的是虽然包装的某些方面几乎为行业中的每个人所了解但其他方面却不是。 因此让我们看一下哪些软件包最适合。 命名空间 通过为您的所有程序包加上您所控制的域的前缀可以确保您的类名是唯一的。 这对于数量惊人的开源项目的成功至关重要。 每个项目都可以并且可能在某个阶段进行定义定义一个“ Filter”类而不会干扰该类的所有其他同名类除了可怜的开发人员他们从网络上复制了一些没有导入语句的代码现在以找出实际引用了哪个Filter类。 这是一个很好的理解而且我还没有看到根软件包的任何相关用法。 组织 我儿子有一大盒乐高积木。 可能有成千上万个。 当他寻找简单的2×4砖块时这不是问题。 但是当他正在搜索仅在集合中存在4次甚至只有一次的特殊砖块时 可能需要很长时间才能找到它。 将其与药剂师柜子比较。 数百种药物通常只需几秒钟即可找到合适的药物。 而且他们甚至都没有使用Google 它们只是每种药物所属的严格订购原则包括一条规则即如何确定新药的正确框。 由于涉及的每个人都知道该原理因此很容易确定要在其中找到毒品的正确盒子。 当在项目早期建立时这样的排序原则将非常有用。 当定义这样的原则时一个标准在大多数时间是不够的。 但是如果您使用更多的规则则使规则正交以确保它们不会干扰。 这意味着没有规则说“所有数据库访问代码都必须放入软件包x中”而另一条规则规定“与客户相关的所有代码都必须放入软件包y中”。 否则您将不知道将CustomerDAO放在哪里。 而是在包树的不同深度上应用正交规则。 我的默认包结构如下所示 organisational-prefix.application.deployment-unit.module.layer.optional further substructure if needed 这将导致软件包名称例如com.mycompany.theCoolApp.server.user.persistence或com.mycompany.theCoolApp.client.shoppingCart.presentation 。 如果您查看这样的包结构则很明显新类属于什么地方或者类似的东西已经存在的地方。 如果避免使用诸如util或misc类的名称它们可能会或多或少地隐藏所有内容则效果会更好。 您也可以查看这些软件包并立即了解有关体系结构的知识。 一旦看到一个名为client webserver和batchserver的软件包级别您就会在脑海中形成一个模型说明应用程序的结构以及名称的选择是否正确。 由于在每个module中都应用了相同的layers规则因此您也可以在较低的软件包中找到有关应用程序结构的更多信息。 之间的module传达应用程序要处理的领域的类型。 很自然重要的概念会得到自己的包装从而使每个检查代码的人都可以声明这是此应用程序中的重要概念。 我还喜欢添加规则“一个包应包含a – b类但不得包含c或更多类”并为ab和c设置适当的值。 随着应用程序的增长这将强制创建新的软件包从而使每个软件包保持可管理的大小。 当然在较小的应用程序中结构可能会缩小。 例如如果只有一个部署单元则无需为该分类使用单独的程序包级别。 包的最后一种用法是最被忽略的 中间建模块 Joe Average Developer主要关注类和方法以及单行代码同时尝试在该级别上提出适合应用程序需求的代码结构。 通常有些架构师会弄清楚如何部署应用程序从而确定必要的部署单元请考虑单独的jar。 如果您查看这些工件的规模可能会发现一些有趣的东西 1种方法由大约10行代码组成。 1类包括大约10种方法。 1罐子大约包含100 – 1000类。 如果没有人照顾包裹则至少会缺少一种结构常常会缺少两层结构 可以并且应该用包装来填补这个空白。 这不仅意味着包装应该存在并且具有合理的尺寸还意味着它们应该遵循通用的设计准则。 特别是“ 单一责任原则”和对依赖项的正确处理 单一责任原则 通过上面提出的命名方案完成了兑现SRP的大量工作。 如果软件包的内容符合其名称说明那么在此方面一切都很好。 依赖性管理 是更强悍的野兽。 Java当前没有提供适当的系统来控制软件包之间的依赖关系尤其是超级软件包即包含多个其他软件包的软件包。 有OSGI 但是我发现使用它很麻烦 特别是因为我不需要所有的动态加载内容但是却遭受了类加载器问题的困扰。 也有拼图但还不存在。 因此我更喜欢使用自定义测试来定义和验证所使用的应用程序的程序包结构。 我选择的工具是JDepend 。 它为您提供了程序包之间的依赖关系列表您可以使用它们将它们与您定义的规则进行比较。 有人创建了从程序包A到程序包B的依赖关系该依赖关系不应该存在 动臂测试变成红色。 那么对程序包依赖性有用的规则是什么 第一无周期。 不在包级别上也不在layer级别上或module级别上如上所述。 第二模块和层具有严格的顺序在顺序上它们可以相互依赖其他所有内容均被禁止。 这些规则极大地限制了开发人员的自由度。 但是以我的经验它消除了违反“单一责任原则”的情况该原则经常以循环依赖的形式出现。 例如如果您有一个Order模块和一个Customer模块则感觉这两个需要彼此了解。 如果您有订单则想知道该订单所属的客户。 如果您有客户您必须能够告诉她所下的订单。 对 很可能是。 但是您是否需要两侧都有完整的对象和功能 可能不是。 例如通过提供一个界面包其中仅包含订购模块所需的客户功能的最核心部分以及一个单独的完整的具有参考订单的客户模块 可以打破这些依赖关系并在您的需求中实现更强的关注分离包装结构。 当您尝试开发应用程序时这反过来会有所帮助。 今天的软件包有一天可能会成长为一个部署单元如果您在部署单元之间存在循环依赖关系则会遇到一些严重的问题。 也许您的团队成长为多个团队。 有了如上所述的干净的程序包结构当团队必须坐在一起讨论由多个团队使用的程序包的更改时您将有明显的界限可以拆分并且还有明显的标准。 参考来自Schaderhaft博客的JCG合作伙伴 Jens Schauder 的软件包重要性 。 翻译自: https://www.javacodegeeks.com/2013/01/the-importance-of-packages-3.html包装类型与包装类别
