следовательно классов быть не должно?

или это просто способ добиться чего-то что есть в аббривиатуре?

лол

в аббревиатуре много чего нет

речь сейчас не про нее

давай тогда сначала

что для тебя ООП

как отличить "ооп" от "не ооп"

под "объектами" тут можно понимать что угодно. Какие-то штуки обмениваются сообщениями. точка.

Почему тогда это именно сообщения, а не "какие-то" штуки? Как отличить сообщение от "какой-то" штуки?

что для тебя ООП

методология, которая в наше время тесно связана с развитием языков программирования

методология, которая в наше время тесно связана с развитием языков программирования

под твое определение подходит хаскель

p.s. языки программирования за последние 30 лет не особо развились. Компиляторы - возможно (rust например)

как отличить "ооп" от "не ооп"

ооп использует объекты в качестве основных структурных едениц

ооп использует объекты в качестве основных структурных едениц

уже лучше, уже до структурного программирования добравлись

с наследованием, классами и всем вытекающим

с наследованием, классами и всем вытекающим

зачем нам наследование, классы и все вытекающее? что при помощи них ты хочешь добиться?

p.s. языки программирования за последние 30 лет не особо развились. Компиляторы - возможно (rust например)

golang вполне развитие, выкинули кучу ненужного )

ну то есть вот есть старое доброе процедурное программирование, где данные лежат там, а поведение тут. И поведение берет данные, и что-то с ними делает.

Мне вот интересно, почему это я тебе должен доказывать, что ООП про объекты

golang вполне развитие, выкинули кучу ненужного )

если ты приглядишься, там ничего нового нет

Мне вот интересно, почему это я тебе должен доказывать, что ООП про объекты

сливаешься типа?)

Нет, ну просто ты задаешь вопросы, а я отвечаю. Так диалог не ведется

если ты приглядишься, там ничего нового нет

так это хорошо, взяли основное и фич не добавили

Так ведется допрос, которым ты меня пытаешься запутать

Нет, ну просто ты задаешь вопросы, а я отвечаю. Так диалог не ведется

вполне себе ведется. Я лишь задаю тебе вопросы что бы привести тебя к ответу

потому что если я тебе буду говорить - то ты будешь "лалка ооп это не то я так не привык"

Ну я человек не глупый, ты объясни, почему ООП не про объекты то

Привести? То есть ответа у тебя нет, просто давайте походим вокруг до чего-нибудь, что назовём ответом?

а если ты будешь сам думать - то сам и додумаешься до сути

фига я вбросил

Ну я человек не глупый, ты объясни, почему ООП не про объекты то

блин я и объясняю. Объекты - это вещи. А ООП объясняет как эти вещи должны между собой взаимодействовать.

Ну в этом я с тобой согласен

то есть если ты возьмешь "объекты" и будешь работать с ними без late binding и без messagin ты получишь просто данные и процедуры

тут есть очень простая грань

Но если ООП объясняет взаимодействие объектов, то почему ООП не про объекты?)

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

по сути ООП это подвид структурного программирования

можно сказать доведенный до крайности

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

и поскольку "объект" в каждом языке штуки разные, имеет смысл вообще их не обсуждать

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

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

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

блин это надо метафору по понятнее придумать

я понял твою мысль

объекты - это абстракция

у них куча реализаций

потому лучше вообще их не учитывать в контексте ООП

Ладно, ладно

Привели пример ООП без объектов, так лучше

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

Привели пример ООП без объектов, так лучше

вот да

Привели пример ООП без объектов, так лучше

вы издеваетесь?

Почему

?

ну... в любом случае я уже приводил - erlang

Я не издеваюсь, проглядел

чет я не вижу, где у эрланга ооп

он правда функциональный, но по идеологии которую закладывал Алан Кей к ООП ближе чем всякие явы

чет я не вижу, где у эрланга ооп

потому что повторюсь - ООП не про объекты)

блин где-то была цитата

Эм. Хорошо, в элранге нет объектов. Что обменивается сообщениями?

Эм. Хорошо, в элранге нет объектов. Что обменивается сообщениями?

микротреды

Вообще я тебя понял, твоё понимание ООП отличается от .. Распространенного, что ли

не совсем

Т.е. данные там лежат в полях, которые в функции, которая в треде?

Т.е. данные там лежат в полях, которые в функции, которая в треде?

не совсем, у тебя есть одна какая-то хрень которая хранит данные и код, обрабатывающий эти данные.

а взаимодействие происходит путем обмена сообщениями между элементами системы

Вообще я тебя понял, твоё понимание ООП отличается от .. Распространенного, что ли

другая штука. Распространенное понимание ООП - отсутствие понимания вовсе)

ебашим процедуры завернутые в классы и норм

Уже лучше. Т.е. есть структура, которая хранит не только данные, но и код взаимодействия с этими данными, и мы в рантайме можем изменить этот код и будет иначе работа вестись?

Уже лучше. Т.е. есть структура, которая хранит не только данные, но и код взаимодействия с этими данными, и мы в рантайме можем изменить этот код и будет иначе работа вестись?

не совсем "изменить код", просто поднять новую штуку с новыми данными и новыми кодом, и попросить сообщения слать не старой а новой

подменить реализацию

это late binding nипа

Ну я согласен например. Я и не пытался понять. Надрочил джаву и пошёл на собес

другая штука. Распространенное понимание ООП - отсутствие понимания вовсе)

Я думаю у многих так было

Ну я согласен например. Я и не пытался понять. Надрочил джаву и пошёл на собес

можешь глянуть какой-нибудь видос с David West на тему того как java и провальная политика Xerox погубили smalltalk и ООП

другая штука. Распространенное понимание ООП - отсутствие понимания вовсе)

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

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

в целом еще функциональное имеет смысл позадрачивать - там недопониманий меньше, и идеи очень похожи

другая штука. Распространенное понимание ООП - отсутствие понимания вовсе)

Не, осознавать вещи вместо того что б думать "это так,потому что все так считают" это здраво

культ карго, угу

https://www.youtube.com/watch?v=oiFYPAel-KY

в целом еще функциональное имеет смысл позадрачивать - там недопониманий меньше, и идеи очень похожи

А не больше ли? Именно недопониманий.

буквально вчера @mkusher выкладывал

А не больше ли? Именно недопониманий.

скажем так, если в монады не лазить - то все весьма просто

ну и в теорию типов/категорий

хотя последнее полезно и для ООП

интересный факт, концепт языка программирования с управляющими структурами по типу if/while, с обработкой исключений и т.д. был разработан еще в середине 40-х

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

в основном в языки впиливаются новые плюшки просто что бы бороться неудобствами старых

идеал недостижим, а потому все языки это некий компромис

https://m.habrahabr.ru/post/307720/ вот вам даже на русском

https://m.habrahabr.ru/post/147890/

пробежался по комментам - там тоже много булшита в головах

всё уже разжевано в нельзя, но лень взять и прочитать

но статья вроде бы норм

может за Read Model похоливарим?

например простая задача - список продуктов. Меня беспокоит что типичный разработчик сначала попросит свою любимую ORM замэпить данные на сущности какие-нибудь, потом он напишет сверху еще приблуду которая уже будет мэпить сущности в json или шаблончики которые будут забирать данные оттуда