Хорошие цитаты. Интересные :)
Давай предположим что твои ссылки на цитаты верны и мои.
И из этой предпосылки попробуй ответить на вопросы, которые мне не под силу:
1.
Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениями
Объект это компьютер в сети, которые обменивается сообщением с другим компьютером в сети. Это следует из определения. Причем тут класс?
Я могу объяснить причем тут класс, только уйдя от значения класса в контексте написания кода. У слова класс есть и другие значения.
При этом с позиции CBD это понятие легко объясняется.
2.
Компонент в этой системе действительно больше походят на клетки, которые могут добавляться или удаляться за доли секунды. Их десятки тысяч. Из них ты строишь систему. При этом каждая такая клетка может обмениваться сообщениями с другими.
Вот как ты добавишь или удалишь класс (в понятии class-based) в большой написанно системе за долю секунды? Тебе как минимум надо будет написать методы расширения этого класса или учесть исключения если ты что то удаляешь? И как ты заставишь классы обмениваться сообщениями?
Упс. А ты заметил в этой цитате слово «компонент»? Или я один его вижу?
Опять же если брать во внимание CBD и в качестве примера WP, то там плагины можно реально включать и отключать за долю секунды, меняя логику обмена сообщениями и поведение системы. Скажем было сообщение о списках главного меню в приложении, мы добавили плагин который добавляет новый раздел, он перехватывает сообщение и добавляет в него новый пункт. На лету. За доли секунды. Модуль сломался, мы просто отключили плагин снова за долю секунды и сообщение перестало перехватываться. Одно сообщение может перехватываться 10 модулями и каждый волен дописать в него свою часть. При этом компонент который изначально владеет этим сообщением вообще не в курсе кто там завтра захочет это сообщение поймать и поиграть с ним. Таким образом мы строили систему из 200 различных модулей которая управляла бизнес процессами в компании на 3000 сотрудников. Оооочень большая и сложная система; Модули включали и отключали за доли секунды. Вся система работала именно так как описывал Ален Кей. При этом где то код был написан как class-based, а где то просто функциями, а где то и прототипы были на JS. Там дофига чего было. Но в основе всего был поставлен CBD-принцип или ООП в понятиях Алена Кея.
Я взял и процитировал. Оформил в статью. Мы прямо сейчас ее комментируем. Прикинь? Если интересно, можно перечитать.
Если проблемы с этим то могу специально для тебя тут повторить 3-4 цитаты которые об этом говорят.
При этом я не заметил или не нашел цитат где Ален Кей говорит о том что в его идеи ООП должны быть классы. Есть ссылка?
Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system.
[...]
Proponents of object-oriented programming (OOP) maintain that software should be written according to a mental model of the actual or imagined objects it represents. [...] Component-based software engineering, by contrast, makes no such assumptions, and instead states that developers should construct software by gluing together prefabricated components
Это хорошее утверждение. Им можно пользоваться в быту. Я с ним согласен.
Единственное что мне в нем не нравиться и что в быту я не говорю в слух, это то что CBD изначально имело имя OOP. Если брать первоисточник и мысль автора. Потом программисты взяли OOP превратили в Class-based, сказали что хай так будет. Просто я за историческую справедливость. И чтобы те кто хают ООП понимали что они хают не отличную идею, а то что из нее вышло благодаря извращению истории.
И конечно же в быту говоря ООП я всегда говорю про class-based, просто потому что бесполезно сопротивляться общепринятым идеям.
Но в уме я всегда понимаю что изначально ООП было хорошей идеей. А идиотизм с class-based возник лишь в ходе истории и слабых умов программистов. Одни умники извратили идею, а другие теперь ее хаят. Так и живем.
Не могу сказать за CORBA. Не достаточно знаний об этой платформе.
В WordPress механика обмена сообщениями между компонентами (плагинами) реализована посредством хуков. Хуки представляют из себя фильтры и реализованные на их базе экшины. И эта механика основана на функциях. Сам же компонент я могу писать через классы или через функции. Это зависит от моих задач и желаний. Если я пишу что-то простое то пишу функциями. Если что то сложное то использую классы. В первом случае можно сказать что компонентная структура работает целиком на функциях, во втором случае на классах. Это не зависит от понятия компоненто ориентированной разработки, а лишь от моего стиля написания кода.
Потому можно сказать что утверждение «Компонентный подход реализуется с помощью классового» где то может быть правдой, а где то бредом.
Но есть мнение что компонентный подход это следующий этап развития класс-ориентированного программирования или ООП как это чаще понимается. Но если включить мозг и изучить первоисточники, забив на школьные учебники то станет ясно что компонентное программирование это не следующий этап развития, а это вообще корень ООП в изначальном понимании которое было просто извращено программистами по ходу работы.
Ну конечно про CORBA. А то что WP соответствует принципам архитектуры компонентов которые обмениваются через сообщения и соответствуют всем принципам ООП которые описал автор — да пофиг. Важно что в Википедии написано CORBA, а вот соответствует ли? Да хз, никто не знает, но упираться рогами в ворота будем до последнего.
не надо обманывать и додумывать.
и да, я дописал апдейт к статье где указал что три.
КомпОП — это разновидность ООП. Еще точнее это и есть ООП в изначальной формулировке. То как это видел автор понятия.
КлассОП — это более популярная разновидность. Которая появилась через C++
Что такое КомпОП реально мало кто из программистов знает. Ну я штук 10 опросил. Ни один ничего внятного не сказал. Все про классы говорят. Ну и комменты в этой статье это явно доказывают. Всего 2 или 3 коммента в тему насчитал. Все остальное просто слюни и вода на тему «а мы думаем иначе».
Оказывается это общеизвестно https://habrahabr.ru/post/307354/#comment_9746612
Есть два подтипа ООП.
То за которое нам тут минусы понаставили называется «классно ориентированное». А то которое народу не понравилось называется «компонентно ориентированное».
В общем описали то что давно известно. Но то о чем 99% программистов не знают. И за это получили минуса ))
Упс. Оказывается все что я тут описал уже общеизвестно и даже есть в википедии — пруф.
И даже то что ООП разделяется на классно-ориентированное и компонентно-ориентированное программирование. Другими словами то ООП что часто имеют ввиду это классно-ориентированное и это то что было придумано в C++, а то о котором речь в статье это компонентно-ориентированное и это то что было придумано Аленом Кеем.
Те системы которые мне известны, которые стали популярны и захватили рынок доказав свою эффективность соответствуют принципу ООП в понятиях Алена Кея не содержат в себе вещей называемых термином «акторы».
Я не против того что акторы имеют место быть и может быть соответствуют изначальному понятию ООП. Мне сложно об этом судить т.к. я не видел ни одной крупной и расширяемой системы которая построена на основе этих штуковин.
Но если будут примеры, то мне будет проще поверить в адекватность этой идеи.
Я не могу доказать обратное без личного опыта, но и без подтверждения с примерами этого утверждения не смогу воспринимать его всерьез. Возможно это так, а может быть и нет. Это все что я могу сказать по этому поводу :)
Вообще можно, но не тебе. Вот именно тебе не дам. Ты мне не нравишься. И не вижу смысла тебе что-либо доказывать.
Если кто-то появится с интересными мыслями и запросит такую инфу, то конечное же предоставлю :)
Не то.
Алан просто придумал и сказал одно, а поняли и начали развивать другое. Вот так точнее.
На выходе имеем хитрый и запутанный омоним. Одно слова и два значения.
Это как слово «ножка» — может быть речь о части тела человека? а может быть о части мебели на которой сидят?
Слово одно — но получило множество значений.
Также и с ООП. Тот кто придумал это понятие думал об одном и это понятие также живет и развивается. Этот подход жив и многие его используют. Но называют его иначе или чаще всего вообще никак не называют.
Но авторы C++ назвали этим словом некий свой механизм, который ассоциируется с классами, инкапсуляцией и наследованием. Развивается параллельно и имеет мало пересечений с тем значением которое было изначально.
Суть и смысл статьи не в том чтобы пытаться менять то ООП которое «классы», а в том чтобы знать правду и что существует второе значение у ООП, которое имелось ввиду автором. Оба инструмента крайне эффективны и полезны если их знать, понимать и уметь применять. Это я говорю как человек которые применяет оба инструмента в работе каждый день. У них реально мало общего — разве что звучание, один автор и то что оба применяются в ИТ. Но по сути это два абсолютно разных принципа и инструмента.
Как то так.
Не вижу противоречий с моим сообщением. Не важно как называется метод доставки: events, хук, канал, процесс и т. д. В разных фреймворках метод обмена называется по разному. Суть в том что в понятии ООП автора этот метод крайне важен и является основной ООП.
А в том как ООП было понято авторами C++ и пущено в массы этому моменту не уделено внимание. Все думают только о методах и свойствах класса с наследованием и инкапсуляцией.
В целом это также попадает в область ООП но является пылинкой от того что имел ввиду автор изначально.
Когда система начинает собираться из множества компонентов которые легко включать и отключать и которые могут менять поведение друг друга и всей системы в целом посредством обмена сообщениями — вот тогда система приближается к изначальному значению понятия ООП.
сомневаюсь что высшее, но допускаю что оно ближе к изначальному понятию ООП от Алена Кея чем то ООП которое придумали авторы C++.
главное понять что есть две версии понятия ООП далекие друг от друга:
1. ООП где объекты это компоненты больших систем которые обмениваются сообщениями и то что имел ввиду Ален Кей
2. ООП где объекты это классы с свойствами и методами которые придумали авторы C++, назвали это ООП и пустили развитие понятия по параллельному пути эволюции далекому от того что имел ввиду автор
И тебе ближе версия №2. А мне ближе версия №1. И кто из нас прав?
Вот только в отличие от тебя я допускаю обе версии. А ты уперся в версию 2 и пытаешься доказать ее правильность.
Ты очень умный. Мне до тебя не дотянуться. Простейший Календарь в MAC OS имеет настройки. А значит обладает свойством настраиваемости.
Вот только он не обладает способностью к созданию больших и сложных систем посредством объектов (компонентов) которые можно легко менять, добавлять, дописывать и удалять и которые обмениваются между собой сообщениями.
Но это вообще не внезапно, нет. Ты очень умный.
вот с C# events не спорю. И я не говорил что на C++ нельзя создать систему с ООП. Скорее всего можно. Только не видел чтобы эти системы были или получили хоть какое-то распространение. И если это так, то значит что то в этих системах не оптимально.
Как только создаются события (хуки, каналы сообщений) и компоненты достаточно гибко начинают обмениваться между собой этими сообщениями, то вот тут мы уже подходим к ООП в изначальном понятии или «ООП как задумывалось».
А пока у нас классы с инкапсуляцией и наследованием то это «ООП как получилось».
И если система эффективна, то она растет, развивается и становится популярной.
А если система хрупка и сложна, то она редка и значит что ее рассматривать не особо интересно. Гораздо интересней рассматривать проблему на примере эффективных и популярных механизмов, доказавших свою адекватность и полезность обществу.
А таковыми являются WP, Drupal, Backbone.js и т д. Только по этой причине я их привел в пример.
Идея на столько глубоко засела в уме, что никак не выходит и эта мысль продиктована через ее призму.
Это сложно. Реально сложно попытаться что-то представить выбросив нечто давно сидящее в голове.
Проблема не в том что ООП изменилось со времен C++. Проблема в том что ООП в C++ никогда не было. И то что мутировало в современное ООП — было чем то другим.
То что называлось как ООП — было не верно понятно изначально и в такой форме родилось и в такой форме развивалось.
Ради прикола можно назвать это «КЛАССное программирование» от слова «класс» по аналогии с функциональным программированием. И это то что сегодня понимается под ООП.
Но тот который когда то произнес это понятие и ввел его в обиход думал о абсолютно других вещах. Вот об этом статья.
И эти понятие не менее поразительны и полезны.
Представьте что кто то сказал слово «Хуркапука» и имел ввиду нечто похожее на мячик.
А кто то взял и сделал лампочку. И сказал что это Хуркапука. И далее все показали на нее пальцем и сказали что это Хуркапука. И Хуркапука развивалась так много лет и вот у нас уже супер современная Хуркапука. Которую кто то любит, а кто то нет. И когда показывают лампочку то все говорят «вот это Хуркапука».
Но суть в том что изначально то под это понятие ввели мячик. И мячик развивался все это время по своей линии эволюции. И он далеко не лампочка.
Вот об этом статья :)
И вот я пытаюсь сказать о том что Хуркапука изначально круглая и ей круто в ворота голы забивать и это имел ввиду автор этого понятия. А народ тут говорит что я дурак и Хуркапука это такая хрень которая светится и ворота ее бить глупо.
Вот так и живем ))
И кто тут дурак? Я как тот кто попытался воссоздать изначальное понятие и рассказать об этом и может быть плохо донес мысль. Или народ который не понял вообще о чем речь и пытается меня обвинить в глупости говоря что мячик мутировал в лампочку и это нормально?
Я согласился бы с этим утверждением, если бы понимал ООП так как большинство. Или так как понимал это 5 лет назад.
Но вот беда, я докопался до мыслей автора и теперь понимаю ООП иначе.
В 2011 году я добрался до предела сложности очередной большой и сложной системы. Она просто начала умирать под гнетом функционала и утопать в постоянно меняющихся требованиях. А затраты на ее обслуживание подскочили до небес. Использовал разные платформы, но всегда очень быстро упирался в предел гибкости. В какой то момент система становится на столько хрупкой что уже с трудом поддается изменениям.
И тогда абсолютно случайно наткнулся на WordPress. И обнаружил что там есть возможность играть компонентами. Добавлять их, отключать, менять их логику не трогая внутренности. И я долго не мог понять как эта способность системы называется. И нашел не так много систем с похожим поведением и механикой взаимодействия компонентов (Drupal, Backbone.js и т. д.). И эта особенность помогла преодолеть предел гибкости и позволила создать очень большую и эффективную систему управления относительно крупной федеральной компанией. Аналогов такой системы на рынке не просто найти.
И не так давно все встало по своим местам когда я наткнулся на цитаты Алена Кея. Оказалось что он тоже искал такие решения и исследовал эту специфику систем. И назвал это свойство ООП. Вот только история с C++ и дальнейшим ходом развития событий привела к тому что понятие ООП мутировало и сегодня понимается не так как задумал автор.
Статья лишь об этом. О том что у ООП есть две стороны: та что популярна и та что была задумана изначально. При этом мне лично и для моих задач более полезной и интересной оказалась та что первоначальная.
И об этом статья. Я не против того как ООП понимают большинство. Более того — я даже сам так программирую. Но хотел лишь сказать что есть и другая сторона — другое понимание этого понятия. То как это задумал автор этого понятия изначально.
Ну а то что большинство программистов оказались не способны это понять — это в общем то не особо удивило :)
Я все же склоняюсь к тому что знать API надо. Не надо знать как он работает внутри. На мой взгляд именно это имел ввиду автор ООП.
Скажем RESTfull API JSON может быть написано на php, ruby или asp.net. Причем внутри он может быть написан на голых функциях без классов и наследования глупым джуниором с говнокодом и кучей ошибок. Но при этом если он отрабатывает все запросы ровно и без ошибок — значит все ок. Объект ведет себя правильно и ожидаемо — значит принцип ООП выполнен.
В плагинах WP тот же принцип. Их более 45 000 штук. Из них 80% написаны ужасно. Открываешь код и хочется рыдать. Но при этом если их включить то в целом система работает. Потому что выполнен базовый принцип ООП — продумана логика обмена сообщениями.
Это не защищает от ошибок на 100%. Если в логике допущены жесткие ошибки то система помрет как и любая другая. Но степень антихрупкости у таких систем сильно выше относительно тех в которых нет механики обмена сообщениями. И компоненты внутри могут быть ужасными, но если на межкомпонентном уровне они себя ведут адекватно, то система будет работать. Возможно в этом причина того что под WP так просто написать новый плагин.
Давай предположим что твои ссылки на цитаты верны и мои.
И из этой предпосылки попробуй ответить на вопросы, которые мне не под силу:
1.
Объект это компьютер в сети, которые обменивается сообщением с другим компьютером в сети. Это следует из определения. Причем тут класс?
Я могу объяснить причем тут класс, только уйдя от значения класса в контексте написания кода. У слова класс есть и другие значения.
При этом с позиции CBD это понятие легко объясняется.
2.
Вот как ты добавишь или удалишь класс (в понятии class-based) в большой написанно системе за долю секунды? Тебе как минимум надо будет написать методы расширения этого класса или учесть исключения если ты что то удаляешь? И как ты заставишь классы обмениваться сообщениями?
Упс. А ты заметил в этой цитате слово «компонент»? Или я один его вижу?
Опять же если брать во внимание CBD и в качестве примера WP, то там плагины можно реально включать и отключать за долю секунды, меняя логику обмена сообщениями и поведение системы. Скажем было сообщение о списках главного меню в приложении, мы добавили плагин который добавляет новый раздел, он перехватывает сообщение и добавляет в него новый пункт. На лету. За доли секунды. Модуль сломался, мы просто отключили плагин снова за долю секунды и сообщение перестало перехватываться. Одно сообщение может перехватываться 10 модулями и каждый волен дописать в него свою часть. При этом компонент который изначально владеет этим сообщением вообще не в курсе кто там завтра захочет это сообщение поймать и поиграть с ним. Таким образом мы строили систему из 200 различных модулей которая управляла бизнес процессами в компании на 3000 сотрудников. Оооочень большая и сложная система; Модули включали и отключали за доли секунды. Вся система работала именно так как описывал Ален Кей. При этом где то код был написан как class-based, а где то просто функциями, а где то и прототипы были на JS. Там дофига чего было. Но в основе всего был поставлен CBD-принцип или ООП в понятиях Алена Кея.
Если проблемы с этим то могу специально для тебя тут повторить 3-4 цитаты которые об этом говорят.
При этом я не заметил или не нашел цитат где Ален Кей говорит о том что в его идеи ООП должны быть классы. Есть ссылка?
Это хорошее утверждение. Им можно пользоваться в быту. Я с ним согласен.
Единственное что мне в нем не нравиться и что в быту я не говорю в слух, это то что CBD изначально имело имя OOP. Если брать первоисточник и мысль автора. Потом программисты взяли OOP превратили в Class-based, сказали что хай так будет. Просто я за историческую справедливость. И чтобы те кто хают ООП понимали что они хают не отличную идею, а то что из нее вышло благодаря извращению истории.
И конечно же в быту говоря ООП я всегда говорю про class-based, просто потому что бесполезно сопротивляться общепринятым идеям.
Но в уме я всегда понимаю что изначально ООП было хорошей идеей. А идиотизм с class-based возник лишь в ходе истории и слабых умов программистов. Одни умники извратили идею, а другие теперь ее хаят. Так и живем.
В WordPress механика обмена сообщениями между компонентами (плагинами) реализована посредством хуков. Хуки представляют из себя фильтры и реализованные на их базе экшины. И эта механика основана на функциях. Сам же компонент я могу писать через классы или через функции. Это зависит от моих задач и желаний. Если я пишу что-то простое то пишу функциями. Если что то сложное то использую классы. В первом случае можно сказать что компонентная структура работает целиком на функциях, во втором случае на классах. Это не зависит от понятия компоненто ориентированной разработки, а лишь от моего стиля написания кода.
Потому можно сказать что утверждение «Компонентный подход реализуется с помощью классового» где то может быть правдой, а где то бредом.
Но есть мнение что компонентный подход это следующий этап развития класс-ориентированного программирования или ООП как это чаще понимается. Но если включить мозг и изучить первоисточники, забив на школьные учебники то станет ясно что компонентное программирование это не следующий этап развития, а это вообще корень ООП в изначальном понимании которое было просто извращено программистами по ходу работы.
и да, я дописал апдейт к статье где указал что три.
КомпОП — это разновидность ООП. Еще точнее это и есть ООП в изначальной формулировке. То как это видел автор понятия.
КлассОП — это более популярная разновидность. Которая появилась через C++
Что такое КомпОП реально мало кто из программистов знает. Ну я штук 10 опросил. Ни один ничего внятного не сказал. Все про классы говорят. Ну и комменты в этой статье это явно доказывают. Всего 2 или 3 коммента в тему насчитал. Все остальное просто слюни и вода на тему «а мы думаем иначе».
Есть два подтипа ООП.
То за которое нам тут минусы понаставили называется «классно ориентированное». А то которое народу не понравилось называется «компонентно ориентированное».
В общем описали то что давно известно. Но то о чем 99% программистов не знают. И за это получили минуса ))
И даже то что ООП разделяется на классно-ориентированное и компонентно-ориентированное программирование. Другими словами то ООП что часто имеют ввиду это классно-ориентированное и это то что было придумано в C++, а то о котором речь в статье это компонентно-ориентированное и это то что было придумано Аленом Кеем.
Я не против того что акторы имеют место быть и может быть соответствуют изначальному понятию ООП. Мне сложно об этом судить т.к. я не видел ни одной крупной и расширяемой системы которая построена на основе этих штуковин.
Но если будут примеры, то мне будет проще поверить в адекватность этой идеи.
Я не могу доказать обратное без личного опыта, но и без подтверждения с примерами этого утверждения не смогу воспринимать его всерьез. Возможно это так, а может быть и нет. Это все что я могу сказать по этому поводу :)
Если кто-то появится с интересными мыслями и запросит такую инфу, то конечное же предоставлю :)
Оставляю за собой право считать иначе. Думаю это всех устроит :)
Алан просто придумал и сказал одно, а поняли и начали развивать другое. Вот так точнее.
На выходе имеем хитрый и запутанный омоним. Одно слова и два значения.
Это как слово «ножка» — может быть речь о части тела человека? а может быть о части мебели на которой сидят?
Слово одно — но получило множество значений.
Также и с ООП. Тот кто придумал это понятие думал об одном и это понятие также живет и развивается. Этот подход жив и многие его используют. Но называют его иначе или чаще всего вообще никак не называют.
Но авторы C++ назвали этим словом некий свой механизм, который ассоциируется с классами, инкапсуляцией и наследованием. Развивается параллельно и имеет мало пересечений с тем значением которое было изначально.
Суть и смысл статьи не в том чтобы пытаться менять то ООП которое «классы», а в том чтобы знать правду и что существует второе значение у ООП, которое имелось ввиду автором. Оба инструмента крайне эффективны и полезны если их знать, понимать и уметь применять. Это я говорю как человек которые применяет оба инструмента в работе каждый день. У них реально мало общего — разве что звучание, один автор и то что оба применяются в ИТ. Но по сути это два абсолютно разных принципа и инструмента.
Как то так.
А в том как ООП было понято авторами C++ и пущено в массы этому моменту не уделено внимание. Все думают только о методах и свойствах класса с наследованием и инкапсуляцией.
В целом это также попадает в область ООП но является пылинкой от того что имел ввиду автор изначально.
Когда система начинает собираться из множества компонентов которые легко включать и отключать и которые могут менять поведение друг друга и всей системы в целом посредством обмена сообщениями — вот тогда система приближается к изначальному значению понятия ООП.
Так ок?
главное понять что есть две версии понятия ООП далекие друг от друга:
1. ООП где объекты это компоненты больших систем которые обмениваются сообщениями и то что имел ввиду Ален Кей
2. ООП где объекты это классы с свойствами и методами которые придумали авторы C++, назвали это ООП и пустили развитие понятия по параллельному пути эволюции далекому от того что имел ввиду автор
И тебе ближе версия №2. А мне ближе версия №1. И кто из нас прав?
Вот только в отличие от тебя я допускаю обе версии. А ты уперся в версию 2 и пытаешься доказать ее правильность.
Вот только он не обладает способностью к созданию больших и сложных систем посредством объектов (компонентов) которые можно легко менять, добавлять, дописывать и удалять и которые обмениваются между собой сообщениями.
Но это вообще не внезапно, нет. Ты очень умный.
Как только создаются события (хуки, каналы сообщений) и компоненты достаточно гибко начинают обмениваться между собой этими сообщениями, то вот тут мы уже подходим к ООП в изначальном понятии или «ООП как задумывалось».
А пока у нас классы с инкапсуляцией и наследованием то это «ООП как получилось».
И если система эффективна, то она растет, развивается и становится популярной.
А если система хрупка и сложна, то она редка и значит что ее рассматривать не особо интересно. Гораздо интересней рассматривать проблему на примере эффективных и популярных механизмов, доказавших свою адекватность и полезность обществу.
А таковыми являются WP, Drupal, Backbone.js и т д. Только по этой причине я их привел в пример.
Это сложно. Реально сложно попытаться что-то представить выбросив нечто давно сидящее в голове.
Проблема не в том что ООП изменилось со времен C++. Проблема в том что ООП в C++ никогда не было. И то что мутировало в современное ООП — было чем то другим.
То что называлось как ООП — было не верно понятно изначально и в такой форме родилось и в такой форме развивалось.
Ради прикола можно назвать это «КЛАССное программирование» от слова «класс» по аналогии с функциональным программированием. И это то что сегодня понимается под ООП.
Но тот который когда то произнес это понятие и ввел его в обиход думал о абсолютно других вещах. Вот об этом статья.
И эти понятие не менее поразительны и полезны.
Представьте что кто то сказал слово «Хуркапука» и имел ввиду нечто похожее на мячик.
А кто то взял и сделал лампочку. И сказал что это Хуркапука. И далее все показали на нее пальцем и сказали что это Хуркапука. И Хуркапука развивалась так много лет и вот у нас уже супер современная Хуркапука. Которую кто то любит, а кто то нет. И когда показывают лампочку то все говорят «вот это Хуркапука».
Но суть в том что изначально то под это понятие ввели мячик. И мячик развивался все это время по своей линии эволюции. И он далеко не лампочка.
Вот об этом статья :)
И вот я пытаюсь сказать о том что Хуркапука изначально круглая и ей круто в ворота голы забивать и это имел ввиду автор этого понятия. А народ тут говорит что я дурак и Хуркапука это такая хрень которая светится и ворота ее бить глупо.
Вот так и живем ))
И кто тут дурак? Я как тот кто попытался воссоздать изначальное понятие и рассказать об этом и может быть плохо донес мысль. Или народ который не понял вообще о чем речь и пытается меня обвинить в глупости говоря что мячик мутировал в лампочку и это нормально?
Но вот беда, я докопался до мыслей автора и теперь понимаю ООП иначе.
В 2011 году я добрался до предела сложности очередной большой и сложной системы. Она просто начала умирать под гнетом функционала и утопать в постоянно меняющихся требованиях. А затраты на ее обслуживание подскочили до небес. Использовал разные платформы, но всегда очень быстро упирался в предел гибкости. В какой то момент система становится на столько хрупкой что уже с трудом поддается изменениям.
И тогда абсолютно случайно наткнулся на WordPress. И обнаружил что там есть возможность играть компонентами. Добавлять их, отключать, менять их логику не трогая внутренности. И я долго не мог понять как эта способность системы называется. И нашел не так много систем с похожим поведением и механикой взаимодействия компонентов (Drupal, Backbone.js и т. д.). И эта особенность помогла преодолеть предел гибкости и позволила создать очень большую и эффективную систему управления относительно крупной федеральной компанией. Аналогов такой системы на рынке не просто найти.
И не так давно все встало по своим местам когда я наткнулся на цитаты Алена Кея. Оказалось что он тоже искал такие решения и исследовал эту специфику систем. И назвал это свойство ООП. Вот только история с C++ и дальнейшим ходом развития событий привела к тому что понятие ООП мутировало и сегодня понимается не так как задумал автор.
Статья лишь об этом. О том что у ООП есть две стороны: та что популярна и та что была задумана изначально. При этом мне лично и для моих задач более полезной и интересной оказалась та что первоначальная.
И об этом статья. Я не против того как ООП понимают большинство. Более того — я даже сам так программирую. Но хотел лишь сказать что есть и другая сторона — другое понимание этого понятия. То как это задумал автор этого понятия изначально.
Ну а то что большинство программистов оказались не способны это понять — это в общем то не особо удивило :)
Скажем RESTfull API JSON может быть написано на php, ruby или asp.net. Причем внутри он может быть написан на голых функциях без классов и наследования глупым джуниором с говнокодом и кучей ошибок. Но при этом если он отрабатывает все запросы ровно и без ошибок — значит все ок. Объект ведет себя правильно и ожидаемо — значит принцип ООП выполнен.
В плагинах WP тот же принцип. Их более 45 000 штук. Из них 80% написаны ужасно. Открываешь код и хочется рыдать. Но при этом если их включить то в целом система работает. Потому что выполнен базовый принцип ООП — продумана логика обмена сообщениями.
Это не защищает от ошибок на 100%. Если в логике допущены жесткие ошибки то система помрет как и любая другая. Но степень антихрупкости у таких систем сильно выше относительно тех в которых нет механики обмена сообщениями. И компоненты внутри могут быть ужасными, но если на межкомпонентном уровне они себя ведут адекватно, то система будет работать. Возможно в этом причина того что под WP так просто написать новый плагин.