UI на основе функционального программирования

Question

Я изучаю понятия функционального программирования сейчас дни, и профессионально я разработчик Asp.net. Но asp.net заставляет вас слишком часто менять свойства объектов в коде. Функциональное программирование основано на неизменяемых объектах. И применить эту концепцию, чтобы изменить значение текстового поля, будет очень болезненно. Также в некоторых случаях обработчики, такие как аргументы ItemInserted FormView, становятся доступными для разработчика, такого как KeepInInsertMode, который разработчик может изменить на true/false, и в этом случае мы модифицируем входные аргументы, которые противоречат FP. Ваши мысли frnds. Каков правильный способ обработки пользовательского интерфейса в мире программного обеспечения? FP или OOPS.

Answer 1

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

Кроме того, только потому, что asp.net что-то делает определенным образом, означает ли это, что все Структуры OO приняли те же дизайнерские решения. Посмотрите на Ruby on Rails или веб-фреймворк Smalltalk Seaside для другого, но все же подхода OO. Даже ASP.net MVC, например, использует несколько иной подход, чем vanilla ASP.net.

То же самое верно для фреймворков FP для обработки пользовательского интерфейса, с дополнительным предостережением, которое в настоящее время кажется более экспериментальным - то есть я не думаю, что все варианты дизайна были изучены так же, как и для OO-фреймворков. Если вы хотите посмотреть, я рекомендую посмотреть на functional reactive programming (в основном для интерактивной анимации), Links (академический - имеет общие аспекты с LINQ) или LiveLab's reactive framework - каждый из них подчеркивает другой аспект проблемы.

Здесь есть чему поучиться, самое главное, возможно, что нет простого ответа ...

Answer 2

Использование функциональной парадигмы приведет к мысли по-другому: вы не будете удивляться, «что произойдет, когда эта кнопка будет нажата», а скорее: что нового состояния моего приложения после нажатия кнопки.

«Новое состояние» будет использоваться слоем презентации вашего программного обеспечения для работы с графическим интерфейсом.

Это приведет к «состоянию -> событию -> состоянию», что, вероятно, намного более предсказуемо, чем парадигма OO «рассказать, не спрашивать».

Но он также может быть более сложным.