改进Java中的包私有类 [英] Improvement of package-private classes in Java

查看:710
本文介绍了改进Java中的包私有类的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

根据我的经验,Java中的类的包私有可见性被证明是多余的。



包私有的可见性似乎是基于一个前提,即几乎私人使用的另一个类的类可能被保存在同一个包中。通常情况不是这样。 是否有人在探索改进的访问权限修饰符/替代机制?



尝试使用包私有可见性时出现问题:




  • 我们试图将功能上不相关的类放在同一个包中
    来获得这个好处



使用public的问题:




  • API被污染。一旦库Jar导入,客户端就会看到其他公共类,他不必担心

  • 从编码标准的角度来看,没有一种简单的方法可以确保短期电路调用不是由开发者在时间紧缩
    (通过短路调用我的意思是方法调用绕过一层(像从Servlet直接到DAO绕过bean / BO)



当前的解决方法:




  • 为了劝阻短路电话,部分应用程序分成多个JAR,并确保每个构建的构建环境中只有相应的JAR(例如server.jar在编译swing客户机类时不可用,只有客户机类和common.jar可用)。 )



问题:



  1. 这些行中的某些内容已经在管道中了吗?

  2. 像Spring / Guice这样的框架是否足够替代?


解决方案

$ c> scala 。有一个访问修饰符的作用域。我发现本教程

 

class =lang-scala prettyprint-override> package company.module.domain

类示例{
private [module] def moduleMethod =?
private [domain] def domainMethod = ???
}

在此示例中 moduleMethod 在包模块及其子包(如 domain )中的任何位置都可用。方法 domainMethod 仅在 domain 包中可见且外部不可见。



不幸的是,此功能与 java 不兼容,并且这些限制被编译为字节代码,但没有限制,即公开


In my experience, package-private visibility for classes in Java is turning out to be redundant.

Package-private visibility seems to be based on the premise that a class which is almost-privately used by another class is likely to be kept in the same package. Often this is not the case. Is someone exploring an improved access modifier/alternate mechanism?

Problem with trying to use package-private visibility:

  • We are tempted to put functionally unrelated classes in same package to get this benefit

Problem with using public instead:

  • APIs get polluted. Once a library Jar is imported, client sees several other public classes that he has no need to be worried about
  • From a coding-standards perspective, there is no easy way to ensure that short-circuit calls are not done by developers on time crunches (By short-circuit calls I mean method calls that bypass a layer (like from Servlet direct to DAO bypassing the bean/BO)

The current workaround:

  • To dissuade short-circuit calls we usually package different parts of the application into several JARs and ensure only the respective JARs are available in the build environment for each build. (For example server.jar would not be available while compiling swing client classes. Only client classes and common.jar would be available.)

Questions:

  1. Wouldn't it be useful to come up with a new visibility modifer/alternative?
  2. Is something along these lines already in pipeline?
  3. Are frameworks like Spring/Guice sufficient replacements?

解决方案

Looks like a feature from scala. There is a scope for access modifiers. I've found this tutorial useful.

Method can be private in scope of some package

package company.module.domain

class Example {
  private[module] def moduleMethod = ???
  private[domain] def domainMethod = ???
}

In this example moduleMethod is available everywhere inside package module and its child packages (like domain). Method domainMethod is visible only in domain package and invisible outside.

Unfortunately this functionality is not compatible with java and those restriction are compiled to byte code with lost of restrictions i.e. to public

这篇关于改进Java中的包私有类的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆