Re[10]: Событийно ориентированное программирование - Философия программирования

_NN>>>Тут ведь получается, что нужно хранить этот 'MyHandler' только для того, чтобы отписаться от события.
_NN>>>Т.е. его нельзя сделать анонимной функцией, локальной переменной и т.д.

KAR>>Не нужно ничего хранить, это глобальная константа. На ивент же может быть больше одного листенера...
_NN>Как не нужно ?

_NN>Вот в этом примере как отписаться ?
_NN>

_NN>  window.addEventListener('click', function() {} );
_NN>

'click' говоришь хранить надо? Ну ок, храни...

_NN>Тут ведь получается, что нужно хранить этот 'MyHandler' только для того, чтобы отписаться от события.
_NN>Т.е. его нельзя сделать анонимной функцией, локальной переменной и т.д.

Не нужно ничего хранить, это глобальная константа. На ивент же может быть больше одного листенера...

Кто знает почему сделали паттерн подписки и отписки от событий примерно так:

SomeEvent += MyHandler;
SomeEvent -= MyHandler;

SomeEvent.addEventListener(MyHandler);
SomeEvent.removeEventListener(MyHandler);

Тут ведь получается, что нужно хранить этот 'MyHandler' только для того, чтобы отписаться от события.
Т.е. его нельзя сделать анонимной функцией, локальной переменной и т.д.

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

MySubscription = SomeEvent.Subscribe(MyHandler)
MySubscription.Dispose();

Даже в старом WinAPI был второй вариант.
Кто же все таки посчитал, что первый подход лучше ?

Здравствуйте, os24ever, Вы писали:

_NN>>как например в Rx
O>Погуглил и нашёл: Just say No to “Reactive Programming”.
O>Автор пишет, что это всего лишь Observer/Observable и был описан в книге GoF много лет тому назад.
O>Потому, наверное, так и сделано: "согласно положениям GoF".

дааа, я помню этого парня!
http://stackoverflow.com/users/182669/dbjdbj

собственно там в комментах по ссылке написали
> Thats the worst example of BS and arrogance that I ever read online.

Здравствуйте, _NN_, Вы писали:

_NN>Кто знает почему сделали паттерн подписки и отписки от событий примерно так:

Кто или где сделал?

В jquery (и Sciter) например так

var elem = ...

function handler(evt) { ... }

elem.on("click", handler); // 1
elem.on("click.mycls", function() {...}); // 2
elem.on("mouseup.mycls", function() {...}); // 3

elem.off( handler );   // отпишет №1
elem.off( ".mycls" );  // отпишет №2 и №3
elem.off( "click" );   // отпишет №1 и №2

Здравствуйте, ionoy, Вы писали:

I>в отличие от IDisposable.

SRP, кстати, опять же.

Здравствуйте, os24ever, Вы писали:
O>Автор пишет, что это всего лишь Observer/Observable и был описан в книге GoF много лет тому назад.
O>Потому, наверное, так и сделано: "согласно положениям GoF".
Автор — поверхностный хам и воинствующее невежество. Он нашёл в Rx знакомое слово и из этого раздул целую статью.

Здравствуйте, KARPOLAN, Вы писали:

_NN>>Тут ведь получается, что нужно хранить этот 'MyHandler' только для того, чтобы отписаться от события.
_NN>>Т.е. его нельзя сделать анонимной функцией, локальной переменной и т.д.

KAR>Не нужно ничего хранить, это глобальная константа. На ивент же может быть больше одного листенера...
Как не нужно ?

Вот в этом примере как отписаться ?

  window.addEventListener('click', function() {} );

Вот классическая ошибка первого варианта в JavaScript:

function f() {
  var handler = function() {    
  }

  // Удалить старое если было
  window.removeEventListener('click', f);
  // Добавить новое
  window.addEventListener('click', f);
}

Тут каждый вызов функции создается другая переменная и в итоге ничего не удаляется.

Второй вариант также позволяет иметь более одного подписчика.

myEvent.Subscribe(f1);
myEvent.Subscribe(f2);

Здравствуйте, _NN_, Вы писали:

_NN>Кто же все таки посчитал, что первый подход лучше ?

Я никогда не слышал, чтобы при дизайне C# 1.0 рассматривались другие варианты (анонимных функций тогда не было). Так что вполне возможно, что никто не решал, что выбранный подход лучше, это могло быть единственное решение, которое тогда пришло в голову дизайнерам. Хранить анонимные функции, конечно, неудобно, поэтому в Rx придумали другой подход. Но тебе всё равно нужно хранить объект, у которого ты собираешься вызывать Dispose() для отписки.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, _NN_, Вы писали:

_NN>>Кто же все таки посчитал, что первый подход лучше ?

N>Я никогда не слышал, чтобы при дизайне C# 1.0 рассматривались другие варианты (анонимных функций тогда не было). Так что вполне возможно, что никто не решал, что выбранный подход лучше, это могло быть единственное решение, которое тогда пришло в голову дизайнерам. Хранить анонимные функции, конечно, неудобно, поэтому в Rx придумали другой подход. Но тебе всё равно нужно хранить объект, у которого ты собираешься вызывать Dispose() для отписки.

В любом случае нужен какой-нибудь идентификатор для отписки.
Другое дело, что им почему-то является сам метод.
В таком варианте не всегда возможно подписаться в одном месте, а отписаться в другом.

Как единственное решение ? На WinAPI не смотрели что ли

Образный код:

auto timer = SetTimer(myCallback);
KillTimer(timer);

Здравствуйте, _NN_, Вы писали:

_NN>В любом случае нужен какой-нибудь идентификатор для отписки.
_NN>Другое дело, что им почему-то является сам метод.
_NN>В таком варианте не всегда возможно подписаться в одном месте, а отписаться в другом.

_NN>Как единственное решение ? На WinAPI не смотрели что ли

_NN>Образный код:
_NN>

_NN>auto timer = SetTimer(myCallback);
_NN>KillTimer(timer);
_NN>

Это disposable объект для отписки, только в профиль.

Здравствуйте, _NN_, Вы писали:

_NN>Кто знает почему сделали паттерн подписки и отписки от событий примерно так:

_NN>

_NN>SomeEvent += MyHandler;
_NN>SomeEvent -= MyHandler;

_NN>SomeEvent.addEventListener(MyHandler);
_NN>SomeEvent.removeEventListener(MyHandler);
_NN>

_NN>Тут ведь получается, что нужно хранить этот 'MyHandler' только для того, чтобы отписаться от события.
_NN>Т.е. его нельзя сделать анонимной функцией, локальной переменной и т.д.

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

_NN>MySubscription = SomeEvent.Subscribe(MyHandler)
_NN>MySubscription.Dispose();
_NN>

_NN>Даже в старом WinAPI был второй вариант.
_NN>Кто же все таки посчитал, что первый подход лучше ?

SomeEvent.Subscribe можно сделать через +=/-=
C# не помню, по этому напишу на С++

function<void()> Subscribe(function<...> MyHandler) {
    SomeEvent += MyHandler;
    return [=]{ SomeEvent -= MyHandler; };
}

наоборот сделать уже сложнее, поэтому лучше использовать +=/-= с которыми можно использовать обе схемы,
чем использовать Subscribe с которым уже не сделать -=.

Здравствуйте, Abyx, Вы писали:

A>наоборот сделать уже сложнее, поэтому лучше использовать +=/-= с которыми можно использовать обе схемы,
A>чем использовать Subscribe с которым уже не сделать -=.

Что значит сложнее ?
Да и проблема то какая решается ?

subscription1 = event.Subscribe(func1)
subscription2 = event.Subscribe(func2)

subscription2.Dispose(); // Отписались от 2
subscription1.Dispose(); // Отписались от 1

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Abyx, Вы писали:

A>>наоборот сделать уже сложнее, поэтому лучше использовать +=/-= с которыми можно использовать обе схемы,
A>>чем использовать Subscribe с которым уже не сделать -=.

_NN>Что значит сложнее ?
_NN>Да и проблема то какая решается ?

_NN>

_NN>subscription1 = event.Subscribe(func1)
_NN>subscription2 = event.Subscribe(func2)

_NN>subscription2.Dispose(); // Отписались от 2
_NN>subscription1.Dispose(); // Отписались от 1
_NN>

и кто и где должен хранить subscription?

Здравствуйте, Abyx, Вы писали:

A>и кто и где должен хранить subscription?

Кто подписывается тот и хранит или передает дальше куда надо.
Разработчик волен делать что хочет.

С другой стороны не нужно знать про сам метод, чтобы подписаться.
Можно подписываясь передать приватный метод или анонимный, и отписаться можно извне без проблем.

Здравствуйте, c-smile, Вы писали:

CS>

CS>var elem = ...

CS>function handler(evt) { ... }

CS>elem.on("click", handler); // 1
CS>elem.on("click.mycls", function() {...}); // 2
CS>elem.on("mouseup.mycls", function() {...}); // 3

CS>elem.off( handler );   // отпишет №1
CS>elem.off( ".mycls" );  // отпишет №2 и №3
CS>elem.off( "click" );   // отпишет №1 и №2
CS>

Я в jQuery не очень силен.
Как отписаться только от 2 или только от 3 ?

А как в jQuery работает возможность описаться от всех подписчиков ?
Т.е: $("someElement").off("click")
Неужели он хранит список всех, кто подписался.

P.S.
В RxJS например можно подписаться и отписаться вот так:

var keys = Rx.Observable.fromEvent(textInput, 'keyup');
var s = keys.subscribe(function() {});
s.dispose();

_NN>как например в Rx
Погуглил и нашёл: Just say No to “Reactive Programming”.
Автор пишет, что это всего лишь Observer/Observable и был описан в книге GoF много лет тому назад.
Потому, наверное, так и сделано: "согласно положениям GoF".

Здравствуйте, _NN_, Вы писали:
_NN>Можно подписываясь передать приватный метод или анонимный, и отписаться можно извне без проблем.
По-прежнему не очень понятно, в чём принципиальная разница между:

_myHandler = () => { };
a.OnClick =+ _myHandler;

...

a.OnClick -= _myHandler;

_myHandlerHandler = a.OnClick.Subscribe(() => { });

...

a.OnClick.Unsubscribe(_myHandlerHandler); // ну или _myHandlerHandler.Dispose();

Здравствуйте, Sinclair, Вы писали:

S>По-прежнему не очень понятно, в чём принципиальная разница между:

S>

S>_myHandler = () => { };
S>a.OnClick =+ _myHandler;
S>a.OnClick -= _myHandler;

S>

S>и
S>

S>_myHandlerHandler = a.OnClick.Subscribe(() => { });
S>a.OnClick.Unsubscribe(_myHandlerHandler); // ну или _myHandlerHandler.Dispose();
S>

Удобнее тем, что внешнему коду не нужно знать конкретный тип обработчика, чтобы отменить операцию. Это значит, что мы можем использовать обобщённую логику отписки для разных "событий".
К тому же IDisposable можно комбинировать:

var disposable1 = stream.Subscribe(...);
var disposable2 = Disposable.Create(() => ...);

return new CompositeDisposable() { disposable1, disposable2 } //Возвращает IDisposable, который по очереди вызовет disposable1 и disposable2

Если интересно, то про разные реализации IDisposable можно почитать, например, тут: http://synchronicity-life.blogspot.com/2011/12/idisposable-implementations-in-reactive.html

Здравствуйте, ionoy, Вы писали:

I>Удобнее тем, что внешнему коду не нужно знать конкретный тип обработчика, чтобы отменить операцию.
Что такое "конкретный тип обработчика"?

I>Это значит, что мы можем использовать обобщённую логику отписки для разных "событий".

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

I>К тому же IDisposable можно комбинировать:

I>var disposable1 = stream.Subscribe(...);
I>var disposable2 = Disposable.Create(() => ...);

I>return new CompositeDisposable() { disposable1, disposable2 } //Возвращает IDisposable, который по очереди вызовет disposable1 и disposable2
I>[/c#]
Непонятно, почему именно Disposable.
Почему вы не хотите комбинировать, например, Action.

Здравствуйте, Sinclair, Вы писали:

S>Пример кода, который вы хотите написать, в студию. С пояснением, почему вы не можете его написать в нынешнем коде.

Встяну. Вот лично у меня присутствует чисто психологический дискомфорт сохранять где-либо для последующей отписки ссылку на функцию. Оно конечно это можно списать на фантомные боли императивщика, но — а вдруг это замыкание какое, к примеру, тянущее за собой чёрт знает сколько захваченных данных?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, ionoy, Вы писали:

I>>Удобнее тем, что внешнему коду не нужно знать конкретный тип обработчика, чтобы отменить операцию.
S>Что такое "конкретный тип обработчика"?

event EventHandler<bool> Event1;
event EventHandler<string> Event2;
        
public void Subscribe()
{
    EventHandler<bool> handler1 = (sender, b) => { };
    EventHandler<string> handler2 = (sender, s) => { };

    Event1 += handler1;
    Event2 += handler2;

    Unsubscribe(handler1, handler2);
}

private void Unsubscribe(EventHandler<bool> handler1, EventHandler<string> handler2)
{
    Event1 -= handler1;
    Event2 -= handler2;
}

В данном случае EventHandler<bool> и EventHandler<string> это конкретные типы обработчиков.
Я не могу написать:

void Unsubscribe(IEnumerable<EventHandler<T>> handlers) {
  foreach(var handler in handlers)
    //somehow unsubscribe?  
}

Потому что источники событий могут быть разные (Event1, Event2 и любая другая подписка).
Получается, что методу отписки нужно знать не только тип обработчика, но и само событие от которого нужно отписаться. Далеко не всегда есть возможность эту информацию предоставить.

S>Непонятно, почему именно Disposable.
S>Почему вы не хотите комбинировать, например, Action.
Из-за разных наборов параметров.

Здравствуйте, ionoy, Вы писали:

S>>Непонятно, почему именно Disposable.
S>>Почему вы не хотите комбинировать, например, Action.
I>Из-за разных наборов параметров.

Дополню:
И необходимости передавать источник. От самого Action толку мало, в отличие от IDisposable.

Здравствуйте, ionoy, Вы писали:

I>Дополню:
I>И необходимости передавать источник. От самого Action толку мало, в отличие от IDisposable.
А, я, наверное, непонятно выразился.
вот что я имел в виду:

public Action Subscribe() {
  EventHandler<bool> handler1 = (sender, b) => { };
  EventHandler<string> handler2 = (sender, s) => { };

  Action unsubscribe = () => {
    Event1 -= handler1;
  };
  г
  return unsubscribe;
}

Как видим, внешнему коду вообще не нужно знать ни тип обработчика, ни конкретное событие. Достаточно позвать делегат, который ему вернули, в тот момент, когда вы хотели вызывать IDisposable.Dispose.

Здравствуйте, Sinclair, Вы писали:

S>А, я, наверное, непонятно выразился.
S>вот что я имел в виду:
S>

S>public Action Subscribe() {
S>  EventHandler<bool> handler1 = (sender, b) => { };
S>  EventHandler<string> handler2 = (sender, s) => { };

S>  Action unsubscribe = () => {
S>    Event1 -= handler1;
S>  };
S>  г
S>  return unsubscribe;
S>}
S>

S>Как видим, внешнему коду вообще не нужно знать ни тип обработчика, ни конкретное событие. Достаточно позвать делегат, который ему вернули, в тот момент, когда вы хотели вызывать IDisposable.Dispose.

Примерно так оно и работает внутри. Есть, например, удобный метод:

Disposable.Create(() => Debug.WriteLine("Dispose called"));

Как я это вижу, у IDisposable есть несколько преимуществ перед Action:

1. На основании этого интерфейса можно создать готовую библиотеку реализаций IDisposable, как сделали в Rx. Такие объекты предоставляют дополнительную функциональность для кода выдающего подписку, а для клиентов всё тот же IDisposable. Про некоторые готовые реализации опять же здесь: http://synchronicity-life.blogspot.com/2011/12/idisposable-implementations-in-reactive.html
2. IDisposable — это распространённый шаблон проектирования. Иногда бывает удобно локализовать подписку с помощью using.
3. IDisposable семантически лучше подходит на роль отписчика, чем Action

Здравствуйте, ionoy, Вы писали:

I>Примерно так оно и работает внутри. Есть, например, удобный метод:

I>

I>Disposable.Create(() => Debug.WriteLine("Dispose called"));
I>

I>Как я это вижу, у IDisposable есть несколько преимуществ перед Action:
Ну так и используйте его, если в вашей инфраструктуре он удобнее.
Лично мне более удобными кажутся weak events, т.к. сама необходимость следить за отпиской напрягает. Независимо от того, используется ли "честный" OnClick -=, Action, или IDisposable.
Я очень часто сталкивался с тем, что нам нужен "observer, который следит, покуда жив", а не "observer, который жив, покуда следит".

Здравствуйте, Sinclair, Вы писали:

I>>Как я это вижу, у IDisposable есть несколько преимуществ перед Action:
S>Ну так и используйте его, если в вашей инфраструктуре он удобнее.
S>Лично мне более удобными кажутся weak events, т.к. сама необходимость следить за отпиской напрягает. Независимо от того, используется ли "честный" OnClick -=, Action, или IDisposable.
S>Я очень часто сталкивался с тем, что нам нужен "observer, который следит, покуда жив", а не "observer, который жив, покуда следит".

Многие Observable так и устроены.

Например, такой код:

stream.Take(3).Subscribe(x => DoSomething(x))

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

Здравствуйте, ionoy, Вы писали:
I>сам отпишет подписчика.
Это понятно. Есть обратные ситуации — datasource.OnChange += form1.Refresh навсегда удержит форму в памяти.

Здравствуйте, Sinclair, Вы писали:

В том, что нельзя допустить вроде этой: http://www.rsdn.ru/forum/philosophy/5699473.1
Или в стиле шарпа:

void Resubscribe()
{
  Action myHandler = () => {};
  a.OnClick -= myHandler;
  a.OnClick += myHandler;
}

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Sinclair, Вы писали:

_NN>В том, что нельзя допустить вроде этой: http://www.rsdn.ru/forum/philosophy/5699473.1
_NN>Или в стиле шарпа:
_NN>

_NN>void Resubscribe()
_NN>{
_NN>  Action myHandler = () => {};
_NN>  a.OnClick -= myHandler;
_NN>  a.OnClick += myHandler;
_NN>}
_NN>

а как ты такое в варианте с IDisposable реализуешь ?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, ionoy, Вы писали:
I>>сам отпишет подписчика.
S>Это понятно. Есть обратные ситуации — datasource.OnChange += form1.Refresh навсегда удержит форму в памяти.
Так ведь можно отписаться по необходимости. Или я чего-то не понимаю?

Здравствуйте, Jack128, Вы писали:

J>а как ты такое в варианте с IDisposable реализуешь ?

Например так:

IDisposable subscription;

void Resubscribe()
{
  subscription.Dispose();
  subscription = a.OnClick.Subscribe(myHandler);
}

Главное то, что я не смогу написать код, который якобы отписывается, а на деле ничего не делает.

Здравствуйте, ionoy, Вы писали:
S>>Это понятно. Есть обратные ситуации — datasource.OnChange += form1.Refresh навсегда удержит форму в памяти.
I>Так ведь можно отписаться по необходимости. Или я чего-то не понимаю?
Что значит "по необходимости"? Как вы определите момент необходимости?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, ionoy, Вы писали:
S>>>Это понятно. Есть обратные ситуации — datasource.OnChange += form1.Refresh навсегда удержит форму в памяти.
I>>Так ведь можно отписаться по необходимости. Или я чего-то не понимаю?
S>Что значит "по необходимости"? Как вы определите момент необходимости?

Вопрос был в том, что привязка навсегда удержит форму в памяти. Если есть такая проблема, значит когда-то эта форма перестаёт быть нужной? Обычно момент удаления формы более или менее детерминирован.

Здравствуйте, _NN_, Вы писали:

_NN>В том, что нельзя допустить вроде этой: http://www.rsdn.ru/forum/philosophy/5699473.1
_NN>Или в стиле шарпа:
_NN>

_NN>void Resubscribe()
_NN>{
_NN>  Action myHandler = () => {};
_NN>  a.OnClick -= myHandler;
_NN>  a.OnClick += myHandler;
_NN>}
_NN>

Ничего не понял. По ссылке — абсолютно работоспособный пример. На событие подписывается ровно одна функция.
В этом коде — тоже. На какой вопрос вы отвечаете — непонятно.

Здравствуйте, ionoy, Вы писали:
I>Вопрос был в том, что привязка навсегда удержит форму в памяти. Если есть такая проблема, значит когда-то эта форма перестаёт быть нужной?
Обычно (в среде с недетерминистической финализацией) объект перестаёт быть нужен тогда, когда последняя ссылка на него выходит из области видимости.

Здравствуйте, _NN_, Вы писали:

_NN>Например так:

_NN>

_NN>IDisposable subscription;

_NN>void Resubscribe()
_NN>{
_NN>  subscription.Dispose();
_NN>  subscription = a.OnClick.Subscribe(myHandler);
_NN>}
_NN>

ну ты сохранил подписку в глобальной переменной. точно так же и лямбду можно сохранить. в чем отличие ?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, ionoy, Вы писали:
I>>Вопрос был в том, что привязка навсегда удержит форму в памяти. Если есть такая проблема, значит когда-то эта форма перестаёт быть нужной?
S>Обычно (в среде с недетерминистической финализацией) объект перестаёт быть нужен тогда, когда последняя ссылка на него выходит из области видимости.

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

Здравствуйте, ionoy, Вы писали:

I>Ссылка сама по себе не выходит из области видимости, какой-то код управляет этим процессом, в любом случае.
Да ладно!
Ещё как выходит. Если бы это было не так, то нам вообще бы не потребовался сборщик мусора — мы всегда бы знали, в какой момент пора звать деструктор и освобождать память

I>Может просто пример с формой неудачный, т.к. там нет проблем отследить закрытие

Да. С формой пример не совсем удачный, т.к. в ней есть явный Dispose, в котором можно сделать отписку и полагаться на компонентную модель в контроле времени жизни. И тем не менее — ошибку типа "забыл отписаться" сделать очень легко. Эта возможность граблей никуда не денется от того, что оператор += будет возвращать что-то другое. Нам всё равно нужно куда-то записывать ссылку, либо на IDisposable, который надо не забыть отдиспозить, либо на хэндлер, который нужно отписать.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, ionoy, Вы писали:

I>>Ссылка сама по себе не выходит из области видимости, какой-то код управляет этим процессом, в любом случае.
S>Да ладно!
S>Ещё как выходит. Если бы это было не так, то нам вообще бы не потребовался сборщик мусора — мы всегда бы знали, в какой момент пора звать деструктор и освобождать память

А можно пример, где ссылка сама по себе выходит из области видимости, но при этом остаётся в памяти из-за привязки к событию?

I>>Может просто пример с формой неудачный, т.к. там нет проблем отследить закрытие

S>Да. С формой пример не совсем удачный, т.к. в ней есть явный Dispose, в котором можно сделать отписку и полагаться на компонентную модель в контроле времени жизни. И тем не менее — ошибку типа "забыл отписаться" сделать очень легко. Эта возможность граблей никуда не денется от того, что оператор += будет возвращать что-то другое. Нам всё равно нужно куда-то записывать ссылку, либо на IDisposable, который надо не забыть отдиспозить, либо на хэндлер, который нужно отписать.
Это верно, ошибиться можно. Другое дело, что про эти грабли разве что глухой не слышал.

Здравствуйте, Jack128, Вы писали:

J>ну ты сохранил подписку в глобальной переменной. точно так же и лямбду можно сохранить. в чем отличие ?

Лямбду легко забыть сохранить и каждый раз создавать новую локальную переменную. Реальный баг

А вот объект подписки не сохранив не отпишешься.

Здравствуйте, _NN_, Вы писали:

_NN>Кто же все таки посчитал, что первый подход лучше ?

Хейльсберг. Он в добавок еще и с делегатами накосячил.

Здравствуйте, _NN_, Вы писали:

_NN>Даже в старом WinAPI был второй вариант.
_NN>Кто же все таки посчитал, что первый подход лучше ?

логически, вариант с

MySubscription = SomeEvent.Subscribe(MyHandler)
MySubscription.Dispose();

абсолютно эквивалентен

SomeEvent.Subscribe(MyHandler)
SomeEvent.Unsubscribe(MyHandler);

т.к. внутри себя объект "подписки" будет вызывать Unsubscribe. Оригинальный myHandler все равно где-то должен храниться.
Т.е. это не более чем синтаксический сахар, причем не самый удобный. Если хочется, его можно реализовать быстро, но фишка в том, что смысла особого нет.

Вариант с объектами-подписками означает, что подписки надо где-то хранить. Это автоматически влечет проблемы с подписчиками, желающими остаться инвариантами и/или подписываемые к более чем одному источнику. Причем, не стоит забывать, что очень часто, если не сказать "обычно", подписчик даже и не знает, что его подписали-отписали. В таких случаях явный

SubjectOne.Unsubscribe(Handler);
SubjectX.Unsubscribe(Handler);

очевидно предпочтительнее манипуляций с объектами-подписками, особенно если отписаться нужно не от всех источников.

От:	KARPOLAN	http://karpolan.com
Дата:	19.07.14 07:23
Оценка:	-7

От:	KARPOLAN	http://karpolan.com
Дата:	19.07.14 07:05
Оценка:	-5

	От:	_NN_
	Дата:	19.07.14 04:53
	Оценка:	20 (3)

	От:	Abyx
	Дата:	21.07.14 10:57
	Оценка:	1 (1) +2

От:	c-smile	http://terrainformatica.com
Дата:	20.07.14 21:50
Оценка:	5 (1)

От:	dimgel	https://github.com/dimgel
Дата:	22.07.14 07:55
Оценка:	1 (1)

От:	Sinclair	https://github.com/evilguest/
Дата:	22.07.14 06:51
Оценка:	+1

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	20.07.14 02:34
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	20.07.14 13:13
Оценка:

От:	ionoy	www.ammyui.com
Дата:	22.07.14 07:04
Оценка:

От:	VladD2	www.nemerle.org
Дата:	24.07.14 01:53
Оценка:

	От:	Jack128
	Дата:	23.07.14 06:20
	Оценка:

	От:	Jack128
	Дата:	23.07.14 10:48
	Оценка: