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

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，這樣在用戶端是不可能修改私人欄位的！

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