А вот Алан Кей, создатель ООП, говорит об обратном, сами объекты менее важны, чем сообщения.
То, что создал Алан Кей, мало имеет отношения к тому, что сейчас принято называть ООП. То самое ООП, которое он создал, это скорее модель акторов типа Akka или Erlang. Мне удобнее мыслить в терминах интерфейсов и классов, и там нет никаких сообщений (по крайней мере first-class), а есть инкапсуляция, наследование и полиморфизм.
В Rust есть инкапсуляция, наследование и полиморфизм, но это не ООП язык.
Ну и что? Самокат – это транспортное средство, но транспортное средство – это не обязательно самокат.
стараться не прибегать к мутабельности, и смысл ФП — разные вещи. ФП — это скорее отсутствие состояния, а вовсе не иммутабельность
Какая-то каша. Сначала вы про чистые функции говорите, теперь вот почему-то уже это отсутствие состояния. Вообще иммутабельность, отсутствие состояния и чистые функции – это вовсе не взаимоисключающие понятия. Скорее наоборот, это тесно связанные вещи, и если используешь что-то одно, то, скорее всего, ты автоматически получаешь другое. Если ты используешь только иммутабельность, то у тебя 99% кода будет чистым. И если ты пишешь только чистые функции, то у тебя, почти всё будет иммутабельное.
И в том же Хаскеле кстати вполне себе есть наследование, полиморфизм и инкапсуляция
Откуда в Хаскелле наследование? Тайпклассы – это не наследование. Это реализация интерфейса, что совсем не то же самое. Полиморфизм там есть, но другой. В ООП это подтиповой полиморфизм, а там параметрический.
Смысл ООП совершенно не в инкапсуляции и наследования, а в обмене сообщениями между обьектами.
Это неправильное определение ООП. ООП — это как раз инкапсуляция, наследование и полиморфизм.
Смысл ФП вовсе даже не в иммутабельности, а в чистых функциях без побочных эффектов. Мутабельность внутри них вполне себе имеет место быть.
Знаем, на Хаскелле писали. Но в Хаскелле действительно все переменные неизменяемые, так что Дядя Боб всё верно написал. И когда пишешь на Хаскелле, то пытаешься всеми силами не прибегать к мутабельности, т.к. такие действия приходится в монады заворачивать, что резко усложняет код.
В каком из бенчмарков? В первом вызывается new ArrayList<>(sourceList), и он и так выделяет массив точной длины. Во втором размер неизвестен в общем случае – фильтр может быть любым.
Ответ на опрос: использую range(from, to), когда мне нужно использовать i в лямбде внутри тела цикла. В остальных случаях пишу обычный for (int i = ...).
Кстати, в Java 15 наконец-то можно будет нормально создавать временные классы и выгружать их с помощью метода Lookup.defineHiddenClass. Долгожданная фича.
Есть немалая категория кода, которая ожидает, что из Iterable можно получить сколько угодно итераторов.
Не вижу проблемы. Значит, такому коду не надо передавать Stream и всё.
В любом случае, наследование Stream от Iterable принесёт во много раз больше пользы, чем вреда.
Кстати, если вы почитаете javadoc к Iterable, то увидите, что там нигде не написано, что iterator() можно вызывать сколько угодно раз. Так что те, кто завязался на то, что обойти Iterable можно много раз – сами себе злобные Буратины.
То, что создал Алан Кей, мало имеет отношения к тому, что сейчас принято называть ООП. То самое ООП, которое он создал, это скорее модель акторов типа Akka или Erlang. Мне удобнее мыслить в терминах интерфейсов и классов, и там нет никаких сообщений (по крайней мере first-class), а есть инкапсуляция, наследование и полиморфизм.
Ну и что? Самокат – это транспортное средство, но транспортное средство – это не обязательно самокат.
Какая-то каша. Сначала вы про чистые функции говорите, теперь вот почему-то уже это отсутствие состояния. Вообще иммутабельность, отсутствие состояния и чистые функции – это вовсе не взаимоисключающие понятия. Скорее наоборот, это тесно связанные вещи, и если используешь что-то одно, то, скорее всего, ты автоматически получаешь другое. Если ты используешь только иммутабельность, то у тебя 99% кода будет чистым. И если ты пишешь только чистые функции, то у тебя, почти всё будет иммутабельное.
Откуда в Хаскелле наследование? Тайпклассы – это не наследование. Это реализация интерфейса, что совсем не то же самое. Полиморфизм там есть, но другой. В ООП это подтиповой полиморфизм, а там параметрический.
Это неправильное определение ООП. ООП — это как раз инкапсуляция, наследование и полиморфизм.
Знаем, на Хаскелле писали. Но в Хаскелле действительно все переменные неизменяемые, так что Дядя Боб всё верно написал. И когда пишешь на Хаскелле, то пытаешься всеми силами не прибегать к мутабельности, т.к. такие действия приходится в монады заворачивать, что резко усложняет код.
new ArrayList<>(sourceList), и он и так выделяет массив точной длины. Во втором размер неизвестен в общем случае – фильтр может быть любым.Не в суперклассе Object, а в утилитном классе Objects, который в отдельном пакете java.util находится.
Какой кошмар. Статью можно сразу удалять из-за такого позора.
PS. Графики рисует сторонняя тулза.
range(from, to), когда мне нужно использоватьiв лямбде внутри тела цикла. В остальных случаях пишу обычныйfor (int i = ...).IntStream.range(0, this.size).map(i -> i * i * i).sum()работает так же быстро, как и простойforВ вашей ссылке нет ничего про запрет использования префикса I.
-Xmoduleи-Xpatch, видимо, были в ранних версиях Java 9, но потом поменялись на--patch-module. Правильные строки запуска такие:Не вижу проблемы. Значит, такому коду не надо передавать Stream и всё.
В любом случае, наследование Stream от Iterable принесёт во много раз больше пользы, чем вреда.
Кстати, если вы почитаете javadoc к Iterable, то увидите, что там нигде не написано, что iterator() можно вызывать сколько угодно раз. Так что те, кто завязался на то, что обойти Iterable можно много раз – сами себе злобные Буратины.