ООП против функционального программирования: главные ошибки в спорах

Сегодня будет развенчивание мифов, связанных с холиваром: функциональное программирование против объектно-ориентированного программирования. Наверное, вы слышали о том, что существует непримиримое противостояние между сторонниками одного и второго направления. В этой статье мы попробуем разобраться, в чем же причина споров и какое направление перспективнее.

«Ошибка в триллион долларов»?

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

Период, когда наконец-то компьютеры начали входить в дома обычных людей

Для этого нам придется чуть-чуть углубиться в историю. И эта история начинается в конце восьмидесятых - начале девяностых годов. Это тот период, когда наконец-то компьютеры начали входить в дома обычных людей. Вы можете возразить, что компьютеризация началась намного раньше, ведь процессор 086 архитектуры был создан 1978 году. Но стоимость компьютеров в то время была очень высокая. Массовое же развитие и популяризация компьютеров происходили именно в 80-90 годы. В это время цена компьютеров уже была намного ниже, и люди, которые в последствии стали программистами, смогли покупать их для личного пользования.

В те времена ещё не были распространены такие языки программирования как Рython, Ruby, PHP, JavaScript, которые сейчас пользуются популярностью. Тогда широко использовались такие устаревшие ныне языки как Pascal и Си.

Как же программисты структурировали свой код?

Как же программисты структурировали свой код раньше? Еще 30 лет назад для того, чтобы написать программу специалисты выделяли в начале кода специальный блок, в котором объявлялись все переменные. И создать новую переменную, где-то внутри кода, было не просто или даже не было возможности из-за ограничений языка. Если же программисты пытались объявлять переменные в каких-то вложенных частях программы, компиляторы все равно собирали все эти объявления и отправляли в специально выделенный блок. Это происходило потому, что операционной системе надо было дать команду: "Выдели мне определенное количество памяти".

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

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

Объектно-ориентированное программирование создало инновацию

Объектно-ориентированное программирование создало инновацию IT, которая заключается в том, что она позволила логически объединять память и код, который управляет этой памятью. На тот момент это было очень большое и серьезное новшество, так как код после этого начал упрощаться. Одновременно с этим создавались новые интересные способы работы с памятью. Появилось и понятие "виртуальная память", то есть программа теперь могла попросить больший объём, чем был у операционной системы.

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

Программирование не является той дисциплиной, в которой могут навечно укорениться какие-то концепции

С моей точки зрения, программирование не является той дисциплиной, в которой могут навечно укорениться какие-то концепции. Это достаточно новое и достаточно мобильное направление человеческой деятельности, которое с большой готовностью перенимает хорошие и здравые идеи. На рынке IT технологий мы видим очень много вещей, которые приходят под влиянием моды и занимают большое место в программировании. Иногда им требуется совсем немного времени для адаптации, может быть, всего пару лет. Если мы посмотрим на библиотеки типа React, Vue в JavaScript, то новые концепции в них очень быстро прижились и получили свое развитие.

Готовность сообщества к пониманию сложных вещей

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

Примером вышесказанного является идея асинхронного программирования, которая существовала достаточно давно, еще до того, как появилась поддержка асинхронных библиотек. И в JavaScript, и Рython концепция асинхронного программирования развивалась параллельно. То есть мода на асинхронное программирование возникла сразу же в нескольких сообществах. Но суть в том, что в глобальном смысле сообщество программистов было не готово к тому, чтобы осмыслить асинхронный код. Когда же, наконец, был найден способ донесения до программистов концепции асинхронного программирования, тогда началось более активное использование его синтаксиса и подходов в работе. Так асинхронное программирование начало приобретать популярность.

То есть для реализации какой-либо инновации в сфере IT должны быть выполнены следующие условия:

• возникновение креативной идеи
• возможность и способ преподавания, так как чтобы внедрить какую-то идею, даже суперкрутую, требуется, чтобы ею начали пользоваться другие люди
• активное использование

Функциональное программирование - одна из идей, которые пока очень сложно объяснить

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

Холивар создан на пустом месте для рекламы

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

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

Я не являюсь пуристом, и мне кажется, что критерии качества кода — это результат, который он приносит. Вообще качество кода — это отдельный большой вопрос. Сложно сказать, какой код лучше. Самый ужасный код может приносить деньги, а для кого-то это является самым важным критерием. При этом прекрасно написанный код с точки зрения идиом, ценностей и правил может вообще никому быть не нужен. Он может просто существовать в какой-то "палате мер и весов" программирования.

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