Java基础一

痛定思痛。 2022-08-02 06:23 139阅读 0赞

# Java语言中有4种访问修饰符 #

--------------------

在Java语言中有4中访问修饰符:**package(默认)**、**private**、**public**和**protected**。

1.  **package**是默认的保护模式，又加做包访问，没有任何修饰符时就采用这种保护模式。包访问允许域和方法被同一个包内任何类的任何方法访问。（包内访问）。
2.  **private**标识得访问模式，表示私有的域和方法只能被同一个类中的其他方法访问，实现了数据隐藏；必要时，可以通过方法访问私有变量.（类内访问）。
3.  **public**修饰符用于暴露域和方法，以便在类定义的包外部能访问它们。对包和类中必要的接口元素，也需要使用这个级别；main()方法必须是public的，toString()方法也必须是public的。一般不会用public暴露一个域，除非这个域已经被声明为final。（跨包访问）。
4.  **protected**修饰符提供一个从包外部访问包(有限制)的方法。在域和方法前增加protected修饰符不会影响同一个包内其他类的方法对它们的访问。要从包外部访问包(其中含有protected成员的类)，必须保证被访问的类是带有protected成员类的子类。也就是说，希望包中的一个类被包之外的类继承重用时，就可以使用这个级别。一般应该慎用。（包中类被包外类继承慎用）。

# Java中Equals方法使用总结 #

--------------------

## 什么时候应当重写对象的equals方法？ ##

--------------------

一般在我们需要进行**值比较**的时候，是需要重写对象的equals方法的。而例外情况在《effective java》的第7条“在改写equals的时候请遵守通用约定”中清楚描述了。

我们知道，在Java中，每个对象都继承于Object。如果不重写，则默认的equals代码如下所示：

public boolean euqals(Object obj){
        return this == obj;
    }

由上面的代码可以看出，equal默认是使用“==”来判断两个对象是否相等。两个对象使用“==”比较的是**对象的地址**，只有两个引用指向的对象相同的时候，“==”才返回true。所以，在开头的例子中，就需要重写equals方法，让两个对象有equals的时候。

## 如何重写equals？ ##

--------------------

首先，当改写equals方法时，需要保证满足它的通用约定。这些约定如下所示：

> 自反性，对于任意的引用值x,x.equals(x)一定为true。
> 
> 对称性，对于任意的引用值x和y，当且仅当y.equals(x)时，x.equals(y)也一定返回true。
> 
> 传递性，对于任意的引用值x,y,z。如果x.equals(y)返回true，y.euqals(z)返回true，则x.equals(z)也返回true。
> 
> 一致性，对于任意的引用值x和y，如果用于equals比较的对象信息没有修改，那么，多次调用x.equals(y)要么一致返回true,要么一致返回false。
> 
> 非空性，所有的对象都必须不等于null。

其实我觉的一个简单的方法是参照String的equals方法即可，官方出版，满足各种要求。其代码如下所示

public boolean equals(Object anObject) {
        if (this == anObject) {
            return true;
        }
        if (anObject instanceof String) {
            String anotherString = (String)anObject;
            int n = count;
            if (n == anotherString.count) {
                char v1[] = value;
                char v2[] = anotherString.value;
                int i = offset;
                int j = anotherString.offset;
                while (n– != 0) {
                    if (v1[i++] != v2[j++])
                        return false;
                }
                return true;
            }
        }
        return false;
    }

函数的解释如下所示：

1.  使用==检查“实参是否是指向对象的一个引用”。
2.  使用instanceof检查实参是否和本对象同类，如果不同类，就不相等。
3.  将实参转换为正确的类型。
4.  根据类的定义，检查实现此对象值相等的各个条件。

更详细的信息，还是请看《effective java》的第7条“在改写equals的时候请遵守通用约定”。

## 修改equals时需要注意什么？ ##

--------------------

**若修改equals方法，也请修改hashCode方法**

首先这个是语言的一个[约定][Link 1]，这么做的一个原因是当此对象作为哈希容器的元素时，需要依赖hashCode,对象默认的hashCode是返回一个此对象特有的hashCode，不同的对象的hashCode返回值是不一样的，而哈希容器处理元素时，是按照对象的哈希值将对象分配到不同的桶中，若我们不重写对象的hashCode,那么值相等的对象产生的哈希值也会不同，这样当在哈希容器中查找时，会找不到对应的元素。

更详细的信息请看《effective Java》的第8条“改写equals时总是要改写hashCode”。

**重写时保证函数声明的正确**

请注意equals的声明是

public boolean equals(Object obj)

参数类型是Object,如果参数类型是此对象类型的话，如下：

class Point{
    final int x;
    final int y;
    public void Point(int x, int y)
        this.x = x;
        this.y = y;
    }
    public boolean euqals(Point obj){
             return (this.x == obj.x && this.y == obj.y);
        }
    }

下面代码执行是按照我们的预期执行的。

Point a(1, 2);
    Poinr b(1, 2);
    System.out.println(a.equals(b));// 输出true

但是如果将类A放入容器中，则会出问题

import java.util.HashSet;
    
    HashSet<Point> coll = new HashSet<Point>();
    coll.add(a);
    System.out.println(coll.contains(b));// 输出false

这是由于HashSet中的contains方法中调用的是equals(**Object** obj)，而Point中的equals(Object obj)仍是Object的equals，这个方法在前面已经说过了，比较的是对象的地址，所以在coll中调用contains(b)时，当然得不到true。

**当有继承关系时注意equals的正确**

当一个类重写equals方法后，另一个类继承此类，此时，可能会违反前面说到的对称性，代码如下所示：

public class ColoredPoint extends Point {
         
        private final Color color;
        public ColoredPoint(int x, int y, Color color) {
            super(x, y);
            this.color = color;
        }
    
        @Override 
        public boolean equals(Object other) {
            boolean result = false;
            if (other instanceof ColoredPoint) {
                ColoredPoint that = (ColoredPoint) other;
                result = (this.color.equals(that.color) && super.equals(that));
            }
            return result;
        }
    }

当我们作比较时

Point p = new Point(1, 2);
    ColoredPoint cp = new ColoredPoint(1, 2, Color.RED);
    System.out.println(p.equals(cp)); //输出ture
    System.out.println(cp.equals(p)); //输出false

原因是当调用Point.equals的时候，只比较了Point的x和y坐标，同时ColoredPoint也是Point类型，所以上面第三行代码相等，而调用ColoredPoint的时候，Point不是ColoredPoint类型，这样就导致第四行代码输出false。

若我们忽略Color的信息来比较呢，例如将ColoredPoint的equals方法改为：

@overwrite
    public boolean equals(Object obj){
        if((obj instanceof Point)){
            return false;
        }
    
        if(!(obj instanceof ColoredPoint)){
            return obj.equals(this);
        }
    
        return super.equals(obj) && ((ColoredPoint)obj).color == color;
    }

这样就保证了对称性，但是却违反了传递性，即下面的情况：

ColoredPoint cp1 = new ColoredPoint(1, 2, Color.RED);
    Point p = new Point(1, 2);
    ColoredPoint cp2 = new ColoredPoint(1, 2, Color.BLUE);
    System.out.println(cp1.equals(p)); //true
    System.out.println(p.equals(cp2)); //true
    System.out.println(cp1.equals(cp2)); //false

面对这种情况，大致有两种解决方案，一种[酷壳的文章–如何在Java中避免equals方法的隐藏陷阱][Java_equals]的最后一条，断绝了Point和ColoredPoint相等的可能，这是一种处理方法，认为Point和ColoredPoint是不同的。另一种方法是effective Java上提出的，**使用聚合而不是继承**，将Point作为ColoredPoint的一个成员变量。目前我倾向于这种方法，因为聚合比继承更灵活，耦合更低。这种方法的代码如下所示：

class ColoredPoint{
        private final Point point;
        private final Color color;
    
        public Point asPoint(){
            return point;
        }
    
        public boolean equals(Object obj){
            boolean ret = false;
            if(obj instanceof ColoredPoint){
                ColoredPoint that = (ColoredPoint)obj;
                ret = that.point.equals(point) && color.equals(that.color);
            }
            return ret;
        }
    }

当ColoredPoint需要比较坐标时，可以调用asPoint方法来转化为坐标进行比较。其他情况比较坐标和颜色，这样就可以解决上面关于对称性和传递性的问题了。

## 参考 ##

--------------------

[Java中Equals使用总结][Java_Equals]

# 依赖注入 #

--------------------

在面向对象编程中，我们经常处理处理的问题就是解耦，程序的耦合性越低表明这个程序的可读性以及可维护性越高。控制反转(Inversion of Control或IoC)就是常用的面向对象编程的设计原则，使用这个原则我们可以降低耦合性。其中依赖注入是控制反转最常用的实现。

## 什么是依赖 ##

--------------------

依赖是程序中常见的现象，比如类Car中用到了GasEnergy类的实例energy，通常的做法就是在Car类中显式地创建GasEnergy类的实例，并赋值给energy。如下面的代码

interface Energy {
    
    }
    
    class GasEnergy implements Energy {
    
    }
    
    class Car {
      Energy energy = new GasEnergy();
    }

## 存在问题 ##

--------------------

*  类Car承担了多余的责任，负责energy对象的创建，这必然存在了严重的耦合性。举一个现实中的例子，一辆汽车使用哪种能源不是由汽车来决定，而是由汽车制造商（CarMaker）来决定，这是汽车制造商的责任。
 *  可扩展性，假设我们想修改能源为电动力，那么我们必然要修改Car这个类，明显不符合开放闭合原则。
 *  不利于单元测试。

## 依赖注入 ##

--------------------

依赖注入是这样的一种行为，在类Car中不主动创建GasEnergy的对象，而是通过外部传入GasEnergy对象形式来设置依赖。 常用的依赖注入有如下三种方式

### 构造器注入 ###

--------------------

将需要的依赖作为构造方法的参数传递完成依赖注入。

class Car {
      Energy mEnergy;
      public Car(Energy energy) {
          mEnergy = energy;
      }
    }

### Setter方法注入 ###

--------------------

增加setter方法，参数为需要注入的依赖亦可完成依赖注入。

class Car {
      Energy mEnergy;
    
      public void setEnergy(Energy energy) {
          mEnergy  = energy;
      }
    }

### 接口注入 ###

--------------------

接口注入，闻其名不言而喻，就是为依赖注入创建一套接口，依赖作为参数传入，通过调用统一的接口完成对具体实现的依赖注入。

interface EnergyConsumerInterface {
      public void setEnergy(Energy energy);
    }
    
    class Car implements EnergyConsumerInterface {
      Energy mEnergy;
    
      public void setEnergy(Energy energy) {
          mEnergy  = energy;
      }
    }

接口注入和setter方法注入类似，不同的是接口注入使用了统一的方法来完成注入，而setter方法注入的方法名称相对比较随意。

## 框架取舍 ##

--------------------

依赖注入有很多框架，最有名的就是Guice，当然Spring也支持依赖注入。Guice采用的是运行时读取注解，通过反射的形式生成依赖并进行注入。这种形式不太适合Android移动设备，毕竟这些操作都在运行时处理，对性能要求较高。

Dagger则是Android开发适合的依赖注入库，其同样采用类注解的形式，不同的是它是在编译时生成辅助类，等到在运行时使用生成的辅助类完成依赖注入。

## 参考 ##

--------------------

[说说依赖注入][Link 2]

# String,StringBuffer与StringBuilder的区别 #

--------------------

**String 字符串常量**  
**StringBuffer 字符串变量（线程安全）**  
**StringBuilder 字符串变量（非线程安全）**

## String 类型和 StringBuffer 类型的主要性能区别 ##

--------------------

**String 是不可变的对象**, 因此在每次对 String 类型进行改变的时候其实都等同于生成了一个新的 String 对象，然后将指针指向新的 String 对象，所以经常改变内容的字符串最好不要用 String ，因为每次生成对象都会对系统性能产生影响，特别当内存中无引用对象多了以后， JVM 的 GC 就会开始工作，那速度是一定会相当慢的。

而如果是使用 StringBuffer 类则结果就不一样了，每次结果都会对 StringBuffer 对象本身进行操作，而不是生成新的对象，再改变对象引用。所以在一般情况下我们推荐使用 StringBuffer ，特别是字符串对象经常改变的情况下。而在某些特别情况下， String 对象的字符串拼接其实是被 JVM 解释成了 StringBuffer 对象的拼接，所以这些时候 String 对象的速度并不会比 StringBuffer 对象慢，而特别是以下的字符串对象生成中， String 效率是远要比 StringBuffer 快的：

String S1 = “This is only a” + “ simple” + “ test”;
    
     StringBuffer Sb = new StringBuffer(“This is only a”).append(“ simple”).append(“ test”);

你会很惊讶的发现，生成 String S1 对象的速度简直太快了，而这个时候 StringBuffer 居然速度上根本一点都不占优势。其实这是 JVM 的一个把戏，在 JVM 眼里，这个  
`String S1 = “This is only a” + “ simple” + “test”`; 其实就是：  
`String S1 = “This is only a simple test”`; 所以当然不需要太多的时间了。但大家这里要注意的是，如果你的字符串是来自另外的 String 对象的话，速度就没那么快了，譬如：

String S2 = “This is only a”;
    String S3 = “ simple”;
    String S4 = “ test”;
    String S1 = S2 +S3 + S4;

这时候 JVM 会规规矩矩的按照原来的方式去做。

[为什么Java字符串是不可变对象？][Java]

## StringBuffer ##

--------------------

**在大部分情况下 StringBuffer > String**

Java.lang.StringBuffer线程安全的可变字符序列。一个类似于 String 的字符串缓冲区，但不能修改。虽然在任意时间点上它都包含某种特定的字符序列，但通过某些方法调用可以改变该序列的长度和内容。  
可将字符串缓冲区安全地用于多个线程。可以在必要时对这些方法进行同步，因此任意特定实例上的所有操作就好像是以串行顺序发生的，该顺序与所涉及的每个线程进行的方法调用顺序一致。

StringBuffer 上的主要操作是 append 和 insert 方法，可重载这些方法，以接受任意类型的数据。每个方法都能有效地将给定的数据转换成字符串，然后将该字符串的字符追加或插入到字符串缓冲区中。append 方法始终将这些字符添加到缓冲区的末端；而 insert 方法则在指定的点添加字符。

例如，如果 z 引用一个当前内容是“start”的字符串缓冲区对象，则此方法调用 z.append(“le”) 会使字符串缓冲区包含“startle”，而 z.insert(4, “le”) 将更改字符串缓冲区，使之包含“starlet”。

## java.lang.StringBuilder ##

--------------------

**在大部分情况下 StringBuilder > StringBuffer**

java.lang.StringBuilder一个可变的字符序列是5.0新增的。此类提供一个与 StringBuffer 兼容的 API，但不保证同步。该类被设计用作 StringBuffer 的一个简易替换，用在字符串缓冲区被单个线程使用的时候（这种情况很普遍）。如果可能，建议优先采用该类，因为在大多数实现中，它比 StringBuffer 要快。两者的方法基本相同。

## 参考 ##

--------------------

[String，StringBuffer与StringBuilder的区别][String_StringBuffer_StringBuilder]

[Link 1]: http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode%28%29
[Java_equals]: http://coolshell.cn/articles/1051.html
[Java_Equals]: http://www.codeceo.com/article/java-equals-usage.html
[Link 2]: http://droidyue.com/blog/2015/06/13/talk-show-about-dependency-injection/?comefrom=http://blogread.cn/news/
[Java]: http://www.codeceo.com/article/why-java-string-class-static.html
[String_StringBuffer_StringBuilder]: http://blog.csdn.net/rmn190/article/details/1492013