От OO до функционального программирования на 10000 футов

Question

Я использую f # и Haskell для изучения функционального программирования на некоторое время. Пока я не получу одобрение в нашей компании, я все равно должен использовать C#. Тем не менее я все еще стараюсь оставаться в функциональном стиле, поскольку я заметил несколько преимуществ.

Вот типичная проблема.

1. Существует ключ-набор таблицы в базе данных с 3 ключами (6,5 млн строк)
2. Есть 4 другие вспомогательные таблицы малого и среднего размера.
3. Существуют сложные формулы, основанные на нескольких входах.

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

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

В настоящее время я делаю следующие предположения для функционального решения.

1. Статические словари плохие. Кажется, что функция может иметь побочные эффекты.

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

3. Традиционные шаблоны OO, вероятно, не сработают.

Как бы вы разработали это на высоком уровне?

Я не прав? Я что-то пропустил?

Answer 1

Нет, вы не ошибаетесь. Оба ООП и функциональное программирование имеют свои преимущества и недостатки.

Разработчик должен знать, как и когда использовать каждый стиль разработки. Хорошо, что C# поддерживает оба стиля разработки.

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

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

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

Answer 2

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

Blockquote 1. Статические словари плохо. Кажется, что функция может иметь побочные эффекты.

Либо у него есть или нет побочных эффектов. Статический словарь может быть хорошим способом реализации memoization на языке OO.

Blockquote 3. Традиционные шаблоны OO, вероятно, не сработают.

Модели OO хорошо работают на языке OO, пытаясь обучить звуковой сигнал. Методы FP в язык OO будут давать подробный и хрупкий код. Это довольно похоже на попытку использовать отвертку с технологией молота, чтобы он дал результат, но есть лучшие способы. Постарайтесь использовать свои инструменты наилучшим образом. Некоторые методы FP могут быть полезны, но полностью игнорируют язык, который не будет делать для кода хорошего качества.

Answer 3

Если вы ищете скорость, вы можете рассмотреть основные структуры данных, которые вы используете. Словарь <> in C# - хеш-таблица, а SortedDictionary <> в C# - двоичное дерево поиска.

F # и Haskell оба выполняют хорошую работу по представлению структур данных дерева. Возможно, вы захотите рассмотреть возможность использования более конкретной структуры данных по умолчанию, которую предоставляет C#.

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

Answer 4

Как бы вы разработали это на высоком уровне?

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

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

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