Comments 1
Довольно странно, я не понимаю, откуда может появиться NRE.
Ведь типичная причина утечки памяти — класс подписывается на событие и его не может собрать GC, потому что в делегате вызова есть ссылка на класс.
Кусок кода с Monitor кажется неоправданно сложным.
Я бы везде использовал lock, для единообразия.
Да и вообще, можно проще:
Описать отдельные статические делегаты для OnMessageEdit, MessageEdit, MessageReply и т.д.
Подписывайся на них, отписывайся, вызывай как нравится.
За потокобезопасностью следит .NET, используя не блокировки, а lock-free алгоритмы (см. здесь).
И не надо никакой «архитектуры» :)
Ведь типичная причина утечки памяти — класс подписывается на событие и его не может собрать GC, потому что в делегате вызова есть ссылка на класс.
Кусок кода с Monitor кажется неоправданно сложным.
Я бы везде использовал lock, для единообразия.
List<NotifyCollectionChangedEventHandler> copy;
lock (handlersMap[key]) { copy = new List<NotifyCollectionChangedEventHandler>(handlersMap[key]); }
foreach (var handlr in copy) { ... }
Да и вообще, можно проще:
Описать отдельные статические делегаты для OnMessageEdit, MessageEdit, MessageReply и т.д.
Подписывайся на них, отписывайся, вызывай как нравится.
За потокобезопасностью следит .NET, используя не блокировки, а lock-free алгоритмы (см. здесь).
И не надо никакой «архитектуры» :)
0
Sign up to leave a comment.
Red Architecture — красная кнопка помощи для сложных и запутанных систем — часть 3 (многопоточность нам в помощь)