程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> Java總結篇系列:Java泛型詳解

Java總結篇系列:Java泛型詳解

編輯:關於JAVA

Java總結篇系列:Java泛型詳解。本站提示廣大學習愛好者:(Java總結篇系列:Java泛型詳解)文章只能為提供參考,不一定能成為您想要的結果。以下是Java總結篇系列:Java泛型詳解正文


一. 泛型概念的提出(為何須要泛型)?

起首,我們看下上面這段冗長的代碼:

public class GenericTest {

  public static void main(String[] args) {
    List list = new ArrayList();
    list.add("qqyumidi");
    list.add("corn");
    list.add(100);

    for (int i = 0; i < list.size(); i++) {
      String name = (String) list.get(i); // 1
      System.out.println("name:" + name);
    }
  }
}

界說了一個List類型的聚集,先向個中參加了兩個字符串類型的值,隨後參加一個Integer類型的值。這是完整許可的,由於此時list默許的類型為Object類型。在以後的輪回中,因為忘卻了之前在list中也參加了Integer類型的值或其他編碼緣由,很輕易湧現相似於//1中的毛病。由於編譯階段正常,而運轉時會湧現“java.lang.ClassCastException”異常。是以,招致此類毛病編碼進程中不容易發明。

 在如上的編碼進程中,我們發明重要存在兩個成績:

1.當我們將一個對象放入聚集中,聚集不會記住此對象的類型,當再次從聚集中掏出此對象時,改對象的編譯類型釀成了Object類型,但其運轉時類型任然為其自己類型。

2.是以,//1處掏出聚集元素時須要工資的強迫類型轉化到詳細的目的類型,且很輕易湧現“java.lang.ClassCastException”異常。

那末有無甚麼方法可使聚集可以或許記住聚集內元素各類型,且可以或許到達只需編譯時不湧現成績,運轉時就不會湧現“java.lang.ClassCastException”異常呢?謎底就是應用泛型。

二.甚麼是泛型?

泛型,即“參數化類型”。一提到參數,最熟習的就是界說辦法時無形參,然後挪用此辦法時傳遞實參。那末參數化類型怎樣懂得呢?望文生義,就是將類型由本來的詳細的類型參數化,相似於辦法中的變量參數,此時類型也界說成參數情勢(可以稱之為類型形參),然後在應用/挪用時傳入詳細的類型(類型實參)。

看著似乎有點龐雜,起首我們看下下面誰人例子采取泛型的寫法。

public class GenericTest {

  public static void main(String[] args) {
    /*
    List list = new ArrayList();
    list.add("qqyumidi");
    list.add("corn");
    list.add(100);
    */

    List<String> list = new ArrayList<String>();
    list.add("qqyumidi");
    list.add("corn");
    //list.add(100);  // 1 提醒編譯毛病

    for (int i = 0; i < list.size(); i++) {
      String name = list.get(i); // 2
      System.out.println("name:" + name);
    }
  }
}

采取泛型寫法後,在//1處想參加一個Integer類型的對象時會湧現編譯毛病,經由過程List<String>,直接限制了list聚集中只能含有String類型的元素,從而在//2處不必停止強迫類型轉換,由於此時,聚集可以或許記住元素的類型信息,編譯器曾經可以或許確認它是String類型了。

聯合下面的泛型界說,我們曉得在List<String>中,String是類型實參,也就是說,響應的List接口中確定含有類型形參。且get()辦法的前往成果也直接是此形參類型(也就是對應的傳入的類型實參)。上面就來看看List接口的的詳細界說:

public interface List<E> extends Collection<E> {

  int size();

  boolean isEmpty();

  boolean contains(Object o);

  Iterator<E> iterator();

  Object[] toArray();

  <T> T[] toArray(T[] a);

  boolean add(E e);

  boolean remove(Object o);

  boolean containsAll(Collection<?> c);

  boolean addAll(Collection<? extends E> c);

  boolean addAll(int index, Collection<? extends E> c);

  boolean removeAll(Collection<?> c);

  boolean retainAll(Collection<?> c);

  void clear();

  boolean equals(Object o);

  int hashCode();

  E get(int index);

  E set(int index, E element);

  void add(int index, E element);

  E remove(int index);

  int indexOf(Object o);

  int lastIndexOf(Object o);

  ListIterator<E> listIterator();

  ListIterator<E> listIterator(int index);

  List<E> subList(int fromIndex, int toIndex);
}

我們可以看到,在List接口中采取泛型化界說以後,<E>中的E表現類型形參,可以吸收詳細的類型實參,而且此接口界說中,但凡湧現E的處所均表現雷同的接收自內部的類型實參。

天然的,ArrayList作為List接口的完成類,其界說情勢是:

public class ArrayList<E> extends AbstractList<E> 
    implements List<E>, RandomAccess, Cloneable, java.io.Serializable {
  
  public boolean add(E e) {
    ensureCapacityInternal(size + 1); // Increments modCount!!
    elementData[size++] = e;
    return true;
  }
  
  public E get(int index) {
    rangeCheck(index);
    checkForComodification();
    return ArrayList.this.elementData(offset + index);
  }
  
  //...省略失落其他詳細的界說進程

}

由此,我們從源代碼角度明確了為何//1處參加Integer類型對象編譯毛病,且//2處get()到的類型直接就是String類型了。

三.自界說泛型接口、泛型類和泛型辦法

從下面的內容中,年夜家曾經明確了泛型的詳細運作進程。也曉得了接口、類和辦法也都可使用泛型去界說,和響應的應用。是的,在詳細應用時,可以分為泛型接口、泛型類和泛型辦法。

自界說泛型接口、泛型類和泛型辦法與上述Java源碼中的List、ArrayList相似。以下,我們看一個最簡略的泛型類和辦法界說:

public class GenericTest {

  public static void main(String[] args) {

    Box<String> name = new Box<String>("corn");
    System.out.println("name:" + name.getData());
  }

}

class Box<T> {

  private T data;

  public Box() {

  }

  public Box(T data) {
    this.data = data;
  }

  public T getData() {
    return data;
  }

}

在泛型接口、泛型類和泛型辦法的界說進程中,我們罕見的如T、E、K、V等情勢的參數經常使用於表現泛型形參,因為吸收來自內部應用時刻傳入的類型實參。那末關於分歧傳入的類型實參,生成的響應對象實例的類型是否是一樣的呢?

public class GenericTest {

  public static void main(String[] args) {

    Box<String> name = new Box<String>("corn");
    Box<Integer> age = new Box<Integer>(712);

    System.out.println("name class:" + name.getClass());   // com.qqyumidi.Box
    System.out.println("age class:" + age.getClass());    // com.qqyumidi.Box
    System.out.println(name.getClass() == age.getClass());  // true

  }

}

由此,我們發明,在應用泛型類時,固然傳入了分歧的泛型實參,但並沒有真正意義上生成分歧的類型,傳入分歧泛型實參的泛型類在內存上只要一個,即照樣本來的最根本的類型(本實例中為Box),固然,在邏輯上我們可以懂得成多個分歧的泛型類型。

究其緣由,在於Java中的泛型這一概念提出的目標,招致其只是感化於代碼編譯階段,在編譯進程中,關於准確磨練泛型成果後,會將泛型的相干信息擦出,也就是說,勝利編譯事後的class文件中是不包括任何泛型信息的。泛型信息不會進入到運轉時階段。

對此總結成一句話:泛型類型在邏輯上看以算作是多個分歧的類型,現實上都是雷同的根本類型。

四.類型通配符

接著下面的結論,我們曉得,Box<Number>和Box<Integer>現實上都是Box類型,如今須要持續商量一個成績,那末在邏輯上,相似於Box<Number>和Box<Integer>能否可以算作具有父子關系的泛型類型呢?

為了弄清這個成績,我們持續看下上面這個例子:

public class GenericTest {

  public static void main(String[] args) {

    Box<Number> name = new Box<Number>(99);
    Box<Integer> age = new Box<Integer>(712);

    getData(name);
    
    //The method getData(Box<Number>) in the type GenericTest is 
    //not applicable for the arguments (Box<Integer>)
    getData(age);  // 1

  }
  
  public static void getData(Box<Number> data){
    System.out.println("data :" + data.getData());
  }

}

我們發明,在代碼//1處湧現了毛病提醒信息:The method getData(Box<Number>) in the t ype GenericTest is not applicable for the arguments (Box<Integer>)。明顯,經由過程提醒信息,我們曉得Box<Number>在邏輯上不克不及視為Box<Integer>的父類。那末,緣由安在呢?

public class GenericTest {

  public static void main(String[] args) {

    Box<Integer> a = new Box<Integer>(712);
    Box<Number> b = a; // 1
    Box<Float> f = new Box<Float>(3.14f);
    b.setData(f);    // 2

  }

  public static void getData(Box<Number> data) {
    System.out.println("data :" + data.getData());
  }

}

class Box<T> {

  private T data;

  public Box() {

  }

  public Box(T data) {
    setData(data);
  }

  public T getData() {
    return data;
  }

  public void setData(T data) {
    this.data = data;
  }

}

這個例子中,明顯//1和//2處確定會湧現毛病提醒的。在此我們可使用反證法來停止解釋。

假定Box<Number>在邏輯上可以視為Box<Integer>的父類,那末//1和//2處將不會有毛病提醒了,那末成績就出來了,經由過程getData()辦法掏出數據時究竟是甚麼類型呢?Integer? Float? 照樣Number?且因為在編程進程中的次序弗成控性,招致在需要的時刻必需要停止類型斷定,且停止強迫類型轉換。明顯,這與泛型的理念抵觸,是以,在邏輯上Box<Number>不克不及視為Box<Integer>的父類。

好,那我們回過火來持續看“類型通配符”中的第一個例子,我們曉得其詳細的毛病提醒的深條理緣由了。那末若何處理呢?總部能再界說一個新的函數吧。這和Java中的多態理念明顯是違反的,是以,我們須要一個在邏輯上可以用來表現同時是Box<Integer>和Box<Number>的父類的一個援用類型,由此,類型通配符應運而生。

類型通配符普通是應用 ? 取代詳細的類型實參。留意了,此處是類型實參,而不是類型形參!且Box<?>在邏輯上是Box<Integer>、Box<Number>...等一切Box<詳細類型實參>的父類。由此,我們仍然可以界說泛型辦法,來完成此類需求。

public class GenericTest {

  public static void main(String[] args) {

    Box<String> name = new Box<String>("corn");
    Box<Integer> age = new Box<Integer>(712);
    Box<Number> number = new Box<Number>(314);

    getData(name);
    getData(age);
    getData(number);
  }

  public static void getData(Box<?> data) {
    System.out.println("data :" + data.getData());
  }

}

有時刻,我們還能夠聽到類型通配符下限和類型通配符上限。詳細有是怎樣樣的呢?

在下面的例子中,假如須要界說一個功效相似於getData()的辦法,但對類型實參又有進一步的限制:只能是Number類及其子類。此時,須要用到類型通配符下限。

public class GenericTest {

  public static void main(String[] args) {

    Box<String> name = new Box<String>("corn");
    Box<Integer> age = new Box<Integer>(712);
    Box<Number> number = new Box<Number>(314);

    getData(name);
    getData(age);
    getData(number);
    
    //getUpperNumberData(name); // 1
    getUpperNumberData(age);  // 2
    getUpperNumberData(number); // 3
  }

  public static void getData(Box<?> data) {
    System.out.println("data :" + data.getData());
  }
  
  public static void getUpperNumberData(Box<? extends Number> data){
    System.out.println("data :" + data.getData());
  }

}

此時,明顯,在代碼//1處挪用將湧現毛病提醒,而//2 //3處挪用正常。

類型通配符下限經由過程形如Box<? extends Number>情勢界說,絕對應的,類型通配符上限為Box<? super Number>情勢,其寄義與類型通配符下限正好相反,在此不作過量論述了。

五.話外篇

本文中的例子重要是為了論述泛型中的一些思惟而簡略舉出的,其實不必定有實在際的可用性。別的,一提到泛型,信任年夜家用到最多的就是在聚集中,其實,在現實的編程進程中,本身可使用泛型去簡化開辟,且能很好的包管代碼質量。而且還要留意的一點是,Java中沒有所謂的泛型數組一說。

關於泛型,最重要的照樣須要懂得其面前的思惟和目標。

以上就是小編為年夜家帶來的Java總結篇系列:Java泛型詳解的全體內容了,願望對年夜家有所贊助,多多支撐~

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved