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

полудухзабыл никЯ же написал, что ближе всего подходит модель акторов, а следовательно erlang/scala. хотя последняя мультипарадигменная.
erlang не ООП
Уверен?
Dynamic dispatch - Каждый процесс в Эрланге можно рассматривать как объект, который принимает сообщения. Proved
Encapsulation - Можно ассоциировать отправку сообщения с вызовом метода. А респонс - как результат выполнения вызова. Proved
Subtype polymorphism - Каждый процесс может принимать люые сообщения и реагировать на них определенным образом, unconstrained polymorphism. Proved.
object inheritance (or delegation) - Inheritance в классическом смысле не поддерживается, но делегация юез проблем.
Open recursion - Поддерживается, через посылку сообщений самому себе.

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

полудух
забыл ника алан кей, создатель термина ооп считает немного иначе:)
маловато "создать термин", мягко говоря
после этого создания ООП довели до такого состояния, что БЕЗ него большие проекты в 2-5 раз сложнее сопровождать
Пруфы есть? Какие свойства ООП позволяют упростить сопровождение?Особенно в многопоточных приложениях. Мутабельность? Запутывание данных и логики? Наследование, которое ломает инкапсуляцию? Environmental reasoning? Интересует сравнение с ФП или логическим программированием

полудухзабыл никЯ в принциме не принимаю ооп как таковое, потому что оно не имеет под собой никской математической основы, в отличие от любой другой, даже процедурной:)
вы "не туда воюете"
ООП не про математику
Ну хоть тут не споришь. Только почему то не понимаешь, что раз так, то это полное говнище. Ты вообще инженер по образованию?
полудухон про упрощение сопровождения кода (а сопровождение кода это гораздо, намного, сильно-сильно дольше, чем создание первой версии. Сопровождение это вся жизнь и развитие проекта)
Так какие качества\свойства ООП позволяют этого достичь? Где пруфы? Я тебе могу привести десяток причин почему ООП как раз мешает сопровождению
полудухзабыл никкак в обьектноориентированном языке могут быть примитивные типы, статические методы и классы:)
как в ООП могут быть классы ? серьёзно?
прочитайте книжку по ООП плиз, а то людей сбиваете с правильного пути своей критикой на пустом месте.
Ну так что, прочитал уже про OOP основанном на prototype? Надо разьяснять? Что насчет статических типов и классов?

Мозговой_слизеньКруто. Подкинем дровишек.
С тобой хоть интересно, видно что открыт для дискуссий. Поехали.


Мозговой_слизень0) В ООП могут быть примитивные типы, например int. А пример класса-обертки для этого типа - это Integer.
Правильно, а в некоторых языках примитивов нет, есть только объекты, как по фэншую. Так получается все же ООП C++ не совсем такая трушная?:) Тут очень подходит выражение - или крестик сними или трусы одень)

Мозговой_слизень1) Если состояние не "шарится", то нужна инкапсуляция, потому что иначе нельзя влиять на состояние объекта. Если я правильно отгадал значение слова "шарится".
Смысл в том что обычно апологеты ООП утверждают что ООП стоит на трех китах - инкапсуляция, полиморфизм и наследование, и героически доказывают что это венец программирования. Так вот. Инкапсуляция не нужна если нету мутабельного стейта. Думаешь как можно программировать без мутабельного стейта? Можно, есть множество способов, некоторые ограничвают доступ к мутабельному стейту - actors, STM, другие избегают его вообще - FP.Минус один китенок
Мозговой_слизень2) Не вполне понял вопрос.
Суть сводится к тому что полиморфизм он разный бывает, и в ООП он самый корявый. Минус второй кит.

Мозговой_слизень3) Не является. Ты сам ответил. Есть, например, composition pattern, а есть наследование классов.
Правильно, а ты знаешь почему не рекомендуют использовать наследование? Например попробую напиши корректный метод equals для иерархии классов. Ну а потом почитай почему inheritance breaks incapsulation. Ну а делегация есть почти во всех языках, в других это просто не нужно. Минус третий кит.

Что же остается в итоге? Вот я и хотел узнать у парня, что же в ООП помогает поддерживать maintainability, и что вообще отличает ООП от других парадигм.

Мозговой_слизеньзабыл никчем отличаются классы от обьектов, и необходимы ли первые для имплементации вторых
Класс это кусок кода в исходнике, а объект это экземпляр класса в памяти, с которым можно производить действия (менять состояние, вызывать методы, передавать куда-то и т.п.). Верно?
В общем случае верно. Но есть версии ООП базирующаяся на прототипах а не классах, как пример javascript.

Мозговой_слизеньТолько вот, думается, "имплементация", скорей, относится к классу, который implements какой-либо интерфейс. То есть класс и объект не связаны какой-либо имплементацией, а вот класс и интерфейс - связаны. Опять же, зависит от того как понимается слово "имплементация". Если буквально "implements", то это к интерфейсам относится.
Ну тут ты совсем не в ту сторону. Я про представление ООП в языке как стратегию. Классы не единственная стратегия

Мозговой_слизеньТак ведь мутабельность зависит от класса. Какие-то мутабельные, какие-то нет. Если мутабельный то меняем состояние, если не мутабельный, то получаем состояние, меняем его и записываем в новую ссылку. То есть получаем уже измененный как нам надо объект. Например String не мутабельный. А StringBuilder мутабельный. И это все в одном языке программирования.
Это в тех языках, которые ты знаешь. Есть языки которые запрещают переприсваивание значения переменной, делая их по факту константами. Если тебе надо что-то поменять, то ты просто создаешь копию на основе существующего объекта. Это сильно упрощает разработку для многопоточных приложений. Вообще оператор присваивания(assignment) приносит в любой язык зависимость понятие времени, для достижения корректности программы нужно следить за порядком операций. Для этого изобретают всякие там JMM и happens-before. Нет мутабельности - нет такой проблемы.


Мозговой_слизеньЯ это понимаю так, например. У нас есть тип ссылки и в зависимости от него мы можем (или не можем) получить доступ к полю или методу в классе-наследнике. Корявый ли это способ работы или нет - я думаю зависит от сравнения. Смотря с чем сравниваем.
Полиморфизм в общем случае это способность вызвать кастомный код в зависимости от типа объекта. Все. Методы, поля, наследники это все вторично. Полиморфизм бывает разных типов - параметрический(женерики), subtype - тот о котором ты знаешь и ad-hoc(погугли). Так вот, в этом плане polymorphism самый косячный из них. Потому что размазывает код по нескольким классам, и тебе трудно судить о том что будет выполнено только глядя в сам класс. Это также приводит к сложности с тестированием. Ну и в целом, в ФП у тебя есть функция, ее инпут и аутпут, чтобы понять что не так, тебе достаточно прочитать текст функции и пофиксить. в Случае ООП - тебе надо дебажить, смотреть какие операции привели к такому состоянию объекта и тд. Это называется environmental reasoning(опять можешь погуглить)

Мозговой_слизеньПросто переопределяешь метод конкретно для нужного класса и все. Если это приведет к каким-то проблема с классами-наследниками, то в них можно тоже этот метод переопределить. Или конкретно уже разбираться с возникшей проблемой. Просто вот так теоретизируя, сложно понять в чем именно проблема.

А как же принципы Лисков и сингл респосибилити? Проблема с наследованием как раз в том, что изменения в одном месте могут аффектнуть корректно написанный код в другом классе НЕЯВНО


Мозговой_слизеньВот лично я думаю, ООП это просто способ программирования. Причем в каждом ЯП он будет чем-то отличаться. Это не значит то это логичный, простой и понятный способ.
В этом и проблема, и большинство проектов сейчас фейлится именно из-за этого, это как строить мост на глаз и по интуиции, без сопромата. Сначала героически придумываем себе проблемы а потом решаем. По сути все дизайн паттерны - это суть попытка исправить корявости ООП.
Мозговой_слизеньСкорее даже сложный и порой нелогичный. Просто это правила, по которым язык работает. Так сделали разработчики. Точно так же как любой язык - китайский или английский не обязаны быть логичными и поняными. Просто так пошло издавна.
И тебя это устраивает? К тому же не путай чуловеческие языки, зависящие от контекста, от четко структурированных языков программирования, в основе которых математика и логика.

Мозговой_слизеньзабыл никВ общем случае верно. Но есть версии ООП базирующаяся на прототипах а не классах, как пример javascript.

А я вот что думаю. Если за язык не платят или на нем сложно найти работу, то это плохой язык. И не важно как красиво он написан. Я считаю, язык не имеет права на существование если он не дает разработчику нормально зарабатывать. Вот что сейчас происходит с битриксом например. Вводятся новые классы, новые методы разработки, новые правила. А облегчило ли это жизнь разрабам? Нет, только усложнило потому что нужно переучиваться за ту же зарплату. И только в страшном сне я задумаюсь об условно "прототипах а не классах" в битриксе, потому что я понимаю что это грабеж моей жизненной энергии. Вот и все. Поэтому я лучше уйду в другой более некрасивый язык, но востребованный, чем буду изучать красоту и мудрость создателей какого-то нового языка или фреймворка. Это уже конечно не относится к программированию, но показывает предел рациональности изучения и поклонения какой-либо технологии.
Ну тут ты прав. ООП знать надо, но если хочешь развиваться надо понимать его слабости и знать алтернативы. Знание только ООП крайне сужает твою перспективу. Вот даже в твоих ответах постоянно сквозит - класс, наследник, поле..

Мозговой_слизеньВ математике есть логика (надеюсь) а в программровании ИМХО ее мало, есть просто правила которые нужно запомнить.
Ее нет в ООП и только в ООП, о чем я тебе и говорю. Проблема именно в том, что целая индустрия ООП была создана ради того чтобы в профессию могли придти люди чуть ли не с улицы, а что идея то простая, да? Все есть объекты. Освоить логическое программирование или функциональное без математического(технического) бэкграунда уже напорядок сложнее. Да, создание фичи у меня занимает времени больше, в несколько раз больше чем на ООП, но веришь нет, только что чекунл джиру, на меня за год завели 3 бага. Нуллпоинтер я ловил 2 раза - оба прилетали из внещних java-библиотек. И т.д. и т.п. Для бизнема пока все еще выгодно держать толпу ООП манки-кодеров, но из-за распространения многопточности облаков и AI(которым можно будет формализовать рутинное программирование и заменить толпу индусов) маятник уже качнулся имхо. Но тут я могу только водить руками, это лишь мое мнение, я далеко не сейлс и не бизнесмен.
Ты просто попробуй изучить другой язык, радикально отличающийся, например хаскелл, эрланг, идрис. Это тебе даст +100 даже при ООП программировании, код в разы улучшится, я тебе гарантирую. Собственно я и сам иногда пишу на Java, но мутаьельную переменную использовал в последний раз год назад.

Мозговой_слизеньа какая альтернатива?) Если пишешь на Java "процедурно", то у тебя не скомпилируется класс. А вот если пишешь на PHP, то пожалуйста. ИМХО логика такая. Смотрим индекс тиобе и зарплаты программистов. Находим лучшее сочетание и начинаем поклоняться этому ЯП. Остальное нерационально.

А когда java не дай бог умрет, то что делать? Почитай как дельфисты с болью переходили на Java, на этом форуме куча примеров. Никогда не клади все яйца в одну корзину. Да и блин, ну мне лично интересно посоянно узнавать что-то новое, если тебе неинтересно - велик шанс что программирование не про тебя, будем честны. Ну и ты говоришь в основном про масс-маркет, если же говорить о специалистах высокого уровня, то просто НЕОБХОДИМО знать несколько языков\платформ\парадигм чтобы выбрать нужную. И такие спецы это товар штучный, и их не увидишь в индексах тиобе и тд. Можно легко иметь зарплату x2 x3 по рынку от средней, если ты что-то из себя представляешь.