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

>>для какого-то специфического участка, нежели на что-то универсальное. Но это не говнокод.

_>

_>специфического участка.. научись делать заключения о коде вне его контекста,

Не всякий код имеет смысл вне его контекста. Тот, который ты привел — похож на зависимый от какого-то контекста. Научись думать головой, а не только есть в неё.

_>http://rsdn.org/forum/dotnet/7425327.1

Автор: sergeya
Дата: 22.04.19

_>- здесь подробненько, спасибо человеку, особо обрати на пункт 4.

Человек молодец, тут спору нет. Но вот out-параметры — это само по себе в большинстве случаев пахучий код, они препятствуют комбинированию функций. Поэтому варианты из пункта 4 однозначно лучшими не являются.

_>>http://rsdn.org/forum/dotnet/7425327.1

Автор: sergeya
Дата: 22.04.19

_>>- здесь подробненько, спасибо человеку, особо обрати на пункт 4.

ARK>Человек молодец, тут спору нет. Но вот out-параметры — это само по себе в большинстве случаев пахучий код, они препятствуют комбинированию функций. Поэтому варианты из пункта 4 однозначно лучшими не являются.

мдаа.. твой диагноз понятен. делегат с делегатом канечно круче. Ты сам себе перечишь.. Человек молодец но делегат с делегатом лучше ).

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

ARK>>Человек молодец, тут спору нет. Но вот out-параметры — это само по себе в большинстве случаев пахучий код, они препятствуют комбинированию функций. Поэтому варианты из пункта 4 однозначно лучшими не являются.

_>мдаа.. твой диагноз понятен. делегат с делегатом канечно круче. Ты сам себе перечишь.. Человек молодец но делегат с делегатом лучше ).

С делегатом не лучше и не хуже, чем возврат тупла или структуры (но с делегатом определенно лучше, чем возврат через out-параметры). Если это внутренний метод, то всё зависит от контекста — может, часть кода написана с применением такого делегата, он в нескольких местах принимается и возвращается — тогда всё нормально, это местечковый утилитарный кусок кода.

Если этот метод является публичным методом какого-то API — то его интерфейс определенно плох, и ни туплами, ни out-параметрами дело не исправить.

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

ARK>Но вот out-параметры — это само по себе в большинстве случаев пахучий код, они препятствуют комбинированию функций. Поэтому варианты из пункта 4 однозначно лучшими не являются.

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

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

Ну то есть попытки хоть как то обосновать свою точку зрения закончились окончательно, осталось одно кривляние. Слив засчитан.

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

S>А тебя не смущает, что Clipboard.Clear() будет вызван в исходном потоке?

Это ПСЕВДОКОД.

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

S>Ни разу не видел делегат, принимающий другой делегат.

Это лишь говорит о количестве и разнообразии виденного тобой кода.

S> Одно дело Func<data,Action>, другое Action<data,Action>. ТС совершенно прав, что напрягся.

Ононочо, Михалыч. Ну и в чем принципиальная разница?

Здравствуйте, Ночной Смотрящий, Вы писали:

S>> Одно дело Func<data,Action>, другое Action<data,Action>. ТС совершенно прав, что напрягся.

НС>Ононочо, Михалыч. Ну и в чем принципиальная разница?

В первом случае мы формируем делегат, т.е. енто возвращаемое значение, во втором сл. -- енто просто параметр в другой делегат. Разница колоссальна.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>А тебя не смущает, что Clipboard.Clear() будет вызван в исходном потоке?
НС>Это ПСЕВДОКОД.

Тогда непонятно, что это псевдокод должен был продемонстрировать.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, barn_czn, Вы писали:

НС>Ну то есть попытки хоть как то обосновать свою точку зрения закончились окончательно, осталось одно кривляние. Слив засчитан.

Слив у человека который на аргументацию отвечает просто — нет. "Черное. Нет, белое. Черное потому что.. Нет белое". Так и ты..
Читай ниже, человек объясняет для таких как ты.

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

_>Читай ниже, человек объясняет для таких как ты.

Продолжай себя закапывать.

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

НС>>Ононочо, Михалыч. Ну и в чем принципиальная разница?

S>В первом случае мы формируем делегат, т.е. енто возвращаемое значение, во втором сл. -- енто просто параметр в другой делегат. Разница колоссальна.

Можно пояснить напальцах для тупых?
Я тоже не понимаю в чём принципиальная разница
Можно сказать, Action это просто Func которая возвращает void.. во многих языках вообще есть только Func.

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

bnk>Можно сказать, Action это просто Func которая возвращает void.. во многих языках вообще есть только Func.

Разница еще в аргументах, т.е.

public Action A(DataObject d){}

и

public void B(DataObject d,Action act){}

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

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

НС>>>Ононочо, Михалыч. Ну и в чем принципиальная разница?

S>>В первом случае мы формируем делегат, т.е. енто возвращаемое значение, во втором сл. -- енто просто параметр в другой делегат. Разница колоссальна.

bnk>Можно пояснить напальцах для тупых?
bnk>Я тоже не понимаю в чём принципиальная разница

Хотя бы в том что функция возвращает результат, который ждут. Без результата функция не имеет смысл (не путать с методом).
Если нет результата то очень часто можно метод выполнить асинхронно. Т.е. запустить и забыть.
Это принципиально ? Надеюсь понятно что Ждать и НЕ Ждать — отличается принципиально.

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

Этот код заменяется интерфейсом IClipboard:

interface IClipboard
{
    void SetData(DataObject data);
}

Или классом, или базовым классом — и всё, сразу понятно, что он делает. Не нужно лезть в код и расшифровывать запутанную логику, реализованную коллбеками.

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

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

V>Этот код заменяется интерфейсом IClipboard:
V>

V>interface IClipboard
V>{
V>    void SetData(DataObject data);
V>}
V>

V>Или классом, или базовым классом — и всё, сразу понятно, что он делает. Не нужно лезть в код и расшифровывать запутанную логику, реализованную коллбеками.

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

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


_>Ты просто гений. А я думал типизированый делегат и интерфейс из одного метода по сути одно и тоже.

С делегатом меньше контроля и ясности. Какой там в реальности код за ним скрывается? Сколько делегатов там в цепочке?

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

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


_>>Ты просто гений. А я думал типизированый делегат и интерфейс из одного метода по сути одно и тоже.

V>С делегатом меньше контроля и ясности.

Это как это? Расскажи про контроль ясности.

>Какой там в реальности код за ним скрывается?

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

>Сколько делегатов там в цепочке?

О какой цепочке речь? Где там в делегатах какие то цепочки?

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

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

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


_>>>Ты просто гений. А я думал типизированый делегат и интерфейс из одного метода по сути одно и тоже.

V>>С делегатом меньше контроля и ясности.

_>Это как это? Расскажи про контроль ясности.

Код делает только одну вещь одним способом и не допускает других способов использования.

>>Какой там в реальности код за ним скрывается?

_>Такой же какой и за имплементацией методов интерфейса.

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

>>Сколько делегатов там в цепочке?

_>О какой цепочке речь? Где там в делегатах какие то цепочки?

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

_>>О какой цепочке речь? Где там в делегатах какие то цепочки?

V>Делегаты можно соединять в цепочки. Механизм событий использует эту особенность делегатов для работы с множеством подписчиков.

Ну т.е. это снова аргумент за делегаты.
Ни все так просто, сынок. Интерфейсы с одним методом есть в дотнете, и делегаты есть. И в этом же дотнете я знаю пример где такие интерфейсы уместны, и пример неуместного.

IDisposable — прекрасный интерфейс. в паре с using просто красота.
IComparer — мука , писать на сортировочку целый класс, это мука.. к счастью для сортировки есть и способ с делегатом.

В примере топика интерфейс 100% неуместен, и не дает ни одного плюса. Аргументов против я так и не услышал.