mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
translated Some Sentences about Java
This commit is contained in:
a598799539
parent
db7184f092
commit
37715e5eca
@ -1,164 +0,0 @@
|
||||
[a598799539 translating...]
|
||||
Some Sentences about Java
|
||||
================================================================================
|
||||
There is nothing new in this article. I just collected some trivial statements which may not be trivial for some of the junior programmers programmers. Boring old stuff.
|
||||
|
||||
If you happen all of these things you know more about Java than the average house wife. I do not know if there is point to know all of these. You can be a fairly good Java programmer if you do not know some of these features. However a lot of new information in this article probably indicates you have room to develop.
|
||||
|
||||
### There are 4 different protection types ###
|
||||
|
||||
in Java (not three). These are `private`, package private, `protected` and `public`. If you do not specify any protection modifier when you define an element in a class it will be package private (and not public and not protected).
|
||||
|
||||
|
||||
|
||||
There are four levels of protection in Java.
|
||||
|
||||
On the other hand if you do not specify protection modifier in front of a method declaration in an interface: it will be public. You may specify it to be explicitly public but it does not have effect on Java and SONAR will not like you doing so.
|
||||
|
||||
|
||||
|
||||
Protection is Transitive
|
||||
|
||||
> My opinion about Java allowing you to optionally write `public` in front of a method in an interface is that this is a technology mistake.
|
||||
|
||||
Similarly you can write `final` in front of a field in an interface, or even `static`. It may imply that they could be non-static or non-final: not true. Fields of an interface are final and static. Always.
|
||||
|
||||
### Protected and package private are not the same ###
|
||||
|
||||
Package private (or default) protection will let other classes of the same package access to the method or field. Protected methods and fields can be used from classes in the same package (so far the same as package private) and in addition to that it can be used from other classes that extend the class containing the protected field or method.
|
||||
|
||||
### Protected is transitive ###
|
||||
|
||||
If there are three packages `a`, `b` and `c`, each containing a class named `A`, `B` and `C` so that `B` extends `A` and `C` extends `B` then the class `C` can access the protected fields and methods of `A`.
|
||||
|
||||
package a;
|
||||
|
||||
public class A {
|
||||
protected void a() {
|
||||
|
||||
}
|
||||
}
|
||||
package b;
|
||||
|
||||
import a.A;
|
||||
|
||||
public class B extends A {
|
||||
protected void b() {
|
||||
a();
|
||||
}
|
||||
}
|
||||
package c;
|
||||
|
||||
import b.B;
|
||||
|
||||
public class C extends B {
|
||||
protected void c() {
|
||||
a();
|
||||
}
|
||||
}
|
||||
|
||||
### Interface can not define protected methods ###
|
||||
|
||||
Many thinks that you can also define `protected` methods in an interface. When programming the compiler makes it obvious fast and brutally: you can not. Btw: this is why I think that allowing the `public` keyword in an interface is a technology mistake: it makes people think that it could also be something else as well.
|
||||
|
||||
|
||||
|
||||
Private is the new public
|
||||
|
||||
If you want to declare a `protected` method in an interface, you probably did not understand encapsulation.
|
||||
|
||||
### Private is not that private ###
|
||||
|
||||
Private variables and methods are visible inside the compilation unit. If that sounds too cryptic: in the same Java file (almost). This is a bit more than “in the class where they are defined”. They can also be seen from classes and interfaces that are in the same compilation unit. Inner and nested classes can see private fields and methods of the class enclosing them. However enclosing classes can also see the private methods and fields of the classes they enclose down to any depth.
|
||||
|
||||
package a;
|
||||
|
||||
class Private {
|
||||
private class PrivateInPrivate {
|
||||
private Object object;
|
||||
}
|
||||
|
||||
Object m() {
|
||||
return new PrivateInPrivate().object;
|
||||
}
|
||||
}
|
||||
|
||||
This latter is not widely known. As a matter of fact it is rarely useful.
|
||||
|
||||
### Private is class level not object ###
|
||||
|
||||
If you can access a variable or method you can access it no matter which object it belongs to. If `this.a` is accessible then `another.a` is also accessible assumed that `another` is an instance of the same class. Objects that are instances of the same class can fool around with each others variables or methods. Rarely makes sense to have such a code though. A real life exception is `equals()` (as generated by Eclipse, lines 15 and 18):
|
||||
|
||||
package a;
|
||||
|
||||
public class PrivateIsClass {
|
||||
private Object object;
|
||||
|
||||
@Override
|
||||
public boolean equals(Object obj) {
|
||||
if (this == obj)
|
||||
return true;
|
||||
if (obj == null)
|
||||
return false;
|
||||
if (getClass() != obj.getClass())
|
||||
return false;
|
||||
PrivateIsClass other = (PrivateIsClass) obj;
|
||||
if (object == null) {
|
||||
if (other.object != null)
|
||||
return false;
|
||||
} else if (!object.equals(other.object))
|
||||
return false;
|
||||
return true;
|
||||
}
|
||||
}
|
||||
|
||||
### Static classes may have many instances ###
|
||||
|
||||
|
||||
|
||||
Protection is not object level. It is class level.
|
||||
|
||||
Classes that are not supposed to have any instances are usually called utility classes. They contain only static fields and static methods and the only constructor is private, not invoked from any of the static methods of the class. In Java 8 you can have such a beasts implemented in interfaces, since Java 8 interfaces can have static methods in it. I am not convinced that we should use that feature instead of utility classes. I am not absolutely convinced that we should use utility classes at all.
|
||||
|
||||
Static classes are always inside in another class (or interface). They are nested classes. They are static and just as static methods can not access instance methods and fields of the class similarly a static nested class can not access the instance methods and fields of the embedding class. That is because nested classes do not have a reference (pointer if you like) to an instance of the embedding class. Inner classes, as opposed to nested classes are non static and can not be created without an instance of the embedding class. Each instance of an inner class has a reference to exactly one instance of the embedding class and thus an inner class can access instance methods and fields of the embedding class.
|
||||
|
||||
Because of this you can not create an inner class without an instance of the surrounding class. You need not specify it though if this is the current object, a.k.a `this`. In that case you can write `new`, which is, in this case, just a short form for `this.new`. In a static environment, for example from a static method you have to specify which instance of the enclosing class should the inner class created with. See the line 10:
|
||||
|
||||
package a;
|
||||
|
||||
class Nesting {
|
||||
static class Nested {}
|
||||
class Inner {}
|
||||
void method(){
|
||||
Inner inner = new Inner();
|
||||
}
|
||||
static void staticMethod(){
|
||||
Inner inner = new Nesting().new Inner();
|
||||
}
|
||||
}
|
||||
|
||||
### Anonymous classes can access only final variables ###
|
||||
|
||||
|
||||
|
||||
Variable has to be effective final
|
||||
|
||||
When an anonymous class is defined inside a method, it can access local variables if they are final. But saying that is vague. They have to be declared final and they also have to be effective final. This is what is released a bit in Java 8. You need not declare such variables as final but they still have to be effective final.
|
||||
|
||||
|
||||
|
||||
Java 8 does not require final, only effective final
|
||||
|
||||
Why do you need to declare something final, when it has to checked to be like that anyway. Like method arguments. They also have to be final. You say that this is not a requirement of Java? Well, you are right. It is a requirement of programming in good style.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.javacodegeeks.com/2014/11/some-sentences-about-java.html
|
||||
|
||||
作者：[Peter Verhas][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.javacodegeeks.com/author/peter-verhas/
|
||||
202
translated/tech/20141127 Some Sentences about Java.md
Normal file
202
translated/tech/20141127 Some Sentences about Java.md
Normal file
@ -0,0 +1,202 @@
|
||||
一些关于Java的句子
|
||||
================================================================================
|
||||
本文并没有什么新鲜的。我只是收集了一些不太重要的语句，
|
||||
但这些语句可能对初级程序员来说很重要。也就是些无聊的旧东西。
|
||||
|
||||
如果以下的这些你都知道的话，那么你比Java的了解已经超过了对一个平常的家庭主妇的了解。我不知
|
||||
道清楚所有的这些是否是有意义的。即使不知道其中的一些特性，你照样也可以成
|
||||
为一个相当不错的Java程序员。然而，本文中许多的新信息可能表明你还有很大
|
||||
的发展空间。
|
||||
|
||||
### Java中有四种不同的访问类型(而不是三种) ###
|
||||
|
||||
这四种类型包括：`private`, package private (包访问权限，无修饰符，又叫
|
||||
default, 译者注)。如果你在类中定义一个元素时并不加任何访问类型修饰符，
|
||||
它将被默认设置为包访问权限(package private)，而不是`public`或者`protected`。
|
||||
|
||||
|
||||
|
||||
|
||||
Java有四个级别的访问类型。
|
||||
|
||||
从另一方面来说，如果在接口中，你不指定方法的访问修饰符，那么它将是
|
||||
`public`类型的。你也可以显式地指定它为`public`类型， 但这并不符合SONAR
|
||||
（一个开源代码质量管理平台，译者注）的代码质量管理思想。
|
||||
|
||||
|
||||
|
||||
访问类型是传递的
|
||||
|
||||
> 我的在Java中允许选择性的在接口的方法中写`public`的观点是一个技术错误。
|
||||
|
||||
同样你也可在接口的字段前写`final`，甚至是`static`。这说明这些字段可以
|
||||
是非静态或非final吗？不是的，接口中的字段中总是final和static的。
|
||||
|
||||
### Protected和package private是不一样的 ###
|
||||
|
||||
Package private（或者default）访问类型可以使得相同包(package)下其他类
|
||||
能够访问这些字段或方法。保护类型(`protected`)的方法和字段可以被相同包
|
||||
下的类使用(这和package private是一样的)，同时它也可以被其他类使用，只
|
||||
要那个类继承了这个包含这些`protected`方法或字段的类。
|
||||
|
||||
### Protected是可传递的 ###
|
||||
|
||||
如果有三个包a、b、c，每个包都分别包含A、B、C类，而且B继承A，C继承B，那
|
||||
么C可以访问A中的protected字段和方法。
|
||||
|
||||
package a;
|
||||
|
||||
public class A {
|
||||
protected void a() {
|
||||
|
||||
}
|
||||
}
|
||||
package b;
|
||||
|
||||
import a.A;
|
||||
|
||||
public class B extends A {
|
||||
protected void b() {
|
||||
a();
|
||||
}
|
||||
}
|
||||
package c;
|
||||
|
||||
import b.B;
|
||||
|
||||
public class C extends B {
|
||||
protected void c() {
|
||||
a();
|
||||
}
|
||||
}
|
||||
|
||||
### 接口不能定义protected方法 ###
|
||||
|
||||
很多人认为可以在接口中定义`protected`方法。如果你这么做的话，编译器很
|
||||
快就会毫不留情地给你报错。顺便说下，这也就是我为什么认为允许`public`关键字在接口
|
||||
中是一个技术错误，它会让人觉得还可以写其他访问类型似的。
|
||||
|
||||
|
||||
|
||||
private是一种新的public
|
||||
|
||||
如果你还想在一个接口的方法中声明protected方法,你可能还不理解封装的含义。
|
||||
### 此private非彼private ###
|
||||
|
||||
私有变量和方法在编译单元内是可见的。如果这听起来太神秘的话，换种说法：几
|
||||
乎就是在同一个Java文件中。这比“在它们被定义的类中”听起来好理解些。它们在
|
||||
同一编译单元的类和接口中也是可见的。嵌套类可以看到类中封装的私有字段和
|
||||
方法。然而，当前封闭类也可以看到该类下任何深度下类中的私有方法和字段。
|
||||
|
||||
package a;
|
||||
|
||||
class Private {
|
||||
private class PrivateInPrivate {
|
||||
private Object object;
|
||||
}
|
||||
|
||||
Object m() {
|
||||
return new PrivateInPrivate().object;
|
||||
}
|
||||
}
|
||||
|
||||
后者并不广为人知,事实上也很少有用到。
|
||||
|
||||
### Private是类的访问级别而不是对象 ###
|
||||
|
||||
如果你可以访问一个变量或方法，那么不管它属于哪个对象你都可以访问它。如
|
||||
果`this.a`可以访问到，那`another.a`也可以访问到，只要它们是同一个类的
|
||||
实例。同一个类的实例对象可以随意调用其他实例的变量或方法。不过这样的代
|
||||
码一般都没有意义。现实生活中异常是`equals()`(由Eclipse生成， 15 - 18行)：
|
||||
|
||||
package a;
|
||||
|
||||
public class PrivateIsClass {
|
||||
private Object object;
|
||||
|
||||
@Override
|
||||
public boolean equals(Object obj) {
|
||||
if (this == obj)
|
||||
return true;
|
||||
if (obj == null)
|
||||
return false;
|
||||
if (getClass() != obj.getClass())
|
||||
return false;
|
||||
PrivateIsClass other = (PrivateIsClass) obj;
|
||||
if (object == null) {
|
||||
if (other.object != null)
|
||||
return false;
|
||||
} else if (!object.equals(other.object))
|
||||
return false;
|
||||
return true;
|
||||
}
|
||||
}
|
||||
|
||||
###静态(static)类可能有很多实例 ###
|
||||
|
||||
|
||||
|
||||
访问类型不是对象级别的而是类级别的。
|
||||
|
||||
那些不支持有任何实例的类，通常被称为实用工具类。它们只包含静态字段和静
|
||||
态方法以及唯一的不被该类的任何静态方法调用的私有构造函数。在Java 8中也
|
||||
可以有这样的一个野兽(这个词翻译不通，译者注)在接口中实现，因为Java 8的
|
||||
接口可以有静态方法。我不觉得我们应该使用这个特性而不是实用工具类。我也
|
||||
不完全确信我们应该使用实用工具类。
|
||||
|
||||
静态类总是在另一个类或接口中。它们是嵌套类。他们是静态的,就像静态方法
|
||||
不能访问类的实例方法和字段一样，静态内部类也不能访问嵌入类的实例方法和
|
||||
字段。这是因为内部类没有嵌入类实例的引用（或者说是指针，如果你喜欢这么
|
||||
叫的话）。内部类（内部类,也即非静态嵌套类, 译者注)，而非静态嵌套类, 没
|
||||
有嵌入类的一个实例，它是无法被创建的。每个内部类的实例都具有嵌入类实例
|
||||
的一个引用，因此一个内部类可以访问嵌入类的实例方法和字段。
|
||||
|
||||
因为这个原因，要是没有外部类的一个实例，你就不能创建一个内部类。当然，
|
||||
如果是当前对象，也就是`this`的话，你就可以不需要指定它。在这种情况下你
|
||||
可以使用`new`, 在这种情况下,也就是`this.new`的简式。在一个静态的环境中
|
||||
,例如从一个静态方法，你必须指定内部类应该创建哪个封闭类的实例。见第10
|
||||
行:
|
||||
|
||||
package a;
|
||||
|
||||
class Nesting {
|
||||
static class Nested {}
|
||||
class Inner {}
|
||||
void method(){
|
||||
Inner inner = new Inner();
|
||||
}
|
||||
static void staticMethod(){
|
||||
Inner inner = new Nesting().new Inner();
|
||||
}
|
||||
}
|
||||
|
||||
### 匿名类只能访问final变量 ###
|
||||
|
||||
|
||||
|
||||
变量必须是有效的final
|
||||
|
||||
当一个匿名类被定义在一个方法中,它可以访问局部变量如果该变量是`final`的
|
||||
。但这说的有点模糊。它们不得不声明成final,他们还必须是有效final。这也
|
||||
是Java 8中发布的一些特性。你不需要声明这些变量为`final`型，但它们仍然
|
||||
必须是有效的`final`。
|
||||
|
||||
|
||||
|
||||
Java 8并不要求`final`，只要求有效final.
|
||||
|
||||
为什么你需要对一些东西声明`final`,当它被检查必须是这样的。就像方法的参
|
||||
数。它们也必须是`final`的。你说这不是Java所必须的吗?嗯,你是对的。这只
|
||||
是一个良好的编程风格所必须的。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.javacodegeeks.com/2014/11/some-sentences-about-java.html
|
||||
|
||||
作者：[Peter Verhas][a]
|
||||
译者：[a598799539](https://github.com/a598799539)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.javacodegeeks.com/author/peter-verhas/
|
||||
Loading…
Reference in New Issue
Block a user