Antonariyfluent находится почти полностью в рамках классического синтаксисаиз любопытства - в чем заключается то малое "не почти"?
ИМХО - ушанка. Балалайка, водка и медведь немножко за кадром

AntonariyНасчет сидиеза не знаю, а в вб вот это, например:


Ну это передача делегата Func<,> ведь (не знаю, как в VB называются делегаты - ссылки на методы). В принципе, это в некотором смысле другой сахар - создание на ходу анонимного делегата. В шарпе будет выглядеть так:

но это не имеет отношения непосредственно к линку.
AntonariyИли может это лишь я такими конструкциями не пользовался за рамками LINQ.Ну и зря ))

AntonariyShocker.ProНу и зря ))А зачем?)в чем вопрос:
Зачем использовать делегаты в принципе?
или
Зачем использовать inline объявление анонимного делегата (вместо ссылки на явно объявленный метод)?

AntonariyВ смысле пример приведи из своей практики. Какая была задача и как ее решил.
Вчерашний пример - из класса A создаю экземпляр класса Б, в который нужно отдать некий ID.
Проблема в том, что с одной стороны этот ID классу Б понадобится не сразу (только при рендеринге), с другой стороны, ID еще и не готов, он будет сгенерен или изменен в процессе работы класса А (но заведомо до того, как он понадобится Б, просто по определению)

Тогда я беру и объявляю конструктор Б не Б(int ID), а Б(Action<int> getID)
и создаю экземпляр: new Б(() => this.MyID)
И тогда, когда классу Б приспичит, он сделает var id=getID() и получит актуальный ID

А вообще, в самой платформе .NET миллион методов и классов, принимающих на вход Func<> или Action<> - каждый из них - ответ на твой вопрос ))

AntonariyТогда я беру и объявляю конструктор Б не Б(int ID), а Б(Action<int> getID)
и создаю экземпляр: new Б(() => this.MyID)
И тогда, когда классу Б приспичит, он сделает var id=getID() и получит актуальный IDПочему не Б(A obj); new Б(this); var id = obj.MyID?Ужасное решение, увеличивающее связность кода. Зачем вводить зависимость класса Б от класса А или от какого-го либо интерфейса? Тем более, что класс Б - библиотечный.

AntonariyПогоня за излишней развязанностью всегда во благо и красоты для?уменьшение связности улучшает обслуживаемость, модифицируемость, тестируемость кода. По поводу "излишней" - по моему опыту - связанность должна быть всегда несколько меньше, чем требует объективный взгляд на проблему сегодня, ибо потом это резко создает ненужные проблемы при любой попытке развития проекта.

AntonariyУсловия задачи сформулированы так, что строго исключают зависимость Б от А?В данном случае - да. Ибо класс библиотечный. Даже если это было бы не так в данной задаче - все равно нужно обойтись без создания зависимости класса Б от класса А, потому что завтра класс Б захочется куда-то унести или воспользоваться им в другом месте. ТЕМ БОЛЕЕ, что написание в данном случае несвязного кода не усложняет код и не прибавляет букв.

AntonariyА действительно. А уже зависит от Б, путь заодно реализует интерфейс из Б, а передается в конструктор как Object.нахера? Уже есть универсальный "интерфейс" Action<int>, нафига тут лишнюю сущность вводить?