淮南模板网站建设费用,检察网站建设请示,wordpress seo设置,舆情网站直接打开的软件即使只是少量更改角度#xff0c;也可能对您如何使用系统产生深远影响。 假设您正在用Java编写Web应用程序。 在系统中#xff0c;您处理订单#xff0c;客户和产品。 作为Web应用程序#xff0c;您的类包括诸如Controller#xff0c;PersonRepository#xff0c;Custome… 即使只是少量更改角度也可能对您如何使用系统产生深远影响。 假设您正在用Java编写Web应用程序。 在系统中您处理订单客户和产品。 作为Web应用程序您的类包括诸如ControllerPersonRepositoryCustomerController和OrderService之类的订书钉。 您如何将课程组织成包 有两种基本的方法来构建软件包。 您可以专注于逻辑层例如com.brodwall.myapp.controllerscom.brodwall.myapp.domain或com.brodwall.myapp.services.customer。 或者您可以专注于域上下文例如com.brodwall.myapp.customercom.brodwall.myapp.orders和com.brodwall.myapp.products。 迄今为止第一种方法最为普遍。 在我看来它也是最没有帮助的。 如果您围绕领域概念而不是技术层来构建软件包则可以通过以下几种方式改变思维 首先也是最根本的您的思维模型现在将与系统用户的思维模型保持一致。 如果要求您实现典型功能那么现在很可能将重点放在系统软件包的严格子集中。 例如向表单添加新字段将至少影响相应域概念的表示逻辑实体和持久层。 如果您的软件包是围绕层组织的则此更改将影响整个系统。 一句话围绕功能而非技术组织的系统具有更高的一致性。 这个技术术语意味着一个类的大部分依赖项都位于该类附近。 其次随着软件的发展围绕领域概念进行组织将为您提供更多选择。 当一个程序包包含数十个类时您可能需要将其拆分为几个程序包。 讨论本身可以启发人。 “也许我们应该将客户地址类别分离到com.brodwall.myapp.customer.address包中。 它似乎有自己的生活。” “是的也许我们可以在需要地址的其他地方使用相同的类例如供应商” “很酷那么com.brodwall.myapp.address呢” 或者也许您认为应该将订单状态代码和付款状态代码放在“ com.brodwall.myapp.order.codes”包中。 另一方面您有什么选择拆分com.brodwall.myapp.controllers 您可以为客户订单和产品创建子包但是这些子包可能只具有一个或两个类。 最后也许是最有趣的是使用领域概念进行包装可以使您根据具体情况改变设计。 也许您确实需要一个OrderService来协调订单的付款和运输而ProductController仅需要带有存储库的基本create-retrieve-update-delete功能。 一个ProductService只会给您带来麻烦。 如果com.brodwall.myapp.services包中缺少ProductService这可能会造成混淆或者至少会给您带来麻烦的感觉那就是出现了问题。 另一方面如果com.brodwall.myapp.product程序包中没有控制器则没关系。 而且大多数系统都有一些不错的零件而有些则不太好。 如果您的服务包对您不起作用那么您将无能为力。 但是如果“产品”程序包烂了您可以将其丢弃并重新实现它而不会使整个系统陷入混乱状态。 通过将实现某个功能所需的类彼此放在一起并与实现其他功能所需的类分开开发人员在开发一个功能时可以务实和创新而不会负面影响其他功能。 不利的一面是大多数开发人员对应用程序中的某些技术更满意而对其他技术则较不满意。 围绕功能而非技术进行组织会迫使每个开发人员考虑更多的技术挑战。 有些程序员将其视为学习的动力而其他程序员似乎宁愿不必学习新知识。 如果花我的钱来创建功能我就知道我想要什么样的开发人员。 细微的变化会产生很大的影响。 通过围绕功能组织软件您将获得一个更加一致的系统可以进行扩展。 它可能会给您的开发人员带来挑战但会降低实现功能所需的交接数量并会挑战开发人员以改善他们正在处理的应用程序部分。 参考 Java 合伙人 Johannes Brodwall在“ 更大的盒子里的思考”博客中的更改Java包名称如何改变了我的系统架构 。 翻译自: https://www.javacodegeeks.com/2012/07/how-changing-java-package-names.html
