В последнее время заметил статьи на тему «ООП крут vs процедурное программирование плохо» и «ООП плохо vs процедурное программирование круто» и «ООП и процедурное плохо vs будущее за XYZ принципами», где XYZ какое-то модно новое понятие.
Самое смешное в этих статьях то, что многие под ООП понимают некий принцип когда-то заложенный в C++. И редко кто реально понимает что такое ООП. Вдруг мне показалось что 99% программистов вообще плохо понимают что такое ООП. Но может быть я ошибаюсь? Давайте посмотрим…
Цель статьи не холивар, а попытка осознать иную точку зрения на понятие ООП. Точку зрения не мою, а автора. Самое страшное то что моя точка зрения где то ближе к авторской, но далека от того что понимают под этим термином большинство программистов.
ООП = объектно-ориентированное программирование. Другими словами программирование которое основано на создании неких объектов. И кто-то решил что речь идет о классах. Но кто это решил? Когда? И почему?
Со студенческих скамей можно поднять историю и выяснить что один из первых кто реализовал принципы ООП и запустил их в массы является C++.
Все что шло далее, наследовало именно это понятие. Вс` бы ничего, но есть одна проблема. Все думают что C++ поддерживает и ассоциируется с ООП, кроме автора понятия ООП.
Вот его цитата:
— Ален Кей
Еще много интересных его цитат по ссылкам:
1. Интересная статья на Хабре тут
2. Подборка из 15 цитат часть из которых весьма интересна тут
Часть из этих цитат будут использованы далее для переворачивания сознания.
Автор утверждает что речь идет о чем то похожем на SmallTalk. И рекомендует всем изучать LISP. Но много ли из читателей знакомы с этими языками? Если есть те кто глубоко знаком с этими языками и опытом решения реальных прикладных задач, то буду очень рад за комментарии к этой статье.
Но мое внимание зацепилось еще за ряд его цитат по теме:
И ещё серия для дожатия мысли:
В этих цитатах я бы отметил следующие особенности:
1. Речь не идет о языках программирования, а о подходе.
2. Фокус не на объектах, да и объекты это не то что общепринято
3. Объекты — это модули или компоненты системы (может быть даже отдельные компьютеры и серверы)
4. Суть не в самих объектах, а в способности этих клеток общаться между друг другом посредством сообщений
И вот мы плотно подошли к тому чтобы перевернуть суть понятия ООП.
Речь не о языках программирования. А о способности системы создавать объекты и обеспечивать эффективный обмен сообщениями между ними и взаимодействие. Также стоит отметить мысль о том что таких языков в принципе нет. Есть лишь платформы, которые отчасти смогли приблизиться к этой идеологии.
Мне показалось что я понял суть этой идеи когда искал платформу достаточно гибкую чтобы управлять большими сложными системами, требование к которым менялись ежедневно.
И мне это удалось.
У этой платформы есть ряд соответствий понятию ООП в версии автора:
1. У этой системы компоненты обмениваются сообщениями друг с другом и таким образом позволяют менять поведение друг друга. Один компонент может изменить поведение других компонентов. (соответствие цитате №1).
2. У этой платформы вся суть в том что модули могут взаимодействовать друг с другом. При этом внутри сам модуль может быть написан ужасно кривыми руками глупого джуниора (соответствие цитате №2). И у этой платформы количество модулей самое большое в мире относительно других платформ. Вероятно как раз по той причине что в этой платформе этот принцип сделан лучше чем где-либо.
3. Компонент в этой системе действительно больше походят на клетки, которые могут добавляться или удаляться за доли секунды. Их десятки тысяч. Из них ты строишь систему. При этом каждая такая клетка может обмениваться сообщениями с другими.
4. При этом каждый компонент достаточно автономный и часто может быть отключен и отремонтирован без остановки всей системы. (соответствие цитате №4). Он может обновляться за несколько секунд на лету. Внутри системы может быть более 100 таких компонентов, каждый из которых обновляется отдельной командой разработчиков.
5. Система изначально содержит в себе каналы сообщений. И их связка может быть позднее. В любое время позже когда понадобится. Сегодня я не знаю как поздно и когда в каком месте и какой компонент мне понадобится изменить в будущем. Но я понимаю что с высокой вероятностью смогу это сделать. Как только я пойму какое состояние и какое поведение какого компонента мне нужно будет изменить, я смогу это сделать либо очень просто, либо относительно просто.
Мне показалось что именно эта платформа подошла ближе всего к понятию ООП. Вероятно по этой причина эта платформа захватила рынок. Стала №1 в мире по ряду показателей. Более 25% сайтов в мире и в РФ работает на этой платформе. Это абсолютный мировой рекорд. Думаю многие уже догадались о чем речь :) Это WordPress.
Думаю что в мире есть и другие платформы, которые сумели реализовать принципы ООП близко к тому как это видел автор концепции. Но судя по доле рынка у WP с этим явно наметились успехи. php — это лишь язык программирования. Сам по себе он не дает ООП. ООП образуется только через прослойку, которая дает необходимые методы для взаимодействия компонентов (или объектов в понятии автора концепции)
Еще одна платформа в которой как мне показалось есть эти особенности это Backbone.js. JavaScript как и php не дает нужных методов для ООП, но Backbone.js уже дает. И позволяет создавать объекты и обеспечивать эффективный обмен сообщениями между ними.
Или взять актуальную в последнее время систему микросервисов, которые общаются посредством RESTfull API & Webhooks. Каждый такой веб-сервис является по своей сути объектом в понятии ООП как это видит автор.
Это не попытка навязать свою точку зрения. Это попытка понять кто и как видит эту идеологию. Я люблю ООП в том виде как это принято в php. Использую классы. При этом я не против процедурного программирования и считаю что это хорошо для многих задач. Уважаю подход с REST API и вебхуками. Но каждый метод я не считаю абсолютной истиной и ценю когда каждый инструмент применяется по назначению.
Еще больше мне нравится система хуков в WordPress, которая позволяет создавать действительно сложные системы с сотнями компонентов, каждый из которых может быть добавлен или удален на любом этапе развития системы. Таким образом нам удавалось создавать очень сложные системы для управления бизнес-процессами или агрегаторы с организацией множества процессов и людей. Очень сложные, аналогов которым сложно найти на рынке. И судя по цитатам автора концепции ООП, то механизм хуков и фильтров WordPress сильно ближе к изначальному понятию ООП чем то что принято писать как классы в php и C++.
Кто что думает на этот счет? Кому это понимание ООП близко? Почему? Кто считает это бредом? Почему? Поговорите со мной...:)
Упс. Оказывается все что я тут описал уже общеизвестно и даже есть в википедии — пруф.
И даже то что ООП разделяется на классно-ориентированное и компонентно-ориентированное программирование. Другими словами то ООП что обычно имеют ввиду это классно-ориентированное и это то что было придумано в C++, а то о котором речь в статье это компонентно-ориентированное и это то что было придумано Аленом Кеем.
В статье я ошибся сказав что 99% программистов не знают что такое ООП. В комментариях ошиблись те кто решил что эта идея бред. Как-то так.
Самое смешное в этих статьях то, что многие под ООП понимают некий принцип когда-то заложенный в C++. И редко кто реально понимает что такое ООП. Вдруг мне показалось что 99% программистов вообще плохо понимают что такое ООП. Но может быть я ошибаюсь? Давайте посмотрим…
Цель статьи не холивар, а попытка осознать иную точку зрения на понятие ООП. Точку зрения не мою, а автора. Самое страшное то что моя точка зрения где то ближе к авторской, но далека от того что понимают под этим термином большинство программистов.
Давайте разберем формулировку ООП
ООП = объектно-ориентированное программирование. Другими словами программирование которое основано на создании неких объектов. И кто-то решил что речь идет о классах. Но кто это решил? Когда? И почему?
Со студенческих скамей можно поднять историю и выяснить что один из первых кто реализовал принципы ООП и запустил их в массы является C++.
Все что шло далее, наследовало именно это понятие. Вс` бы ничего, но есть одна проблема. Все думают что C++ поддерживает и ассоциируется с ООП, кроме автора понятия ООП.
Вот его цитата:
Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++
— Ален Кей
Еще много интересных его цитат по ссылкам:
1. Интересная статья на Хабре тут
2. Подборка из 15 цитат часть из которых весьма интересна тут
Часть из этих цитат будут использованы далее для переворачивания сознания.
Если C++ это не тот ООП который имел ввиду автор, то какой тот?
Автор утверждает что речь идет о чем то похожем на SmallTalk. И рекомендует всем изучать LISP. Но много ли из читателей знакомы с этими языками? Если есть те кто глубоко знаком с этими языками и опытом решения реальных прикладных задач, то буду очень рад за комментарии к этой статье.
Но мое внимание зацепилось еще за ряд его цитат по теме:
1. «Я жалею, что придумал термин «объекты» много лет назад, потому что он заставляет людей концентрироваться на мелких идеях. По-настоящему большая идея — это сообщения».
2. «Ключ к тому, чтобы делать большие и расширяющиеся системы, заключается в том, чтобы придумывать, как модули будут общаться друг с другом, а не заботиться об их внутренних свойствах и поведении».
3. «Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениями».
4. «Одна из ключевых идей — делать системы, которые бы продолжали работать во время тестирования и, в особенности, во время внесения изменений. Даже большие изменения должны быть инкрементарными и тратить не больше секунды перед вступлением в силу».
5. ООП для меня это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP.
И ещё серия для дожатия мысли:
Мне жаль, что давным давно я использовал термин «объект» для этой темы, потому что из-за этого многие люди фокусируются на меньшей из идей. Большая идея, которой не хватает современным статически-типизированным ОО-языкам: Большая идея это «сообщения». Ключ к созданию хороших масштабируемых систем это проработка механизмов общения модулей, а не проработка их внутренних свойств и поведения.
В этих цитатах я бы отметил следующие особенности:
1. Речь не идет о языках программирования, а о подходе.
2. Фокус не на объектах, да и объекты это не то что общепринято
3. Объекты — это модули или компоненты системы (может быть даже отдельные компьютеры и серверы)
4. Суть не в самих объектах, а в способности этих клеток общаться между друг другом посредством сообщений
И вот мы плотно подошли к тому чтобы перевернуть суть понятия ООП.
ООП — это архитектура приложения
Речь не о языках программирования. А о способности системы создавать объекты и обеспечивать эффективный обмен сообщениями между ними и взаимодействие. Также стоит отметить мысль о том что таких языков в принципе нет. Есть лишь платформы, которые отчасти смогли приблизиться к этой идеологии.
Мне показалось что я понял суть этой идеи когда искал платформу достаточно гибкую чтобы управлять большими сложными системами, требование к которым менялись ежедневно.
И мне это удалось.
У этой платформы есть ряд соответствий понятию ООП в версии автора:
1. У этой системы компоненты обмениваются сообщениями друг с другом и таким образом позволяют менять поведение друг друга. Один компонент может изменить поведение других компонентов. (соответствие цитате №1).
2. У этой платформы вся суть в том что модули могут взаимодействовать друг с другом. При этом внутри сам модуль может быть написан ужасно кривыми руками глупого джуниора (соответствие цитате №2). И у этой платформы количество модулей самое большое в мире относительно других платформ. Вероятно как раз по той причине что в этой платформе этот принцип сделан лучше чем где-либо.
3. Компонент в этой системе действительно больше походят на клетки, которые могут добавляться или удаляться за доли секунды. Их десятки тысяч. Из них ты строишь систему. При этом каждая такая клетка может обмениваться сообщениями с другими.
4. При этом каждый компонент достаточно автономный и часто может быть отключен и отремонтирован без остановки всей системы. (соответствие цитате №4). Он может обновляться за несколько секунд на лету. Внутри системы может быть более 100 таких компонентов, каждый из которых обновляется отдельной командой разработчиков.
5. Система изначально содержит в себе каналы сообщений. И их связка может быть позднее. В любое время позже когда понадобится. Сегодня я не знаю как поздно и когда в каком месте и какой компонент мне понадобится изменить в будущем. Но я понимаю что с высокой вероятностью смогу это сделать. Как только я пойму какое состояние и какое поведение какого компонента мне нужно будет изменить, я смогу это сделать либо очень просто, либо относительно просто.
Мне показалось что именно эта платформа подошла ближе всего к понятию ООП. Вероятно по этой причина эта платформа захватила рынок. Стала №1 в мире по ряду показателей. Более 25% сайтов в мире и в РФ работает на этой платформе. Это абсолютный мировой рекорд. Думаю многие уже догадались о чем речь :) Это WordPress.
Думаю что в мире есть и другие платформы, которые сумели реализовать принципы ООП близко к тому как это видел автор концепции. Но судя по доле рынка у WP с этим явно наметились успехи. php — это лишь язык программирования. Сам по себе он не дает ООП. ООП образуется только через прослойку, которая дает необходимые методы для взаимодействия компонентов (или объектов в понятии автора концепции)
Еще одна платформа в которой как мне показалось есть эти особенности это Backbone.js. JavaScript как и php не дает нужных методов для ООП, но Backbone.js уже дает. И позволяет создавать объекты и обеспечивать эффективный обмен сообщениями между ними.
Или взять актуальную в последнее время систему микросервисов, которые общаются посредством RESTfull API & Webhooks. Каждый такой веб-сервис является по своей сути объектом в понятии ООП как это видит автор.
Резюме
Это не попытка навязать свою точку зрения. Это попытка понять кто и как видит эту идеологию. Я люблю ООП в том виде как это принято в php. Использую классы. При этом я не против процедурного программирования и считаю что это хорошо для многих задач. Уважаю подход с REST API и вебхуками. Но каждый метод я не считаю абсолютной истиной и ценю когда каждый инструмент применяется по назначению.
Еще больше мне нравится система хуков в WordPress, которая позволяет создавать действительно сложные системы с сотнями компонентов, каждый из которых может быть добавлен или удален на любом этапе развития системы. Таким образом нам удавалось создавать очень сложные системы для управления бизнес-процессами или агрегаторы с организацией множества процессов и людей. Очень сложные, аналогов которым сложно найти на рынке. И судя по цитатам автора концепции ООП, то механизм хуков и фильтров WordPress сильно ближе к изначальному понятию ООП чем то что принято писать как классы в php и C++.
Кто что думает на этот счет? Кому это понимание ООП близко? Почему? Кто считает это бредом? Почему? Поговорите со мной...:)
Upd. 20160811
Упс. Оказывается все что я тут описал уже общеизвестно и даже есть в википедии — пруф.
И даже то что ООП разделяется на классно-ориентированное и компонентно-ориентированное программирование. Другими словами то ООП что обычно имеют ввиду это классно-ориентированное и это то что было придумано в C++, а то о котором речь в статье это компонентно-ориентированное и это то что было придумано Аленом Кеем.
В статье я ошибся сказав что 99% программистов не знают что такое ООП. В комментариях ошиблись те кто решил что эта идея бред. Как-то так.
