Как структурировать компоненты в FP?

Question

В ООП я структурировал свой код по составу, имел множество компонентов, и я был в некотором роде доволен этим ... Все было аккуратно в коробках :-) Что считается хорошей практикой в ​​чистом FP?

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

например: в дизайне, управляемом доменом: Услуги -> Хранилища

• ServiceA (serviceX, serviceY, repo1, repo2, repo3)
• ServiceB (serviceA, serviceC, serviceZ, repo1, repo2, repo3)
• Сервис C (сервис А, сервис Б)

Что меняется в чистом FP, так это то, что мне не нужно создавать экземпляры всех этих объектов, теперь у меня есть только набор функций ... Умонастроение совершенно иное ... В моем текущем коде все зависимости скрыты, как если бы я использовал «статическую функцию везде в моем коде», что ужасно плохо для тестирования в ООП ...

Как мне думать в чистом FP?

Answer 1

Александр Гранин начал писать книгу о «Функциональном дизайне и архитектуре», к сожалению, он не закончил эту книгу, но сделал ее часть, которую абсолютно стоит прочитать: Источники

Здесь вы также найдете все детали :

• Моделирование архитектуры, анализ требований, проектирование подсистем с точки зрения FP;
• Встроенные и внешние DSL в моделировании предметной области;
• Монады как подсистемы с эффектами;
• Свободные монады в качестве функциональных интерфейсов;
• Другие типы функциональных интерфейсов;
• Инверсия управления в FP (с использованием свободных монадических eDSL);
• STM, IO Ref, MVars в качестве состояния одновременного приложения;
• Объективы;
• State, Reader, Writer,RWS, ST монады в проектировании подсистем;
• GUI и FP;
• Применимость основных методов и подходов, таких как UML, SOLID, GRASP;
• Взаимодействие с нечистыми подсистемами.

Надеюсь, кто-нибудь заплатит ему время, чтобы закончить :-)

Answer 2

Функциональный подход ничем не отличается. Кратко:

1. Всегда переходите от самых общих абстракций к самым конкретным. Это относится и к ООП, однако, FP имеет тенденцию быть более точным в этом. В частности, это означает, что вы держите общие, еще не частично примененные функции, далеко от модулей, потребляющих их.
2. Состав. Хорошо держать свои «примитивные» функции подальше от композиций, особенно длинных. Вы можете относиться к этому как к подпункту № 1, хотя я бы отнес это к важности для себя. (Предупреждение! Некоторые языки, такие как F #, вынуждают новичков использовать операторы типа (|>) для составления функций. Это не ваш способ: не оценивайте их, иначе вы не сможете добиться того, о чем я здесь говорю: убедитесь, что ваша композиция действительно создает новую функцию, и вы сами решаете, когда ее запускать).
3. Никогда не смешивайте IO или изменяемую кодовую базу (IO-монаду в случае Haskell) с чистой кодовой базой.
4. Определите синонимы типа и новые типы, когда это необходимо. Сконфигурируйте свои (Haskell) модули для экспорта только тех битов, которые вы хотели бы быть доступными для потребителей, а не для всего модуля (за исключением случая, когда такой модуль довольно прост, конечно).