CrossDomainObject,
INotifier
{
private readonly object _syncObject = new object();
private List<object> _events = new List<object>();
public virtual IEnumerable<object> GetEvents()
{
lock (_syncObject)
return _events;
}
public void Add(object events)
{
lock (_syncObject)
{
_events = new List<object>(_events); // Creates new, old value returned outside
_events.Add(events); //初始化带参数,然后又添加,为什么?
}
}
public bool Remove(object events)
{
lock (_syncObject)
{
_events = new List<object>(_events); // Creates new, old value returned outside
return _events.Remove(events); //这里同样不理解,直接Remove或者new不可以吗?
}
}
}
13 个解决方案
#1
头脑烧坏了的之后写的代码,并且使用 object 弱类型增强了头脑烧坏的风险。
你这个代码出处在那里?贴出来地址。
你这个代码出处在那里?贴出来地址。
#2
代码不全,看不出 _events = new List<object>(_events); 的必要性
可能是为了切断某些可能存在的引用关系吧
可能是为了切断某些可能存在的引用关系吧
#3
这里看上去似乎是想以枚举为实例化参数,然后又从枚举中以对象方式去Remove。
不过这类若类型代码其实就是各种故意设计的陷阱,我们写代码都是尽量清晰简单,故意用弱类型就是糟粕。
#4
代码出处 https://github.com/Nirklav/TCPChat
#5
P2P多用户客户端服务器语音聊天
#6
_events = new List<object>(_events);
-》不明觉厉啊
-》不明觉厉啊
#7
我并不认为 这两个方法会一起用,原作者逻辑 应该只是将这个 作为了一个业务逻辑,并没得有什么不妥。。。
#8
_events = new List<object>(_events)
本身 _events就是一个弱类型列表,调用的时候无非相当于创建了一个新的列表,并且把原始的值赋值给新的列表。
_events.Add(events);
新方法的参数传递就来,加入列表。
感觉没什么不妥。。
本身 _events就是一个弱类型列表,调用的时候无非相当于创建了一个新的列表,并且把原始的值赋值给新的列表。
_events.Add(events);
新方法的参数传递就来,加入列表。
感觉没什么不妥。。
#9
重点是
这两行代码,这里是故意弄了个陷阱。
_events = new List<object>(_events); // Creates new, old value returned outside
return _events.Remove(events); //这里同样不理解,直接Remove或者new不可以吗?
这两行代码,这里是故意弄了个陷阱。
#10
重点是 Remove 部分而不是 Add 部分。
这类数据结构其实并不高效(使用一个 static 的链表或者字典才高效),而弱类型的这种语法,则增加了诡异的、动态解析成分。其实功能非常灵活的代码完全可以写成强类型的非常明白的,而并不是越用弱类型越好。
这类数据结构其实并不高效(使用一个 static 的链表或者字典才高效),而弱类型的这种语法,则增加了诡异的、动态解析成分。其实功能非常灵活的代码完全可以写成强类型的非常明白的,而并不是越用弱类型越好。
#11
先不说这个代码的效率如何,这段代码的目标是为了保护外部调用者遍历list的安全性。
关键相关代码看这里:
public virtual IEnumerable<object> GetEvents()
{
lock (_syncObject)
return _events;
}
外部调用者获取了_events对象后已经出了lock保护,所以他在add和remove的时候创建了一个新的_events来存储数据,保证在被调用者获取的_events不被修改
关键相关代码看这里:
public virtual IEnumerable<object> GetEvents()
{
lock (_syncObject)
return _events;
}
外部调用者获取了_events对象后已经出了lock保护,所以他在add和remove的时候创建了一个新的_events来存储数据,保证在被调用者获取的_events不被修改
#12
明白了,主要是确保线程安全。
#13
这种写法海真的没有见过
#1
头脑烧坏了的之后写的代码,并且使用 object 弱类型增强了头脑烧坏的风险。
你这个代码出处在那里?贴出来地址。
你这个代码出处在那里?贴出来地址。
#2
代码不全,看不出 _events = new List<object>(_events); 的必要性
可能是为了切断某些可能存在的引用关系吧
可能是为了切断某些可能存在的引用关系吧
#3
这里看上去似乎是想以枚举为实例化参数,然后又从枚举中以对象方式去Remove。
不过这类若类型代码其实就是各种故意设计的陷阱,我们写代码都是尽量清晰简单,故意用弱类型就是糟粕。
#4
代码出处 https://github.com/Nirklav/TCPChat
#5
P2P多用户客户端服务器语音聊天
#6
_events = new List<object>(_events);
-》不明觉厉啊
-》不明觉厉啊
#7
我并不认为 这两个方法会一起用,原作者逻辑 应该只是将这个 作为了一个业务逻辑,并没得有什么不妥。。。
#8
_events = new List<object>(_events)
本身 _events就是一个弱类型列表,调用的时候无非相当于创建了一个新的列表,并且把原始的值赋值给新的列表。
_events.Add(events);
新方法的参数传递就来,加入列表。
感觉没什么不妥。。
本身 _events就是一个弱类型列表,调用的时候无非相当于创建了一个新的列表,并且把原始的值赋值给新的列表。
_events.Add(events);
新方法的参数传递就来,加入列表。
感觉没什么不妥。。
#9
重点是
这两行代码,这里是故意弄了个陷阱。
_events = new List<object>(_events); // Creates new, old value returned outside
return _events.Remove(events); //这里同样不理解,直接Remove或者new不可以吗?
这两行代码,这里是故意弄了个陷阱。
#10
重点是 Remove 部分而不是 Add 部分。
这类数据结构其实并不高效(使用一个 static 的链表或者字典才高效),而弱类型的这种语法,则增加了诡异的、动态解析成分。其实功能非常灵活的代码完全可以写成强类型的非常明白的,而并不是越用弱类型越好。
这类数据结构其实并不高效(使用一个 static 的链表或者字典才高效),而弱类型的这种语法,则增加了诡异的、动态解析成分。其实功能非常灵活的代码完全可以写成强类型的非常明白的,而并不是越用弱类型越好。
#11
先不说这个代码的效率如何,这段代码的目标是为了保护外部调用者遍历list的安全性。
关键相关代码看这里:
public virtual IEnumerable<object> GetEvents()
{
lock (_syncObject)
return _events;
}
外部调用者获取了_events对象后已经出了lock保护,所以他在add和remove的时候创建了一个新的_events来存储数据,保证在被调用者获取的_events不被修改
关键相关代码看这里:
public virtual IEnumerable<object> GetEvents()
{
lock (_syncObject)
return _events;
}
外部调用者获取了_events对象后已经出了lock保护,所以他在add和remove的时候创建了一个新的_events来存储数据,保证在被调用者获取的_events不被修改
#12
明白了,主要是确保线程安全。
#13
这种写法海真的没有见过