【问题标题】:Access to variables and methods of a module in a multi-module program在多模块程序中访问模块的变量和方法
【发布时间】:2018-06-08 07:39:19
【问题描述】:

我正在编写一个模块化程序,旨在将模块作为独立单元与核心程序结合使用。

这意味着程序在“插入”或移除新模块时完全不会中断,并且不需要更改任何其他代码以使程序在有或没有某些模块的情况下编译和执行。

我的问题是,我是否应该为所有模块中的所有变量设置公共 getter 和 setter,并公开所有方法,以便开发人员在开发自己的模块时需要访问或更改某个模块中的变量(例如)模块,他们可以这样做而无需更改访问修饰符,还是我应该重新考虑我的设计?

提前感谢您!

【问题讨论】:

  • 这个问题不够清楚,只要我不知道你到底做了什么,但是我可以给你一些指导来满足你设计模块化组件的要求!
  • @msoliman 我还没有做任何事情,我在问这样我就不必再回去删除我写的所有内容了。我尝试使用反射和自定义配置文件,但发现我无处可去,而且我很可能用 Java 做所有事情。使用公共 getter、setter 和方法将是一个解决方案,但我想知道是否有更好的方法来解决这个问题。感谢您的评论!
  • 您好,欢迎来到 Stack Overflow。这是一个好问题,但对于 SO 来说不是一个好问题,因为它非常广泛。你可能会被否决,但不要气馁:这个网站对某些类型的问题非常有帮助(并且对其他类型的问题有敌意)。请花一些时间阅读help pages 和其他好问题,以了解本网站的用途。
  • 仅供参考,您的问题类似于stackoverflow.com/questions/565095/…stackoverflow.com/questions/14399929/…。请注意,这些问题收到了 7 和 16 个答案(这实际上是问题的证据:宽泛的高级问题往往会得到冗长、固执己见的答案,这本身还不错,但通常不适合 SO)。我建议您阅读这些问题和所有答案以获得更多观点。
  • @DavidS 谢谢你的链接!我看到给出的答案的唯一问题是他们专注于 OO 设计而不是模块化设计。但我确实看到这个问题有点主观,正如帮助页面所暗示的那样,这不是 SO 的用途。

标签: java modularity


【解决方案1】:

只要我需要帮助您,我会根据对您问题的理解尝试回答。如果您仍然需要问任何问题,请发表评论,否则不要忘记评价我的回答。

访问修饰符 (public, private, etc) 是为了在您的类中实现 abstraction and encapsulations 而构建的,它们都是面向对象编程的关键概念。所以你必须分析你的要求你应该向外界透露或披露什么,特别是如果你想发布你的代码并在不同的系统中使用你不需要其他开发人员更改一些仅供内部使用的属性,例如database connection string

  • 模块化,您可以在其中通过接口定义公共功能并实现这些接口。

  • 此外,我想到了一个原则,即您应该优先考虑组合而不是继承,以避免大量代码更改、中断和依赖。

  • 依赖注入框架可帮助您注入模块,例如 Spring 框架带有依赖注入。

  • 所有这些原则都将实现Open-closeLiscov substitution 原则,旨在使您的代码易于扩展和扩展,并且仍然保持系统关闭以进行修改。

现在应该涉及到设计模式,您应该将组件构建在一起,但它仍然基于您的要求,您可以在其中使用Factory Method,例如,如果您有一个工厂构建多种类型的对象。 Strategy 您需要在运行时根据用户激活等更改行为。

答案甚至应该比这更长,但是我试图让您一瞥应该在哪里搜索并从这里继续。

【讨论】:

  • 我更新了我的问题,希望能提供更多关于我的问题的详细信息,但要明确一点:假设我有一个核心模块(运行一切的那个)和辅助模块 x 和 y。另一个开发者来了,想要开发模块 z,但需要从模块 x 运行一个方法并从模块 y 中获取一些变量。为了促进这一点,我应该让所有内容都可以公开访问,以便模块 x 和 y 中的所有内容都可以访问,还是应该让他们根据他们认为合适的方式调整其他包中的访问修饰符?
  • 将必要的公开,并在以后进行调整以提供更多访问权限。如果您有多个客户端,如您所说,其中一些应该具有公共属性,而另一个客户端或模块需要不同的公共属性,使用继承或组合并为每个客户端公开他自己的类,@nanoandrew4 是否清楚或您仍然感到困惑
  • 您的评论很清楚,感谢您的快速回复。
  • @nanoandrew4 如果对您有帮助,请不要忘记评价我的答案并标记为正确
  • 我对您的答案进行了评分,但会等着看其他人是否有其他答案,然后再将其标记为正确。
猜你喜欢
  • 2017-06-18
  • 2015-09-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-04-12
  • 1970-01-01
  • 1970-01-01
  • 2014-09-10
相关资源
最近更新 更多