簡體   English   中英

是否有必要在Java中深度復制數組?

[英]Is it necessary to deep copy an array in java?

據我所知和研究,Java中的數組不是對象,而是引用類型。 我的疑問是,當我想返回一個數組時,我應該使用例如clone()方法返回一個深拷貝(就像您對一個對象所做的那樣clone() ,還是可以像返回一個簡單的數組那樣返回計數數組的變量?用get方法輸入變量(即int還是double)? 為了澄清,我將插入一個示例代碼來揭示這種情況:

public class List
{
    // Instance Variables ----------
    private int[] list1;
    private int[] list2;

   // Constructors ----------
   public List()
   {
     list1 = new int[0]; list2 = new int[0];
   }
   public List(List x)
   {
       list1 = x.getList1();
       list2 = x.getList2();

    }

    // Get methods
    public int[] getList1()
    {
        return list1;
    }

    public int[] getList2()
    {
        return list2;
    }

    // Set methods
    public void setList1(int size)
    {
        list1 = new int[size];
    }

     public void setList2(int size)
    {
        list2 = new int[size];
    }
      // Compare reference between an array and the instance variables
      public boolean equals (int[] x)
    {
        if ( x == list1 || x == list2)
        return true;
        else
        return false;
    }
}

現在,我有一個TestClass,它的使用類List是這樣的:

List listx = new List();
int[] listy = listx.getList2();
boolean test = listx.equals(listy);
System.out.printf("Result: " + test );

如此說來,當我使用equals方法查看兩個數組是否共享相同的引用或地址時,總是得到正確的結果! 我是否以此打破OOP基本原理? 我會因為listy指向listx實例變量而失去控制權嗎? 好吧,我真的對此感到困惑,我不知道這是否正確(將數組作為非實例化的類),或者是否應該使用其他方法使用Clone方法發送某種淺層的Deepcopy來確保所有基本的OOP原則已得到滿足,用這個原則,我的意思是說,類方法只能由API訪問,而內部狀態(實例變量)只能由類本身訪問。

如果希望方法的調用者能夠修改原始數組,則無需執行復制操作。 否則,您會這樣做。

檢查equals()的實現。 它應該是自反的,對稱的和可傳遞的 ,而您的情況並非如此。

您沒有違反OOP主體。 但是,您正在打破函數式編程的原理。 功能編程將訪問泄漏視為失去控制。

無論您是否要練習函數式編程,都由您決定,Java對此不采取任何立場。

您可能要考慮不要泄漏此特定類的訪問權限是否重要。 如果您發現不要泄漏訪問權限很重要,請將該類設為不可變的。

您還可以保護實例變量。 在這種情況下,變量的任何可能更改都必須由實例類處理。 但是,可以從單獨的上下文中修改實例,並導致失去控制。 因此,函數式編程僅允許不可變的類。

是否要深層復制取決於您的用例。 如果您的元素是不可變的,通常不需要進行深層復制。 如果可以更改,則取決於您是否要在副本的接收方中查看更改。 通常,當您想要給定數據的快照時,必須深度復制它。 但是請記住,在大多數情況下,數組不是API的好參數或返回類型。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM