Home  >  Article  >  Backend Development  >  3 thoughts on C#reference in detail

3 thoughts on C#reference in detail

黄舟
黄舟Original
2017-03-04 10:53:591689browse

1 If the values ​​are equal, the objects will be equal by default?

What are the default rules for determining the existence of a reference type in a .net container? Determine whether pointer values ​​are equal.

        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 class used:

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

Let’s do a test below:

            //即便Value相等,instance2与instance1的内存地址不相等!
            bool isExistence1 = list.Contains(instance2);            //isExistence1 : false;

The result of this test is false because they point to different Memory address, although the values ​​are equal, this is the "values ​​are equal, objects are not equal" situation.
 
If a reference type wants to determine whether it is equal based on one of its attribute values, then it needs to implement the IEquatable interface!
If you want to continue to see whether the objects are equal based on whether the values ​​are equal, please refer to the article: C# container, interface class, performance

2 Reference trap?

 One object refers to another object. When one changes, the other changes. For example, when merging two dictionaries, the merge result is correct, but the original object is accidentally changed.

Here is an example:

            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); 
                }
            }

The result of dictCombine is correct, {"qaz", "100" and "11"}, {"wsx" ","13"},{"edc","17"}
But what about the result of dict1? Been changed! dict1 unexpectedly became {"qaz", "100" and "11"}, {"wsx", "13"}. Correct merge, dict1 should not be changed!

Analysis of reasons

dictCombine first adds the key value of dict1, that is, the key values ​​of dictCombine all refer to the key value of dict1; Next, When merging dict2, first determine whether dictCombine contains the key of dict2. If it does, add it to the key value of dictCombine. The value refers to the same object, that is, this value is added to the key of dict1. Verification of whether dictCombine[ele.Key] and dict1[ele.Key] references are equal:

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

Correct solution

Avoid dictCombine[ele.Key] and dict1[ele .Key] reference equality! ! !

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 merge result is correct, and neither dict1 nor dict2 has changed!

Summary
  Using reference equality brings many benefits, such as reference-to-value (by reference) between functions. However, if used improperly, it will also bring us some unnecessary trouble.​

#3 Improper reference destroys encapsulation?
 
If you use the private field in the encapsulated class as the return value of the interface method, this approach will destroy the encapsulation of the class, especially An issue that is easily overlooked. If you ignore this issue, inexplicable problems may occur.
 
As shown in the following code,
 

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)
        {            ...//处理逻辑
        }
    }  
}

Now using the class TestPrivateEncapsulate just written, we first create an instance,

TestPrivateEncapsulate test = new TestPrivateEncapsulate();

 And then call:

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

The expected wantedObjs returned should have 3 elements of integer type, 1, 4, 2.

Continue:

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

When we want to go back and calculate, the original sum of elements of wantedObjs:

test.GetSum();

We accidentally got 12, not 7 as expected. Why is this?

After careful analysis, we found that after calling sol.Add(5) on the client, we indirectly modified the variable in TestPrivateEncapsulate: _refObjs, which was changed from {1,4,2} to {1,4 ,2,5}.

 Private variables were modified on the client side! This is the side effect of the interface returning private variables!

 Correct answer:

    // 将原来的公有变为私有
    private List<object> getRefObjs()
    {
        _refObjs = new List<object>();        ...
        ...
       //其他逻辑处理计算出来的_refObjs={1,4,2};    
        return _refObjs; //返回私有字段
    }

    //只带只读的属性
    public RefObjs
    {
        get
         {
            getRefObjs();            return _refObjs;
         }
    }

Set a public field with only read-only attributes, and change the original public method GetRefObjs into the private method getRefObjs, so that in It is impossible for the client to modify private fields!

Summarize
The attribute values ​​of the objects are all equal, but the object references are not necessarily equal;
Two or more objects refer to an object. If this object is modified, the attribute values ​​of all referrers are also modified;
Member return Encapsulated reference variables will destroy the encapsulation.

The above is the detailed introduction of the three thoughts of C#reference. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!


Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn