народ, объясните тупому, почему для событий в .NET выбран именно паттерн void MethodName(object, EventArgs)?
понятно, почему может понадобиться sender, понятно, зачем может понадобиться EventArgs, не понятно почему не передать всё это как object[].
Здравствуйте, andreich78, Вы писали:
A>народ, объясните тупому, почему для событий в .NET выбран именно паттерн void MethodName(object, EventArgs)? A>понятно, почему может понадобиться sender, понятно, зачем может понадобиться EventArgs, не понятно почему не передать всё это как object[].
Можно ещё посмотреть на паттерн возбуждения события "снаружи": void MethodName(EventArgs). Ну а внутри как sender просто добавляется this.
Ну и строгая типизация, конечно (обработчик знает, что EventArgs — это EventArgs).
O>Можно ещё посмотреть на паттерн возбуждения события "снаружи": void MethodName(EventArgs). Ну а внутри как sender просто добавляется this.
O>Ну и строгая типизация, конечно (обработчик знает, что EventArgs — это EventArgs).
хм, то есть это возможность вызвать событие снаружи класса, не давая изменить источник события. интересно...
но строгая типизация почему-то нарушена в части "object sender" — зачем это понадобилось наполовину следить за типами, а наполовину не следить, можно было сделать и "object e" вместо "EventArgs e"?
Здравствуйте, andreich78, Вы писали:
A>хм, то есть это возможность вызвать событие снаружи класса, не давая изменить источник события. интересно... A>но строгая типизация почему-то нарушена в части "object sender" — зачем это понадобилось наполовину следить за типами, а наполовину не следить, можно было сделать и "object e" вместо "EventArgs e"?
ИМХО идея в том, что совершенно разные классы могут публиковать одни и те же события (например, какие-нибудь воображаемые MyCustomButton и StandardButton публикуют событие Click). В таком случае sender не всегда может бытть конкретизирован (да это часто и не нужно), а какой-нибудь ClickEventArgs очень даже полезно конкретизировать (для удобства пользователя события — чаще нам нужны именно аргументы, т.к. сендера мы и так знаем, когда подписываемся).
O>ИМХО идея в том, что совершенно разные классы могут публиковать одни и те же события (например, какие-нибудь воображаемые MyCustomButton и StandardButton публикуют событие Click). В таком случае sender не всегда может бытть конкретизирован (да это часто и не нужно), а какой-нибудь ClickEventArgs очень даже полезно конкретизировать (для удобства пользователя события — чаще нам нужны именно аргументы, т.к. сендера мы и так знаем, когда подписываемся).
O>Путанно объяснил, наверное... как смог
получается, что наследоваться от EventArgs необязательно, разве нет?
просто передавать аргумент того же типа...
Здравствуйте, andreich78, Вы писали:
O>>ИМХО идея в том, что совершенно разные классы могут публиковать одни и те же события (например, какие-нибудь воображаемые MyCustomButton и StandardButton публикуют событие Click). В таком случае sender не всегда может бытть конкретизирован (да это часто и не нужно), а какой-нибудь ClickEventArgs очень даже полезно конкретизировать (для удобства пользователя события — чаще нам нужны именно аргументы, т.к. сендера мы и так знаем, когда подписываемся).
O>>Путанно объяснил, наверное... как смог A>получается, что наследоваться от EventArgs необязательно, разве нет? A>просто передавать аргумент того же типа...
По-моему как раз обязательно (для удобства пользователя), но только в случае если твой event предоставляет какие-нибудь event arguments. Тогда делегат для Click event будет выглядеть как void ClickDelegate(object sender, ClickEventArgs e). Пользователь получит именно ClickEventArgs. Ещё раз повторюсь, что моё ИМХО в том, что сделано было так для удобства подписчика события.
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, andreich78, Вы писали:
O>>>ИМХО идея в том, что совершенно разные классы могут публиковать одни и те же события (например, какие-нибудь воображаемые MyCustomButton и StandardButton публикуют событие Click). В таком случае sender не всегда может бытть конкретизирован (да это часто и не нужно), а какой-нибудь ClickEventArgs очень даже полезно конкретизировать (для удобства пользователя события — чаще нам нужны именно аргументы, т.к. сендера мы и так знаем, когда подписываемся).
O>>>Путанно объяснил, наверное... как смог A>>получается, что наследоваться от EventArgs необязательно, разве нет? A>>просто передавать аргумент того же типа...
O>По-моему как раз обязательно (для удобства пользователя), но только в случае если твой event предоставляет какие-нибудь event arguments. Тогда делегат для Click event будет выглядеть как void ClickDelegate(object sender, ClickEventArgs e). Пользователь получит именно ClickEventArgs. Ещё раз повторюсь, что моё ИМХО в том, что сделано было так для удобства подписчика события.
Мне кажется, andreich78 спрашивал немного другое: обязательно ли в void ClickDelegate(object sender, ClickEventArgs e) наследовать ClickEventArgs именно от EventArgs? Ведь ничего не мешает отнаследовать его от кого угодно, хоть от Rectangle — это не повлияет ни на делегат, ни на строгую типизацию, все это будет...
Здравствуйте, Andrbig, Вы писали:
A>Здравствуйте, Oyster, Вы писали:
O>>Здравствуйте, andreich78, Вы писали:
O>>>>ИМХО идея в том, что совершенно разные классы могут публиковать одни и те же события (например, какие-нибудь воображаемые MyCustomButton и StandardButton публикуют событие Click). В таком случае sender не всегда может бытть конкретизирован (да это часто и не нужно), а какой-нибудь ClickEventArgs очень даже полезно конкретизировать (для удобства пользователя события — чаще нам нужны именно аргументы, т.к. сендера мы и так знаем, когда подписываемся).
O>>>>Путанно объяснил, наверное... как смог A>>>получается, что наследоваться от EventArgs необязательно, разве нет? A>>>просто передавать аргумент того же типа...
O>>По-моему как раз обязательно (для удобства пользователя), но только в случае если твой event предоставляет какие-нибудь event arguments. Тогда делегат для Click event будет выглядеть как void ClickDelegate(object sender, ClickEventArgs e). Пользователь получит именно ClickEventArgs. Ещё раз повторюсь, что моё ИМХО в том, что сделано было так для удобства подписчика события.
A>Мне кажется, andreich78 спрашивал немного другое: обязательно ли в void ClickDelegate(object sender, ClickEventArgs e) наследовать ClickEventArgs именно от EventArgs? Ведь ничего не мешает отнаследовать его от кого угодно, хоть от Rectangle — это не повлияет ни на делегат, ни на строгую типизацию, все это будет...
А в качестве исключения можно использовать тип int, он тоже не отнаследован от Exception, только, слава богу, ни кто это не делает.
Все хотят хорошо провести время, но время не проведешь !
Здравствуйте, Andrbig, Вы писали:
A>Мне кажется, andreich78 спрашивал немного другое: обязательно ли в void ClickDelegate(object sender, ClickEventArgs e) наследовать ClickEventArgs именно от EventArgs? Ведь ничего не мешает отнаследовать его от кого угодно, хоть от Rectangle — это не повлияет ни на делегат, ни на строгую типизацию, все это будет...
Естественно, сам разработчик волен писать так, как ему захочется... использование EventArgs в качестве парента это своего рода договорённость.
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, Andrbig, Вы писали:
A>>Мне кажется, andreich78 спрашивал немного другое: обязательно ли в void ClickDelegate(object sender, ClickEventArgs e) наследовать ClickEventArgs именно от EventArgs? Ведь ничего не мешает отнаследовать его от кого угодно, хоть от Rectangle — это не повлияет ни на делегат, ни на строгую типизацию, все это будет...
O>Естественно, сам разработчик волен писать так, как ему захочется... использование EventArgs в качестве парента это своего рода договорённость.
Здравствуйте, Andrbig, Вы писали:
A>Здравствуйте, Oyster, Вы писали:
O>>Здравствуйте, Andrbig, Вы писали:
A>>>Мне кажется, andreich78 спрашивал немного другое: обязательно ли в void ClickDelegate(object sender, ClickEventArgs e) наследовать ClickEventArgs именно от EventArgs? Ведь ничего не мешает отнаследовать его от кого угодно, хоть от Rectangle — это не повлияет ни на делегат, ни на строгую типизацию, все это будет...
O>>Естественно, сам разработчик волен писать так, как ему захочется... использование EventArgs в качестве парента это своего рода договорённость.
A>Хм, а в чем мотивы такой договоренности?
Тут моих знаний не хватает Нужен был какой-то базовый класс для аргументов событий... почему это не object? Ну может из-за EventArgs.Empty?
А вообще вот цитата из MSDN и я умываю руки :
.NET Framework Guidelines
Although the C# language allows events to use any delegate type, the .NET Framework has some stricter guidelines on the delegate types that should be used for events. If you intend for your component to be used with the .NET Framework, you probably will want to follow these guidelines.
The .NET Framework guidelines indicate that the delegate type used for an event should take two parameters, an "object source" parameter indicating the source of the event, and an "e" parameter that encapsulates any additional information about the event. The type of the "e" parameter should derive from the EventArgs class. For events that do not use any additional information, the .NET Framework has already defined an appropriate delegate type: EventHandler.
— это не повлияет ни на делегат, ни на строгую типизацию, все это будет...
Нужен был какой-то базовый класс для аргументов событий... почему это не object? Ну может из-за EventArgs.Empty? 