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

Question

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

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

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

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

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

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

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

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

3. Традиционные паттерны ОО, вероятно, не будут работать.

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Цитата 3. Традиционные паттерны ОО, вероятно, не сработают.

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