Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: На счет ООП программирования  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 600
mayton
До того как начнется метание навоза на турбину.

С++ - это мультипарадигменный язык. Как минимум к ООП можно добавить обобщённое.
И можно просто процедурно говно-кодить.

Тоесть он поддерживает ООП. Но ООП не является доминирующей фичей. Или определяющей
бытие и сознание кодера.

C++ вообще-то изобрели как раз для ООП
он прям ООП-ориентированный, как никто (иди в жопу, ява)
если ООП не нужен, то C
8 июл 19, 01:18    [21922387]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 600
забыл ник
Я же написал, что ближе всего подходит модель акторов, а следовательно erlang/scala. хотя последняя мультипарадигменная.

erlang не ООП Картинка с другого сайта.
8 июл 19, 01:21    [21922388]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
забыл ник
Member

Откуда:
Сообщений: 2811
Видать ответил на все слова, которые понял из моего текста:) Время позднее, придется ждать ликбеза до завтра. и все же, чтобы не выглядеть таким простофилей как сейчас, потрудись перечитать мой пост и загуглить все непонятные слова. ну и задачку со звездочкой никто не отменял.
п.с статические методы и статические классы, раз уж тебе из контекста непонятно:) хотя на досуге можешь заодно подумать чем отличаются классы от обьектов, и необходимы ли первые для имплементации вторых, можно взять для этого яваскрипт ранних версий.
и еще, пылкий отважный вьюноша - горящие глаза и шпага в жопе это хорошо, но зачастую приводит к попаданию в такие вот дурацкие ситуации. но в них есть и польза, если начнете читать и думать, то возможно я помогу тебе стать умнее, а вследствие и востребованнее как специалисту
8 июл 19, 01:34    [21922389]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
Sergunka
Member

Откуда:
Сообщений: 1843
Возращаясь к теме топика. Возьмите как образец к примеру исходные коды того же Spring

https://github.com/spring-projects/spring-security/tree/master/acl/src/main/java/org/springframework/security/acls

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

В общем не стесняйтесь лезть в исходники тем более в яве они все в свободном доступе лежат как молчаливый упрек.
8 июл 19, 02:20    [21922393]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
mayton
Member

Откуда: loopback
Сообщений: 40989
Я про лапшу и лазанью.
8 июл 19, 07:31    [21922410]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
mayton
Member

Откуда: loopback
Сообщений: 40989
полудух
забыл ник
Я же написал, что ближе всего подходит модель акторов, а следовательно erlang/scala. хотя последняя мультипарадигменная.

erlang не ООП Картинка с другого сайта.

Ближе к Lisp я-бы сказал.
8 июл 19, 11:31    [21922536]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
Мозговой_слизень
Member

Откуда:
Сообщений: 3008
забыл ник
ну и обьясни заодно как в обьектноориентированном языке могут быть примитивные типы, статические методы и классы:)


забыл ник
ну а напоследок задача со звездочкой, опиши в чем же суть ооп, и чем эта парадигма отличается от других. Хинты:
1) нужна ли инкапсуляция если состояние не шарится?
2) чем отличается параметрический, adhoc и subtype полиморфизм
3) является ли наследование единственным методом переиспол зования кода? а как насчет prefer composition over inheritance от апологетов ооп:)


Круто. Подкинем дровишек.

0) В ООП могут быть примитивные типы, например int. А пример класса-обертки для этого типа - это Integer.
1) Если состояние не "шарится", то нужна инкапсуляция, потому что иначе нельзя влиять на состояние объекта. Если я правильно отгадал значение слова "шарится".
2) Не вполне понял вопрос.
3) Не является. Ты сам ответил. Есть, например, composition pattern, а есть наследование классов.
8 июл 19, 13:20    [21922638]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
Мозговой_слизень
Member

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

Класс это кусок кода в исходнике, а объект это экземпляр класса в памяти, с которым можно производить действия (менять состояние, вызывать методы, передавать куда-то и т.п.). Верно?
Только вот, думается, "имплементация", скорей, относится к классу, который implements какой-либо интерфейс. То есть класс и объект не связаны какой-либо имплементацией, а вот класс и интерфейс - связаны. Опять же, зависит от того как понимается слово "имплементация". Если буквально "implements", то это к интерфейсам относится.
8 июл 19, 13:27    [21922646]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
забыл ник
Member

Откуда:
Сообщений: 2811
полудух
забыл ник
Я же написал, что ближе всего подходит модель акторов, а следовательно erlang/scala. хотя последняя мультипарадигменная.

erlang не ООП Картинка с другого сайта.

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

А теперь расскажи почему он не ООП? Потому что Его создатель написал что он функциональный? То есть ты судишь по форме а не содержанию, все правильно?
8 июл 19, 13:57    [21922678]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
забыл ник
Member

Откуда:
Сообщений: 2811
полудух

забыл ник
а алан кей, создатель термина ооп считает немного иначе:)

маловато "создать термин", мягко говоря Картинка с другого сайта.
после этого создания ООП довели до такого состояния, что БЕЗ него большие проекты в 2-5 раз сложнее сопровождать

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

полудух
забыл ник
Я в принциме не принимаю ооп как таковое, потому что оно не имеет под собой никской математической основы, в отличие от любой другой, даже процедурной:)

вы "не туда воюете" Картинка с другого сайта.
ООП не про математику

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

Так какие качества\свойства ООП позволяют этого достичь? Где пруфы? Я тебе могу привести десяток причин почему ООП как раз мешает сопровождению
полудух
забыл ник
как в обьектноориентированном языке могут быть примитивные типы, статические методы и классы:)

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

Ну так что, прочитал уже про OOP основанном на prototype? Надо разьяснять? Что насчет статических типов и классов?
8 июл 19, 14:04    [21922688]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
забыл ник
Member

Откуда:
Сообщений: 2811
Мозговой_слизень
Круто. Подкинем дровишек.

С тобой хоть интересно, видно что открыт для дискуссий. Поехали.


Мозговой_слизень
0) В ООП могут быть примитивные типы, например int. А пример класса-обертки для этого типа - это Integer.

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

Мозговой_слизень
1) Если состояние не "шарится", то нужна инкапсуляция, потому что иначе нельзя влиять на состояние объекта. Если я правильно отгадал значение слова "шарится".

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

Суть сводится к тому что полиморфизм он разный бывает, и в ООП он самый корявый. Минус второй кит.

Мозговой_слизень
3) Не является. Ты сам ответил. Есть, например, composition pattern, а есть наследование классов.

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

Что же остается в итоге? Вот я и хотел узнать у парня, что же в ООП помогает поддерживать maintainability, и что вообще отличает ООП от других парадигм.
8 июл 19, 14:19    [21922708]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
забыл ник
Member

Откуда:
Сообщений: 2811
Мозговой_слизень
забыл ник
чем отличаются классы от обьектов, и необходимы ли первые для имплементации вторых

Класс это кусок кода в исходнике, а объект это экземпляр класса в памяти, с которым можно производить действия (менять состояние, вызывать методы, передавать куда-то и т.п.). Верно?

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

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

Ну тут ты совсем не в ту сторону. Я про представление ООП в языке как стратегию. Классы не единственная стратегия
8 июл 19, 14:23    [21922714]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
Мозговой_слизень
Member

Откуда:
Сообщений: 3008
забыл ник
Правильно, а в некоторых языках примитивов нет, есть только объекты, как по фэншую. Так получается все же ООП C++ не совсем такая трушная?:) Тут очень подходит выражение - или крестик сними или трусы одень)

за С++ я не могу говорить, я знаю только 2 языка и 1 чуть-чуть. И среди них нет си.


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


Так ведь мутабельность зависит от класса. Какие-то мутабельные, какие-то нет. Если мутабельный то меняем состояние, если не мутабельный, то получаем состояние, меняем его и записываем в новую ссылку. То есть получаем уже измененный как нам надо объект. Например String не мутабельный. А StringBuilder мутабельный. И это все в одном языке программирования.

забыл ник
Суть сводится к тому что полиморфизм он разный бывает, и в ООП он самый корявый. Минус второй кит.

Я это понимаю так, например. У нас есть тип ссылки и в зависимости от него мы можем (или не можем) получить доступ к полю или методу в классе-наследнике. Корявый ли это способ работы или нет - я думаю зависит от сравнения. Смотря с чем сравниваем.

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


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



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


Вот лично я думаю, ООП это просто способ программирования. Причем в каждом ЯП он будет чем-то отличаться. Это не значит то это логичный, простой и понятный способ. Скорее даже сложный и порой нелогичный. Просто это правила, по которым язык работает. Так сделали разработчики. Точно так же как любой язык - китайский или английский не обязаны быть логичными и поняными. Просто так пошло издавна.
8 июл 19, 14:42    [21922735]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
Мозговой_слизень
Member

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


А я вот что думаю. Если за язык не платят или на нем сложно найти работу, то это плохой язык. И не важно как красиво он написан. Я считаю, язык не имеет права на существование если он не дает разработчику нормально зарабатывать. Вот что сейчас происходит с битриксом например. Вводятся новые классы, новые методы разработки, новые правила. А облегчило ли это жизнь разрабам? Нет, только усложнило потому что нужно переучиваться за ту же зарплату. И только в страшном сне я задумаюсь об условно "прототипах а не классах" в битриксе, потому что я понимаю что это грабеж моей жизненной энергии. Вот и все. Поэтому я лучше уйду в другой более некрасивый язык, но востребованный, чем буду изучать красоту и мудрость создателей какого-то нового языка или фреймворка. Это уже конечно не относится к программированию, но показывает предел рациональности изучения и поклонения какой-либо технологии.
8 июл 19, 14:49    [21922743]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
iOracleDev
Member

Откуда:
Сообщений: 24
Мозговой_слизень
Вот лично я думаю, ООП это просто способ программирования.

Это вид и уровень абстракции, чтобы пользователь пардон программист оперировал понятными ему абстрактными понятиями.
8 июл 19, 14:54    [21922753]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
Мозговой_слизень
Member

Откуда:
Сообщений: 3008
iOracleDev
Мозговой_слизень
Вот лично я думаю, ООП это просто способ программирования.

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

словоблудие) для неокрепших умов звучит убедительно
8 июл 19, 15:12    [21922765]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
забыл ник
Member

Откуда:
Сообщений: 2811
Мозговой_слизень
Так ведь мутабельность зависит от класса. Какие-то мутабельные, какие-то нет. Если мутабельный то меняем состояние, если не мутабельный, то получаем состояние, меняем его и записываем в новую ссылку. То есть получаем уже измененный как нам надо объект. Например String не мутабельный. А StringBuilder мутабельный. И это все в одном языке программирования.

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


Мозговой_слизень
Я это понимаю так, например. У нас есть тип ссылки и в зависимости от него мы можем (или не можем) получить доступ к полю или методу в классе-наследнике. Корявый ли это способ работы или нет - я думаю зависит от сравнения. Смотря с чем сравниваем.

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

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

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


Мозговой_слизень
Вот лично я думаю, ООП это просто способ программирования. Причем в каждом ЯП он будет чем-то отличаться. Это не значит то это логичный, простой и понятный способ.

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

И тебя это устраивает? К тому же не путай чуловеческие языки, зависящие от контекста, от четко структурированных языков программирования, в основе которых математика и логика.
8 июл 19, 15:12    [21922767]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
забыл ник
Member

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


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

Ну тут ты прав. ООП знать надо, но если хочешь развиваться надо понимать его слабости и знать алтернативы. Знание только ООП крайне сужает твою перспективу. Вот даже в твоих ответах постоянно сквозит - класс, наследник, поле..
8 июл 19, 15:14    [21922771]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
Мозговой_слизень
Member

Откуда:
Сообщений: 3008
В общем тут уже можно так далеко уйти что не найдешь откуда пришел)

Вот лично я согласен с тем, что
забыл ник
размазывает код по нескольким классам, и тебе трудно судить о том что будет выполнено только глядя в сам класс.
Это конечно жопа и моя бы воля, я бы всегда писал процедурно т.к это очень просто и понятно. Ну и вряд ли я соглашусь с тем, что ЯП как-то связан с математикой, увы, будучи троешником по математике, можно быть норм программистом. Арифметика да, но математика, увы, я не нашел общего. В математике есть логика (надеюсь) а в программровании ИМХО ее мало, есть просто правила которые нужно запомнить.
8 июл 19, 15:35    [21922802]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
Мозговой_слизень
Member

Откуда:
Сообщений: 3008
забыл ник
Мозговой_слизень
пропущено...


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

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


а какая альтернатива?) Если пишешь на Java "процедурно", то у тебя не скомпилируется класс. А вот если пишешь на PHP, то пожалуйста. ИМХО логика такая. Смотрим индекс тиобе и зарплаты программистов. Находим лучшее сочетание и начинаем поклоняться этому ЯП. Остальное нерационально.
8 июл 19, 15:38    [21922807]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
забыл ник
Member

Откуда:
Сообщений: 2811
Мозговой_слизень
В математике есть логика (надеюсь) а в программровании ИМХО ее мало, есть просто правила которые нужно запомнить.

Ее нет в ООП и только в ООП, о чем я тебе и говорю. Проблема именно в том, что целая индустрия ООП была создана ради того чтобы в профессию могли придти люди чуть ли не с улицы, а что идея то простая, да? Все есть объекты. Освоить логическое программирование или функциональное без математического(технического) бэкграунда уже напорядок сложнее. Да, создание фичи у меня занимает времени больше, в несколько раз больше чем на ООП, но веришь нет, только что чекунл джиру, на меня за год завели 3 бага. Нуллпоинтер я ловил 2 раза - оба прилетали из внещних java-библиотек. И т.д. и т.п. Для бизнема пока все еще выгодно держать толпу ООП манки-кодеров, но из-за распространения многопточности облаков и AI(которым можно будет формализовать рутинное программирование и заменить толпу индусов) маятник уже качнулся имхо. Но тут я могу только водить руками, это лишь мое мнение, я далеко не сейлс и не бизнесмен.
Ты просто попробуй изучить другой язык, радикально отличающийся, например хаскелл, эрланг, идрис. Это тебе даст +100 даже при ООП программировании, код в разы улучшится, я тебе гарантирую. Собственно я и сам иногда пишу на Java, но мутаьельную переменную использовал в последний раз год назад.
8 июл 19, 15:50    [21922831]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
забыл ник
Member

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


А когда java не дай бог умрет, то что делать? Почитай как дельфисты с болью переходили на Java, на этом форуме куча примеров. Никогда не клади все яйца в одну корзину. Да и блин, ну мне лично интересно посоянно узнавать что-то новое, если тебе неинтересно - велик шанс что программирование не про тебя, будем честны. Ну и ты говоришь в основном про масс-маркет, если же говорить о специалистах высокого уровня, то просто НЕОБХОДИМО знать несколько языков\платформ\парадигм чтобы выбрать нужную. И такие спецы это товар штучный, и их не увидишь в индексах тиобе и тд. Можно легко иметь зарплату x2 x3 по рынку от средней, если ты что-то из себя представляешь.
8 июл 19, 15:53    [21922839]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
andreykaT
Member

Откуда:
Сообщений: 2181
парадигмы всего три. чо там учить то. структурная объектная функциональная.

с каждой на следующую прыгать канеш тяжело. и мозголомно когда годами пишешь на одном и том же но тем не менее - возможно. я помню как не понимал ООП а потом "зашло", потом помню как не понимал функциональщину (до сих пор заходит, но мне нравится).

да и в принципе на этом всё. остальное - декорации. ничего нового не придумали и скорее всего не придумают при нынешнем ходе вещей.
8 июл 19, 16:20    [21922863]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
andreykaT
Member

Откуда:
Сообщений: 2181
забыл ник
Мозговой_слизень
В математике есть логика (надеюсь) а в программровании ИМХО ее мало, есть просто правила которые нужно запомнить.

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

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

насчет затаскивания идей фп в ооп согласен. прям очень согласен и в джаве для этого многое есть. многое устарело до ужаса (сривниваю со скалой) но. зато быстро надежно и предсказуемо :)
8 июл 19, 16:24    [21922868]     Ответить | Цитировать Сообщить модератору
 Re: На счет ООП программирования  [new]
mayton
Member

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

Назовите условия при которых Java умрет. Просто всё имеет причины ход и следствие
и мне было-бы тоже интересно пофантазировать на эту тему. Как вариант - научно
техническая революция которая вообще отменит программирование как таковое.
Может быть биоинформатика. Может интеллект роя. Я не знаю. Но это должно
быть нечто настолько сильное что похоронит не только Java но и разом целый
пласт технологий.
8 июл 19, 18:24    [21922995]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Java Ответить