Как рекомендации функционального программирования для статических методов влияют на тестируемость?

Question

Чем больше я углубляюсь в функциональное программирование, тем больше читаю рекомендации в пользу статических методов в пользу нестатических. Вы можете прочитать об этой рекомендации в этой книге, например:

http://www.amazon.de/Functional-Programming-Techniques-Projects-Programmer/dp/0470744588

Конечно, это имеет смысл, если вы думаете о функциональной чистоте. Там стоит статическая функция и говорит: «Мне не нужно никакого состояния!»

Однако, как это влияет на тестируемость? Я имею в виду, разве система с большим количеством статических методов становится трудной для тестирования (так как статические методы трудно подделать)? Или макеты играют второстепенную роль в функциональном программировании, и если да, то почему?

EDIT

Так как есть сомнения, действительно ли книга дает такую ​​рекомендацию. Я процитирую немного больше. Надеюсь, это нормально для Оливера Штурма.

Использовать статические методы

Статические методы - одна из основных идей, которую стоит рассмотреть в качестве общего руководства. Он поддерживается многими объектно-ориентированными программистами, и с функциональной точки зрения функции можно сделать статичными большую часть времени. Любая чистая функция может быть сделана статичной. (...)

Некоторые могут утверждать, что идея всегда передавать все параметры означает, что вы не используете идеи объектной ориентации так часто, как могли бы. На самом деле это может быть правдой, но, возможно, это происходит потому, что концепции объектной ориентации не уделяют столько внимания вопросам параллельного выполнения, как следовало бы. (...)

Наконец, рекомендация: если вы написали метод, который не требует доступа ни к какому полю в классе, в котором он живет, сделайте его статическим!

Кстати, до сих пор были хорошие ответы. Спасибо за это!

Answer 1

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

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

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

(я понимаю, что функциональные стили программирования могут использовать ОО через неизменяемые объекты - пожалуйста, прочитайте упоминание ОО выше как «объектно-ориентированное программирование с изменяемым состоянием»)

Edit:

Как указал Фредрик , важной частью функциональных методов является не то, что они являются статическими, а то, что они не изменяют состояние программы . «Чистая» функция представляет собой отображение набора входов на набор выходов (один и тот же вход всегда дает один и тот же результат) и не имеет другого эффекта.

Answer 2

Все «состояние» в чисто функциональном программировании поступает от входов.Для модульного тестирования функциональных программ вы создаете тестовые входы и наблюдаете выходы.Если ваши методы не могут быть протестированы, предоставляя им тестовые входные данные и наблюдая за выходными данными, они недостаточно функциональны.

Answer 3

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

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

Answer 4

В функциональном программировании вы хотели бы имитировать функции вместо объектов. Так что если вы хотите проверить функцию f без зависимости от некоторых ComplicatedAndLongFunction в

f(x)
{
    myx = g(x);
    y = ComplicatedAndLongFunction(myx);
    myy = h(y)
    return myy;
}

Вы можете отделить f от ComplicatedAndLongFunction, введя последнее в f:

f(x, calc)
{
    myx = g(x);
    y = calc(myx);
    myy = h(y)
    return myy;
}

, чтобы вы могли указать поведение calc в своем тесте.

Возникает вопрос (по крайней мере, в моей голове), существуют ли фальшивые рамки, которые позволяют легко определять ожидания функций без необходимости возвращаться к объектам.