Предположения о событии повышения

Представьте себе следующий класс:Предположения о событии повышения

class A 
{ 
    public event EventHandler AnyEvent; 
}

Вы создаете экземпляр класса A, и приложить некоторые обработчиков событий. Теперь, если AnyEvent будет поднят, я бы не стал предполагать, что обработчики событий выполняются в другом потоке, чем поток, который я создал. Это было бы очень важно, если бы вы создали объект в потоке GUI, а обработчик событий выполнял операции с элементами GUI. Это заставит меня использовать соответствующие шаблоны вызова.

Это действительно становится злом, если вы используете интерфейсы, определяющие события:

interface B 
{ 
    event EventHandler SomeEvent; 
}

Теперь одна реализация может поднять событие с оригинальной резьбой, следующий из второго потока. Это может привести к тому, что ваше приложение будет успешно работать с ним и не выполнит другую реализацию.

Я думаю, что кодирование всегда должно быть прозрачным - это не так! И если я не создаю другой поток, я не предполагаю, что мои методы выполняются из любого другого, кроме моего ,.

Есть ли какие-либо аспекты, которые я не рассматривал? Любое, что лишало бы моего предположения?

источник

2011-12-23 Matthias

Threading - ответственность потребителя класса, а не автора класса, поэтому ваше предположение неверно.

Следует полагать, что класс не является потокобезопасным, если только он не документирован как потокобезопасный. Даже большинство встроенных классов .NET не являются потокобезопасными, если не говорят, что они есть.

Это зависит от потребителя класса, который должен знать о резьбе.

источник

2011-12-23 23:28:26 Davy8

Хорошо, я никогда не слышал, что изначально я должен предположить, что классы не являются потокобезопасными. Однако, что вы думаете о интерфейсной части моего вопроса? – Matthias

К сожалению, это не то, что может быть реализовано интерфейсом. Лучшее, что вы можете сделать, это документировать интерфейс определенным образом и предположить, что исполнитель будет следовать рекомендациям. Абстракции будут протекать http://www.joelonsoftware.com/articles/LeakyAbstractions.html – Davy8

Нет никакой магии с событиями. События обрабатываются в потоке, который их повышает. Он не имеет ничего общего с потоком, который создает объект.

источник

2011-12-23 23:14:20

это не вопрос. – Matthias

Затем вам нужно уточнить вопрос. Вы также должны попытаться разбить его, чтобы выявить, какие ложные предположения содержат ваш вопрос. –

Я думаю, что я уже сделал это. Возможно, вам стоит снова прочитать вторую часть, касающуюся интерфейса. – Matthias

Обратные вызовы обработчика событий в той же теме, что и событие.

источник

2011-12-23 23:16:18 Reddog

не вопрос. – Matthias

Вызывающие события просто вызывают некоторый метод (или набор методов) с использованием механизма, такого как указатели на функции.

События полностью не обращают внимания на нить, которая их прикрепляет, и не имеют никакой другой информации, которая могла бы привести к правильному использованию методов в правой нити.

Возможно, вы используете свои предположения из COM-дней?

источник

2011-12-23 23:31:06

Предположения о событии повышения

ответ

Смежные вопросы