Уже давно заметил, что нередко применяю метод рефакторинга, который назвал бы "Excract piece of code as parameter". Продемонстрирую на простом примере.
До рефакторинга:

private static void Main()
{
    Method1();
}

private static void Method1()
{
    int c1 = 1;
    long c2 = 2;

    string c3 = "" + c1 + c2;
}

После:

private static void Main()
{
    Method1((c1, c2) => "" + c1 + c2);
}

private static void Method1(Func<int, long, string> func)
{
    int c1 = 1;
    long c2 = 2;

    string c3 = func(c1, c2);
}

Я уже дозрел, чтобы написать об этом в форуме разработчиков ReSharper-а. Но встретил мнение, что “… типа не фиг таким увлекаться …”. Что думаете по этому поводу?

В дополнение к описанному методу рефакотринга, еще хочется Convert Delegate to Interface.

AP>Уже давно заметил, что нередко применяю метод рефакторинга, который назвал бы "Excract piece of code as parameter". Продемонстрирую на простом примере.
AP>До рефакторинга:
AP>

AP>private static void Main()
AP>{
AP>    Method1();
AP>}

AP>private static void Method1()
AP>{
AP>    int c1 = 1;
AP>    long c2 = 2;

AP>    string c3 = "" + c1 + c2;
AP>}
AP>

AP>После:
AP>

AP>private static void Main()
AP>{
AP>    Method1((c1, c2) => "" + c1 + c2);
AP>}

AP>private static void Method1(Func<int, long, string> func)
AP>{
AP>    int c1 = 1;
AP>    long c2 = 2;

AP>    string c3 = func(c1, c2);
AP>}
AP>

Опционально, вместо Func/Action можно вводить именованный делегат.

В принципе, данный метод рефакторинга почти полностью укладывается в простую последовательность широко используемых методов рефакторинга:
1. Extract method.
2. Ручное объявление переменной типа Func и присвоение ей значения равного методу.
3. Применение к переменной рефакторинга Introduce Parameter.
4. Inline method.

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

AP>Уже давно заметил, что нередко применяю метод рефакторинга, который назвал бы "Excract piece of code as parameter". Продемонстрирую на простом примере.
Значит дозрел до функциональщины.

AP>Я уже дозрел, чтобы написать об этом в форуме разработчиков ReSharper-а. Но встретил мнение, что “… типа не фиг таким увлекаться …”. Что думаете по этому поводу?
А ссылку можно?

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

AP>Я уже дозрел, чтобы написать об этом в форуме разработчиков ReSharper-а. Но встретил мнение, что “… типа не фиг таким увлекаться …”. Что думаете по этому поводу?

ReSharper это давно умеет. Рефакторинг Introduce Parameter, опция 'Select local variables to En-lambda'.

AP>Я уже дозрел, чтобы написать об этом в форуме разработчиков ReSharper-а. Но встретил мнение, что “… типа не фиг таким увлекаться …”. Что думаете по этому поводу?

чем код после такого рефакторинга стал лучше?
это скорее обфускация а не рефакторинг ))


AP>В дополнение к описанному методу рефакотринга, еще хочется Convert Delegate to Interface.

Delegate to Interface
и
Interface to Delegate
— да, наверно имеет право на фичу.

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

WH>Здравствуйте, Alexander Polyakov, Вы писали:

AP>>Уже давно заметил, что нередко применяю метод рефакторинга, который назвал бы "Excract piece of code as parameter". Продемонстрирую на простом примере.
WH>Значит дозрел до функциональщины.

По-моему, функциональщина тут не при чем. Это всего лишь известный уже лет сто старый добрый паттерн Strategy, щедро посыпанный сахаром. Лет пять регулярно использую такой же подход на java. ФП узурпировало это понятие (под брендом "ФВП"), можно подумать, это прямо особенность, только лишь для него и характерная. Я понимаю, что в функциональных языках функции-значения — единственный способ декомпозиции, но это не повод отбирать термины

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

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

WH>>Здравствуйте, Alexander Polyakov, Вы писали:

AP>>>Уже давно заметил, что нередко применяю метод рефакторинга, который назвал бы "Excract piece of code as parameter". Продемонстрирую на простом примере.
WH>>Значит дозрел до функциональщины.

LP>По-моему, функциональщина тут не при чем. Это всего лишь известный уже лет сто старый добрый паттерн Strategy, щедро посыпанный сахаром. Лет пять регулярно использую такой же подход на java. ФП узурпировало это понятие (под брендом "ФВП"), можно подумать, это прямо особенность, только лишь для него и характерная. Я понимаю, что в функциональных языках функции-значения — единственный способ декомпозиции, но это не повод отбирать термины

Просто для ФП не нужны дополнительные костыли в виде "паттернов" и всё решается "из каробки", т.к. функции первоклассные значения. Кто что отбирать собирался не очень понятно

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

К>Просто для ФП не нужны дополнительные костыли в виде "паттернов" и всё решается "из каробки", т.к. функции первоклассные значения.

Так ведь фп здесь не при чем. ФП — это не изменяемые значения. Все. А "функции — первоклассные значения" — лишь практика, прижившаяся в фп.

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

LP>Здравствуйте, Курилка, Вы писали:

К>>Просто для ФП не нужны дополнительные костыли в виде "паттернов" и всё решается "из каробки", т.к. функции первоклассные значения.

LP>Так ведь фп здесь не при чем. ФП — это не изменяемые значения. Все. А "функции — первоклассные значения" — лишь практика, прижившаяся в фп.

Нет "функции — первоклассные значения" — это практически определение ФП

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

К>Здравствуйте, LaPerouse, Вы писали:
LP>>Здравствуйте, Курилка, Вы писали:
К>>>Просто для ФП не нужны дополнительные костыли в виде "паттернов" и всё решается "из каробки", т.к. функции первоклассные значения.
LP>>Так ведь фп здесь не при чем. ФП — это не изменяемые значения. Все. А "функции — первоклассные значения" — лишь практика, прижившаяся в фп.
К>Нет "функции — первоклассные значения" — это практически определение ФП

Из википедии

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.

Как видишь, ни слова про "первоклассные значения"

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

К>>Нет "функции — первоклассные значения" — это практически определение ФП

LP>Из википедии
LP>

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.

LP>Как видишь, ни слова про "первоклассные значения"

Из этого же спорного источника:

These features are a necessity for the functional programming style, in which (for instance) the use of higher-order functions is a standard practice.

Дальнейшее крючкотворство мне неинтресно

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

AP>Уже давно заметил, что нередко применяю метод рефакторинга, который назвал бы "Excract piece of code as parameter". Продемонстрирую на простом примере.

AP>[/c#]
AP>После:
AP>

AP>private static void Main()
AP>{
AP>    Method1((c1, c2) => "" + c1 + c2);
AP>}

AP>private static void Method1(Func<int, long, string> func)
AP>{
AP>    int c1 = 1;
AP>    long c2 = 2;

AP>    string c3 = func(c1, c2);
AP>}
AP>

AP>Я уже дозрел, чтобы написать об этом в форуме разработчиков ReSharper-а. Но встретил мнение, что “… типа не фиг таким увлекаться …”. Что думаете по этому поводу?

Субъективно говоря код стал сложнее в понимании и сопровождении.
Для понимания второго варианта кода нужно посмотреть два разных _логически_не_связанных_ фрагмента кода. Т.е. уменьшается сцепление (cohesion) и увеличивается связность (coupling), а должно быть как раз наоборот.
Практика (во всяком случае моя) подтверждает, что передача делагатов в подобные функции очень усложняют понимание кода. Был проект, в котором потом пришлось распутывать клубок делегатов, поскольку визуально совершенно непонятны потоки передачи информации между объектами, включая клинические случаи, когда один объект указывает открытый метод другого объекта в качестве делегата для третьего.

Единственный разумный рефакторинг, который здесь направшивается — это классический Extract Method:

string SomeMethod(int c1, long c2) {
  return "" + c1 + c2;
}

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

Ваш же вариант, в _данном_конкретном_ случае — явно нарушает принцип KISS и принцип здравой логики (возможно в другом контексте он и даст какие-то преимущества, но в вашем случае — однозначно нет).
Можно говорить о применении паттерна "Стратегия", но в таком случае никакой речи не может быть о таких делегатах, как Func<int, long, string> (ведь контекста в этом типе — ноль). Поскольку речь идет о рефакторинге, то вряд ли можно рассчитывать на тщательный и продуманный анализ, но даже если вы все тщательно продумали и решили, что паттерн "Стратегия" будет полезен, гораздо проще начать с самого простого случая (обычной функции), и добавить паттерн "Стратегия", только тогда, когда он будет _абсолютно_необходим_. А сразу же добавлять паттерн "Стратегия" тогда, когда достаточно одной функции — это явный перебор (в таком случае вспоминаются мысли про паттерны проектирования: мысль1

Автор: XopoSHiy
Дата: 14.04.10

и мысль2

Автор: SergeyT.
Дата: 25.04.10

).

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

LP>>Так ведь фп здесь не при чем. ФП — это не изменяемые значения. Все. А "функции — первоклассные значения" — лишь практика, прижившаяся в фп.

К>Нет "функции — первоклассные значения" — это практически определение ФП

Это чушь

Это необходимо но недостаточно.

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

I>Здравствуйте, Курилка, Вы писали:

LP>>>Так ведь фп здесь не при чем. ФП — это не изменяемые значения. Все. А "функции — первоклассные значения" — лишь практика, прижившаяся в фп.

К>>Нет "функции — первоклассные значения" — это практически определение ФП

I>Это чушь
От тебя сложно ожидать другого

I>Это необходимо но недостаточно.
О достаточности никто ничего не уверждал.

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


I>>Это необходимо но недостаточно.
К>О достаточности никто ничего не уверждал.

"практически определение ФП" это что по твоему ?

Определись, практически определение или же определением практически не является.

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

I>Здравствуйте, Курилка, Вы писали:


I>>>Это необходимо но недостаточно.
К>>О достаточности никто ничего не уверждал.
I>"практически определение ФП" это что по твоему ?

Спор был как раз о том, являются ли "первоклассные функции" необходимым условием. Каждый остался при своем мнении.
Я не буду спорить на эту тему, потому что я и так уже развел флейм. Выскажу только свое мнение. Если бы они являлись необходимым условием, то любая функциональная программа обязана была бы использовать их. Даже foo = 1 был бы нефункциональным. Вот неизменяемые данные — это необходимое условие, потому что при нарушении этого условия программа перестает быть функциональной. Конечно, тут можно сказать, что программа — это одно, а язык — другое. Но утверждение было именно про ФП, а не ФЯ — это раз. И сдается мне язык без ФВП, но с чистыми функциями будет функциональным — это два.

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

AP>Я уже дозрел, чтобы написать об этом в форуме разработчиков ReSharper-а. Но встретил мнение, что “… типа не фиг таким увлекаться …”. Что думаете по этому поводу?

Вот пытаюсь понять смысл получаемого кода, но пока не могу.

ST>Субъективно говоря код стал сложнее в понимании и сопровождении.
ST>Для понимания второго варианта кода нужно посмотреть два разных _логически_не_связанных_ фрагмента кода. Т.е. уменьшается сцепление (cohesion) и увеличивается связность (coupling), а должно быть как раз наоборот.
ST>Практика (во всяком случае моя) подтверждает, что передача делагатов в подобные функции очень усложняют понимание кода. Был проект, в котором потом пришлось распутывать клубок делегатов, поскольку визуально совершенно непонятны потоки передачи информации между объектами, включая клинические случаи, когда один объект указывает открытый метод другого объекта в качестве делегата для третьего.

т.е. Linq это вредное явление, которое не стоит использовать?
идея в linq такая же, каркас оставляем, а мелочевку выносим наружу в виде делегатов.

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

DG>т.е. Linq это вредное явление, которое не стоит использовать?
DG>идея в linq такая же, каркас оставляем, а мелочевку выносим наружу в виде делегатов.

Здесь, наверное, просто пример не удачный, т.к. после выноса кода в делегат, никакого каркаса внутри метода не остается, из-за этого и непонятно для чего это делалось.

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

LP>Спор был как раз о том, являются ли "первоклассные функции" необходимым условием. Каждый остался при своем мнении.
LP>Я не буду спорить на эту тему, потому что я и так уже развел флейм. Выскажу только свое мнение. Если бы они являлись необходимым условием, то любая функциональная программа обязана была бы использовать их. Даже foo = 1 был бы нефункциональным. Вот неизменяемые данные — это необходимое условие, потому что при нарушении этого условия программа перестает быть функциональной. Конечно, тут можно сказать, что программа — это одно, а язык — другое. Но утверждение было именно про ФП, а не ФЯ — это раз. И сдается мне язык без ФВП, но с чистыми функциями будет функциональным — это два.

эээ, я с тобой не согласен.