.NET架構-引用陷阱的代碼執行個體分享

來源:互聯網
上載者:User
1 值相等,對象便預設相等?
.net 容器中判斷某個參考型別存在的預設規則是什嗎? 判斷指標值是否相等。

        private static List<int> list;                static void Main(string[] args)        {                    //建立執行個體instance1            MyObject instance1 = new MyObject();            instance1.Value = 10;                        //建立list            List<MyObject> list = new List<MyObject>();                        //引用執行個體instance1            list.Add(instance1);                        //建立執行個體:instance2            MyObject instance2 = new MyObject();                        //賦值為instance1.Value            instance2.Value = instance1.Value;               }    }

  用到的Model類:

            public class MyObject            {                public int Value { get; set; }            }

下面做1個測試:

            //即便Value相等,instance2與instance1的記憶體位址不相等!            bool isExistence1 = list.Contains(instance2);            //isExistence1 : false;

  這個測試結果是false,因為它們指向不同的記憶體位址,儘管值相等,這便是“值相等,對象不相等”的情況。
  
  參考型別若是想根據其中的某個屬性值判斷是否相等,那麼需要實現IEquatable介面!
若想繼續看 根據值是否相等 判斷對象是否相等,請參考文章:C# 容器,介面類,效能

2 引用陷阱?

  一個對象引用另一個對象,某一個改變,另一個便改變。例如,合并兩個字典,合并結果是對的,但是卻意外改變了原對象。

在這裡舉一個例子:

            var dict1 = new Dictionary<string, List<string>>();            dict1.Add("qaz",new List<string>(){"100"});//含有qaz鍵            dict1.Add("wsx",new List<string>(){"13"});            var dict2 = new Dictionary<string, List<string>>();            dict2.Add("qaz", new List<string>() { "11" });//也含有qaz鍵            dict2.Add("edc", new List<string>() { "17" });            //合并2個字典到dict                        var dictCombine = new Dictionary<string, List<string>>();            foreach (var ele in dict1) //拿到dict1            {               dictCombine .Add(ele.Key,ele.Value);             }            foreach (var ele in dict2) //拿到dict2            {                if(dictCombine.ContainsKey(ele.Key))//檢查重複                   dictCombine [ele.Key].AddRange(ele.Value);                 else                {                    dictCombine .Add(ele.Key,ele.Value);                 }            }

  dictCombine的結果正確,{“qaz”, “100”和”11”}, {“wsx”,”13”},{“edc”,”17”}
但是dict1的結果怎麼樣? 被改變了! dict1意外變為了 {“qaz”, “100”和”11”}, {“wsx”,”13”}。 正確的合并,不應該改變dict1!

分析原因

  dictCombine首先添加了dict1的索引值,也就是dictCombine的索引值都引用了dict1的索引值; 接下來,再合并dict2時,首先判斷dictCombine中是否包含了dict2的鍵,如果包含,則再往dictCombine的索引值中添加, 值又引用了同一個對象,也就是在dict1的鍵中添加了這個值。dictCombine[ele.Key]和dict1[ele.Key]引用是否相等的驗證:

bool flag = object.ReferenceEquals(dictCombine[ele.Key], dict1[ele.Key]);//true

正解

  避免dictCombine[ele.Key]和dict1[ele.Key]引用相等!!!

Dictionary<string, List<string>> dict = new Dictionary<string, List<string>>();            //先把鍵都合并到dictCombine中,值都是新建立的            foreach (var key in dict1.Keys)            {                if (!dictCombine.ContainsKey(key))                    dictCombine.Add(key, new List<string>());            }            foreach (var key in dict2.Keys)            {                if (!dictCombine.ContainsKey(key))                    dictCombine.Add(key, new List<string>());            }     //分別將值添加進去            foreach (var ele in dict1)            {                dictCombine[ele.Key].AddRange(ele.Value);            }            foreach (var ele in dict2)            {                dictCombine[ele.Key].AddRange(ele.Value);            }

dictCombine合并結果是正確的,並且dict1,dict2都未改變!

總結
   利用引用相等,帶來了很多好處,比如函數間的引用傳值(by reference)。但是,如果運用不當,也會給我們帶來一些不必要的麻煩。  

3 引用不當破壞封裝?
  
  如果將封裝的類內私人欄位作為介面方法的傳回值,這種做法會破壞類的封裝,是特別容易忽視的一個問題。如果忽視這個問題,可能會出現莫名其妙的問題。
  
  如下面的代碼所示,
  

public class TestPrivateEncapsulate{    private List<object> _refObjs;    public List<object> GetRefObjs()    {        _refObjs = new List<object>();        ...        ...       //其他邏輯處理計算出來的_refObjs={1,4,2};            return _refObjs; //返回私人欄位    }    public object GetSumByIterRefObjs()    {        if (_refObjs == null)            return null;        foreach (var item in _refObjs)        {            ...//處理邏輯        }    }  }

  現在使用剛才寫的類TestPrivateEncapsulate,我們先建立一個執行個體,

TestPrivateEncapsulate test = new TestPrivateEncapsulate();

  然後調用:

List<object> wantedObjs = test.GetRefObjs();

  返回的預期wantedObjs應該有3個整形類型的元素,1,4,2。

  繼續:

List<object> sol = wantedObjs; //我們將sol指向wantedObjssol.Add(5); //加入元素5

  等我們想回過頭來計算,原來wantedObjs的元素求和:

test.GetSum();

  我們意外得到了12,而不是預想中的7。這是為什麼呢?

  仔細分析後發現,我們在用戶端調用,sol.Add(5)後,間接的修改了TestPrivateEncapsulate內變數:_refObjs,它由{1,4,2}修改為了{1,4,2,5}。

  私人變數在用戶端被修改了!這便是介面返回私人變數帶來的副作用!

  正解:

    // 將原來的公有變為私人    private List<object> getRefObjs()    {        _refObjs = new List<object>();        ...        ...       //其他邏輯處理計算出來的_refObjs={1,4,2};            return _refObjs; //返回私人欄位    }    //只帶唯讀屬性    public RefObjs    {        get         {            getRefObjs();                        return _refObjs;         }    }

  設定一個公有欄位,僅帶有唯讀屬性,將原來的公有方法GetRefObjs變為私人方法getRefObjs,這樣在用戶端是不可能修改私人欄位的!

總結
對象的屬性值都等,但對象引用不一定相等;
兩個或多個對象都引用某個對象,若這個對象被修改,則所有引用者屬性值也被修改;
成員返回封裝的引用變數,會破壞封裝。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.