Объясните на простом примере разницу между ООП и ФП?

Question

[sinevik]

Ребята, поясните вообще разницу в методологии программирования на конкретном просто примере.

Вот этот стиль написания? Он как называется? Процедурный?

router.get('/users', (req, res) => {
  //get users from DB
  res.json(users)
})
router.post('/users', (req, res) => {
  //create user 
  res.json(userCreated)
})

Вот это тоже самое только в стиле ООП (условно.....)

class UserRouter {
  public router = express.Router() 
  public address = '/users'
  constructor() {
    this.initRoutes()
  }
  initRoutes() {
    this.router.get(this.address, this.getUsers)
    this.router.post(this.addressm this.createUser)
  }
  getUsers(req: express.Request, res: express.Response) {
    //get users from DB
    res.json(users)
  }
  createUser(req: express.Request, res: express.Response) {
    //create user
    res.json(userCreated)
  }
}

Хорошо, тогда как будет выглядеть все тоже самое только в функциональном стиле? Хотя бы условно как это будет выглядеть на ФП, не обязательно рабочий код, желательно на js. Если express позволяет использовать только ООП, то можно условно его на что то заменить (главное понять принцип а не рабочий код написать).

Answer 1

[Griboks]

В чистом ФП будет примерно так:

releaseSocket(releaseConnection(releaseRouter(json(get('/users',prepareRequest(createRouter(routerParams,connect(createSocket('TCP'),ip, port)))),users))))

Некоторые приёмы использовать стоит, но не самая лучшая идея - писать в функциональном стиле такие программы.

Comments

[sinevik]

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

[Виталий Першин]

sinevik, Непонятно, потому что пример плохой. Почитайте "Функциональное программирование на JavaScript" Луис Атенсио. Там есть сравнение с ООП, примеры и много чего интересного.

[sinevik]

Виталий Першин, Если вы говорите что пример не удачный, правильно ли я понимаю что писать вообще всю программу на чистом ФП это плохая затея? Потому что пример взят из реальной жизни, самый распространенный. Звучит так, что ФП это какая то мутная тема

[Griboks]

sinevik,

В целом понятно. Просто идет цепочка вызовов функций. Но неужели это удобно использовать.

Абсолютно неудобно и непонятно. Поэтому и придумали ООП. Однако приверженцы ФП яро отвергают классы, поэтому придумали всевозможные классозаменители - контейнеры с условными вызовами.

Например, вместо
connect(createSocket('TCP'),ip, port)
можно написать

connect = tcpSocket=>connect(tcpSocket,ip,port);
createSocket('TCP').then(connect)

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

В чем фишка всего этого ФП, не до конца понимаю

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

Виталий Першин,

Непонятно, потому что пример плохой.

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

Звучит так, что ФП это какая то мутная тема

Это очень мутная тема. Большинство прикольных функциональных фишек JS уже успел себе забрать, например map, reduce, промисы... Вот и осталась одна муть.

[WbICHA]

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

const connection = connect(createSocket('TCP'), ip, port);
const router = createRouter(routerParams, connection);
const request = prepareRequest(router);
const requestedUsers = json(get('/users', request, users));
const releasedRouter = releaseRouter(requestedUsers);
const relesedConnection = releaseConnection(releasedRouter);

releaseSocket(relesedConnection);

На порядок читабельнее, правда?

[Виталий Першин]

sinevik, Я не особо силен в ФП, но мне очень понравился подход и я пытаюсь изучать по возможности, как минимум частичное использование это очень здоров. Как выше сказали map, reduce и много других функций в js реализовали, они и есть пример ФП. Пример из книги, думаю выглядит получше чем пример в ответе:

По отдельности все довольно просто

[WbICHA]

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

[Griboks]

WbICHA,

Вот примерно так он бы выглядел в реальности:

Тогда давайте не будем путать реальность с преднамеренно красивым примером.

function connect(...) {...}

function createRouter(...) {...}

function prepareRequest(...) {...}

function json(...) {...}

function get(...) {...}

function releaseRouter(...) {...}

function releaseConnection(...) {...}

function GetModel(endpoint, requestParams, ip, port, routerParams) 
{
    const connection = connect(createSocket('TCP'), ip, port);
    const router = createRouter(routerParams, connection);
    const request = prepareRequest(router);
    const requestedUsers = json(get(endpoint, request, requestParams));
    const releasedRouter = releaseRouter(requestedUsers);
    const relesedConnection = releaseConnection(releasedRouter);

    releaseSocket(relesedConnection);
    return requestedUsers;
}

function Main(){
    users = GetModel('/users', {...}, ..., ..., {...});
    avatars = GetModel('/avatars', {...}, ..., ..., {...}); 
    posts= GetModel('/posts', {...}, ..., ..., {...});
    console.log(users, avatar, posts); // По законам ФП все полученные данные после данной строчки мы должны удалить.
}

Так, неплохо, с запросами разобрались. Осталось написать ещё 100 функций для других вещей. Кстати, наверное, неудобно все функции хранить в одном файле. Давайте сгруппируем их по модулям. Теперь у нас есть классы, поздравляю!

[sinevik]

Griboks,

function GetModel(endpoint, requestParams, ip, port, routerParams) 
{
    const connection = connect(createSocket('TCP'), ip, port);
    const router = createRouter(routerParams, connection);
    const request = prepareRequest(router);
    const requestedUsers = json(get(endpoint, request, requestParams));
    const releasedRouter = releaseRouter(requestedUsers);
    const relesedConnection = releaseConnection(releasedRouter);

    releaseSocket(relesedConnection);
    return requestedUsers;
}

Вот эта штука. Что то похожее на класс

[WbICHA]

Griboks,

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

Кстати, наверное, неудобно все классы хранить в одном файле. Давайте сгруппируем их по модулям. Теперь у нас есть классы в классах, поздравляю!

А если серьёзно, то какие нафиг это классы? Это неймспейсы собственной персоной. Причём как неймспейсы их никто почти никогда не использует, а импортируют конкретные функции.

[Griboks]

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

[WbICHA]

Griboks,

затем переменные в них

Переменные в теле модуля? Ну-ну. Константы да, но на то они и константы.

потом вложенные структуры

А конкретнее?

И да, повторюсь, раз кое кто не прочёл это ранее:

Вообще, лучше использовать всё самое лучшее из разных подходов и будет тебе счастье. Использовать исключительно один подход, имхо, это минус, а не плюс.

Answer 2

[mayton2019]

На чистом ФП программировать достаточно тяжело. Нужно сильно изменить подход к задаче. Чистое ФП предполагает что когда вы вызываете функцию то "вся вселенная замерла". И второй вызов функции с такими-же параметрами будет видеть эту-же мертвую версию вселенной. Это если вобщем.

Наш мир состоит из постоянно менающихся объектов. Файлы. Сетевые соединения. Объекты в БД. Это грязный мир. И натянуть на него ФП парадигму довольно сложно. В хаскель довольно жёстко порешали с этим. Сказали что есть монада IO. И если функция ее возвращает - то она работает с таким грязным миром. Всё остальное - чистое. Тоесть провели границу.

Как тебе конфигурить твой роутер в ФП - я честно говоря не знаю. Мы должны сначала договориться об абстракциях. И понять где проходят границы чистого и грязного миров. Что делает get users from DB. Изменяет ли он мир? Или может вернуть внезамно другой результат при тех-же аргументах. Это все - сложные вопросы которые просто выходят за рамки твоего.

Поэтому лучше не парь себе мозги именно таким вопросом. Кстати функциональщики тоже не могут сойтись на мнении например считать ли Sheme функциональным или мультипарадигменным языком. Вообще строгого деления на такие классы не существует. Можно просто сказать что когда мы программируем - то мы тяготеем к чему-то больше или меньше. Например форма Бекуса-Науэра (БНФ) - это чистое функциональное описание грамматики. А язык XPath - чистый функциональный. При этом и одно и второе могут быть инкапсулированы в проект на языке Java например который вобщем грязно-императивный. Тоесть в каких-то частях проекта мы сами исповедуем ФП.

Answer 3

[Евгений Симоненко]

Ваши примера кода в обоих случаях в стиле ООП с классами. Привести пример ФП стиля для роутера Express вряд ли получится, так как Express написан в стиле ООП. Можно посмотреть на аналоги на других языках, таких как Haskell, Rust, Scheme.

Answer 4

[DollyPapper]

Разница ИМХО в моделировании задачи. Парадигма у языка может быть не одна, но одна из тех которые язык поддерживает всегда превалирующая. Например в Java можно писать и в функциональном стиле, но большинство проектов это ООП подход.
Сама парадигма дает вам подход для моделирования и декомпозиции задачи. В ООП обьект декомпозиции это обьект, уж простите за тавтологию, в ФП обьект декомпозиции это фукнция. В ООП вы создаете обьект, возможно мутируете его состояние, вызываете у обьекта методы и вот это вот всё. В ФП у вас есть изначальные данные и они должны пройти через цепочку преобразований (вызовов функций) чтобы вычислить конечный результат, при этом изначальные данные не мутируются, и функция (в чистом ФП) всегда идемподентна, т.е. подавая на вход одни и те же данные мы получаем один и тот же результат, что в ООП и других подходах не всегда возможно, поскольку состояние обьекта например может поменять другая часть кода, например в другом потоке.
Когда говорят про функциональный стиль в JS это чаще всего вые**ны говорящего, потому что в жс просто понадергали фишек из ФП: декларативный подход к написанию кода, каррирование (которое чаще является частичным применением, а не каррированием), иммутабельность. А чисто ФПшный подход я ни разу в жизни если честно не встречал. Да и надо ли оно...

Answer 5

[Алексей Богданов]

Метафоричный взгляд с высока, но без отражения полной сути:

ФП это код ДНК (DNA), программа роста/синтеза системы/организма

ООП это чертеж/схема системы/организма.

Система/организм предназначена для обработки/вычисления входного потока данных в выходной.

Comments

[от это да]

нет причин думать что организмы программируются функцинально
мы не знаем как устроен язык днк