>>1173405 (OP)
Классика:
https://youtu.be/lfdAwl3-X_c

https://youtu.be/PIGhKmTCESc
https://youtu.be/75U9eefFYoU
https://youtu.be/3QT7jaoOa9w

>>1173405 (OP)
И другие светочи:
https://youtu.be/RdE-d_EhzmA
https://youtu.be/DOyNfmqwR98

Рано или поздно в мире джавы должна была зародиться эта форма жизни, законы эволюции неумолимы.

Я думаю не стоит забывать, что все вы здесь пидорасы.

>>1173425
>обоссанный и обиженный опущ перекатился вслед

>>1173338
>Если ООП говно, то назови популярные не ООП гуи-библиотеки.
html+css+react

>>1173509
>html
>не ооп
толсто

>>1173513
Евгений Ваганыч, перелогиньтесь.

>>1173531
html это декларативный язык объектной модели документа. с помощью html тегов ты создаешь объекты, а с помощью аттрибутов изменяешь свойства этих объектов.
XAML это то же самое.

>>1173509
Загляни в исходники React, там внутри повсюду классы и объекты.

>>1173492
Рад за тебя.

>>1173537
Тонко, тонко xD

>>1173537
html и DOM связаны между собой чуть менее чем никак. html не обязан отстраиваться в DOM, а DOM не обязан сериализоваться в html.

>>1173537
>html это декларативный язык объектной модели документа
собственно это все равно, что сказать, что JSON это язык создающий объекты js (потому что JavaScript Object Notation же). А это не так.

>>1173561

А кто обязан-то? Джава обязана в байткод компилиться?

Весь исходный код это текстовые файлы, которые смысла без компилятора/интерпретатора не имеют.

>>1173561
а java программы не обязательно компилироваться в java байткод. и что?

>>1173539
Загляни в исходники gtk, там повсюду байты и маллоки.

Алсо, нихуя вы, пацаны, даже на такую толстоту повелись, лол.

>>1173572

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

Главное как ложится-то идеально, лол

>>1173537
>>1173567
>>1173571
Напомню, что тред полон шизиков со способностью к абстракции на уровне Люси.

В мире повелось, что интерфейсы - это контракты для классов, а типы - это общее название всех интерфейсов и примитивов.

>>1172925

Ну так мы услышим что-то новенькое о порочности
>рекурсивной зависимости в определении типа.
?

>>1173405 (OP)
https://jug.ru/2018/04/bugayenko/

>>1174894
Было в прошлом треде. Всем тредом обсуждали это интервью.

>>1173405 (OP)
Сначала прислушивался к его идеям, потом понял что он просто тупая вниманиеблядь. Код с 3 пикчи просто без комментариев. Нахуй его вообще пускают на конференции

Егорка берет сам у себя интервью https://www.youtube.com/watch?v=vXUwE3FGfpg

>>1177825
Есть такое. Главная проблема это то, что он не может в диалог. Неудобные комментарии он просто не замечает. Это говорит о том, что у него слабая доказательная позиция "яскозал!".

Все его комментарии это ссылки на свои же посты.

>>1173405 (OP)
>3 пик
Блядь, у меня тимлид так начал писать после того, как фаулера прочитал, что временные переменные не нужны, а т.к. мы пишем на питоне, то теперь он делает
return хуйня с пика перед этим вообще ничего не делая внутри функции, только def и return

>>1177858
И как читабельно? Кинь примерчик, звучит пиздецово. Как будто ФП себе по вене пустил.

>>1177858
Твоего тимлида случайно не Бугаенко Егором звать?

>>1177915
https://pastebin.com/25AuQMSA
Вот пример одной функции, меня еще и ебет за эту хуйню
Завтра удалю, а то иногда мне кажется, один человек из нашей команды тут сидит

>>1178007
Саша, тебе пизда. Отвечаю.

>>1178013
Как хорошо, что я не саша
Хотя, я чет на код проекта смотрю, он в большинстве случаев однострочники в 120 символов делает, а не такую хуйню, но все равно, есть только def и return

>>1178016
>Как хорошо, что я не саша
Ну блин((

По пасте - выглядит конечно уебищно. Расскажи ему про лишпы и фп, что ли. Натягивать это на питон - как-то странно. Получается говно.

>>1178018
Он закоренелый плюсовик с десятилетним стажем, которого заставили писать на питоне, доверяет только ооп и старым книгам, типа того же фаулера с его рефакторингом

>>1178021
Ну земля ему пухом, чо. Сочувствую, держись там.

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

>>1178000

Кто такой? Чем знаменит?

>>1178112
А ты ты относишься к временным переменным? Нужно совсем их избегать? Как бы ты отрефакторил (несмотря на наличие регулярок в самом xpath, то есть опереруя теми методами, что есть)? Это моя первая работа и скоро он победит, раздавив меня авторитетом, но я подсознательно чувствую, что он советует говно

>>1178113
Шизик известный

>>1178145

Блять, я не заметил, что ему аж три треда уже посвящено.

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

>>1178131

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

> Как бы ты отрефакторил (несмотря на наличие регулярок в самом xpath, то есть опереруя теми методами, что есть)

Ну так там всего-то надо вызвать lxml.xpath с правильно написанным запросом, который выдернет тебе номер страницы. Он по ходу xpath не знает, ну как если бы кто-то не знал про join в SQL и начал бы таблицы объединять циклами.

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

Сделай как он говорит и забей хуй. Я тебе подскажу работающий заговор, от ебнутых начальников: когда он начинает вот так заебывать, делаешь, что он говорит, а сам в кармане держишь дулю. При этом мысленно читаешь мантру "да и хуй маме Вашей". Все, живешь дальше как ни в чем не бывало.

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

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

>>1178159
>Надо понимать, что происходит при объявлении временных переменных.
>В питонке просто увеличится счетчик ссылок
Вы там ебанулись? Любой хоть сколько-нибудь компетентный компилятор в байткод заинлайнит конструкцию вида let x = <expr>; foo(x)

>>1178197
>а потом когда нужно отлаживать, сижу переписываю все с переменными.
Кек.

>>1177825
>Код с 3 пикчи просто без комментариев.
Почему? Идея понятна вполне, просто синтаксис не позволяет такое нормально писать. Непонятно только почему он не пишет new Attempts( 5, ... Зачем второй аргумент под лестницу бросать? Чтобы можно было по-дефолту значение задавать?

>>1178131
>А ты ты относишься к временным переменным? Нужно совсем их избегать?
Единственный плюс их отсутствия - локальность и контекстонезависимость кода. То есть ты можешь практически любой кусок кода из функции изолировать в отдельную функцию минимумом усилий. Огромный минус - на языках в которых синтаксис этого не позволяет, писать без локальных переменных получается очень криво. На хаскеле пойнтфри выглядит норм, в конкатенативных языках подразумевается изначально, в питоне или джаве - сразу нет.

>>1173405 (OP)
более обрыганского кода ещё не видывал, а приходилось даже отсметривать исходники китайских паграместов, которые вообще не знаю о существование ООП, а циклы пишут на вложении блоков трая в бесконечный цикл

>>1178057
Он обезумел, теперь переписывает на это все, что видит, хорошо, что я ухожу через неделю

>>1193036
man ирония

>>1173405 (OP)
3 пик - это же лисп, мать его. Егорка хотя бы осознает это? Ебааать. Лисп этого не заслужил.

>>1213977
Либо он реально не осознает, либо он очень тонкий тролль.

>>1173405 (OP)
Этот ваш Егор лицом похож на чувака, который в нетфликсовском Van Helsing играл солдатика.

>>1192577
какой же он ублюдок

>>1213977
При чем тут лисп? Типа увидел круглые скобочки - значит лисп?))0) Надеюсь, что ты троллишь.

>>1173405 (OP)
Егор, с каких книг вкатиться в ООП? Чтобы там SOLID, cohesion вся хуйня, но чтобы потом не пришлось отучаться.

Егорка, как тебе руби? Проникся ли ты красотой паттернов в ruby on rails?

>>1173409
Посоны, я на питоне пишу программы примерно в стиле Егорки, хотя первый раз про него слышу.
Я буду жить?

>>1246486
>Егор, с каких книг вкатиться в ООП?
The Blue Book.

>>1246509
>Егорка, как тебе руби?
Говно.

>>1246569
>Я буду жить?
Да.

>>1246700
> The Blue Book.
Который про Smalltalk?

>>1246720
Да.

>>1246486
>SOLID
Егору не нравится SOLID же.

>>1244976
На самом деле весь его подход выглядит как кложур.

Алсо вы уже нашли язык на котором его можно реализовать?

>>1249578
>На самом деле весь его подход выглядит как кложур.
Нет, не выглядит. С чего ты это взял? С того, что скобочки, да?))0)

>Алсо вы уже нашли язык на котором его можно реализовать?
Кого "его"? Он на джаве УСПЕШНО пишет, что еще ты "реализовывать" хочешь?

>>1249605
С того что пытается организовывать код имьютабельными структурами, дефектный ты наш))

> на джаве успешно пишет
То есть он в жабе на каждый чих создаёт объект и ни в чем не проседает?

>>1249877
Ты всерьез считаешь, что иммутабельные структуры есть только в кложе?

Ничего не проседает. Ни единого проседа. Когда жвм выполняет его код, можно слышать, как ангелы тихонечко плачут поют на небесах.

>>1249888
> только кложа
Нет, но кложа успешно идеологически форсит этот подход

> не просидает
Есть какие-нибудь пруфы? Статья может быть?

>>1249877
>То есть он в жабе на каждый чих создаёт объект и ни в чем не проседает?

Ну, то есть ты не в курсе, что все ёба-оптимизирующие компиляторы байтоебли, и гцц, и ллвм переводят код в Single static assignment представление, с которым можно дохуя наоптимизироваться?

>>1250098
>Ну, то есть ты не в курсе, что все ёба-оптимизирующие компиляторы байтоебли, и гцц, и ллвм переводят код в Single static assignment представление

В рантайме?

>>1250098
Ну, мне очевидно что конструкции типа 2 + 2 перед запуском приложения преобразуются в результат, я о другом - разве в ран тайме создание объектов не является дорогостоящей операцией?

>>1250106
>- разве в ран тайме создание объектов не является дорогостоящей операцией?

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

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

>>1250106
>в ран тайме создание объектов не является дорогостоящей операцией?
А что может быть дорогостоящего в создании объекта, особенно если это легкий объект?

>>1250220
А то, что процессоры оптимизированы под обработку массивов. разбросанные по памяти объекты создают случайный доступ к памяти и неиспользуют процессорный кеш.
типичная ООП программа работает медленно by design.

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

>>1250265
>40 раз медленнее

В О-нотации вырази мне это "в 40 раз", пожалуйста, вот тогда можно о чем-то говорить.

>>1250265
>подумаешь программа работает в 40 раз медленнее, в 40 раз больше расходует процессорное время и электричество.

В 40 раз по сравнению с чем?

>>1250265

Да и хуй с ней, пускай в 40 раз медленнее - если этой скорости для решения задачи достаточно - то и ебать колотить. На карйняк - ну пусть клиент калькулятор выкинет и купит что-то современное. Сейчас бы + два года на еблю байтов тратить что бы ПОТАНЦЕВАЛ РАСКРЫТЬ.

>>1250269
по сравнению с data oriented дизайном программ

>>1250272
вообще-то это немаленькие деньги.
была где-то кулстория, где разработчики переписали сервер на го и вместо дохуя серверов отсавили всего 2, которые даже не загружались полностью.
вот так то.

>>1250273
>по сравнению с data oriented дизайном программ

И сроки разработки с data oriented дизайном программ тоже в 40 раз больше ?

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

Маняфантазии процедурных байтоёбов

>>1250273

От того что ты будешь называть устаревшее и неэффективное процедурное программирование новыми модными базвордами оно современным подходом не станет.

>>1250276
на го любая макака может писать код. он даже проще js.

ООП языки скоро вымрут. эти языки не приспособлены под современные реалии развития процессоров.
чем больше ядер и кеша будут добавлять в процессоры, тем более java и ко. будут отставать от процедурных языков в скорости

Всё-таки до чего же егор охуенен:

https://www.yegor256.com/2018/01/09/micro-budgeting.html

>>1250285
>Подразумевает что ООП это не один из способов записи процедурных программ.

>>1250265
>в 40 раз больше расходует процессорное время и электричество.
Авотхуй. Процессорное время и электричество ты потратишь электричества на ненужные спекулятивные вычисления. Если процессор тупо ожидает загрузку данных, то он почти нихуя не потребляет.

>>1250285
Быстрее перепилят архитектуру процессоров.

>>1250308
Идиоматический ООП это способ записи процедурных программ, которые проебывают все кеши.
Это не было проблемой, когда процессоры были одноядерными и без кешей и все считали по абстрактной теории сложности

>>1250085
>Нет, но кложа успешно идеологически форсит этот подход
Соглашусь, но не совсем: она форсит моделирование домейна через plain data (которые как бы have to be immutable просто чтобы обеспечить sound семантику), в то время как Егор форсит иммутабельные объекты, а не данные. Все-таки это кардинально разные вещи, as far as I can see.

>Есть какие-нибудь пруфы? Статья может быть?
Ну, если серьезно, то большинство таких вызовов должны анвайндиться жвм, если она может доказать, что здесь нет анбаундед полиморфизма. Гугли monomorphic/megamorphic virtual calls.

>>1250098
Это оптимальное представление для компилятора, а не для рантайма. Компилятор джавы работает с джавой, а не с ssa ir.

>>1250251
В следующей (или следующей за ней) джаве введут value objects, которые будут иммутабельными и с оптимизированым мемори лэйоут. То есть массив таких объектов будет лежать одним чанков в памяти. Алсо, тогда вострубят ангелы в свои небесные трубы, и покаются грешники и злословники, поносившие Егора, но не будет для них страшной кары, ведь простит их Егор, ибо не ведали они, что творят.

>>1250257
Двачую.

>>1250265
Да, абсолютно похуй. Меня не ебет, выполняется программа 2мс или 80мс, это за биологическими пределами восприятия homo sapiens.

>>1250275
Если любую программу переписать на чем угодно, то она будет в 9000 раз оптимизированней, проще и лучше, просто потому что ты уже знаешь, что тебе надо написать.

Алсо, была (и есть) кулстори, где Дропбокс переписал весь свой бэкенд с го на раст, потому что го жрал память как не в себя и тормозил. Так что 1) дело все-таки не в го наверное, не находишь? 2) нам теперь все скрипты вместо баша\питона на расте писать по твоей логике? Максимализм выдает в тебе юнца.

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

Само ООП настолько общая (и мутная) концепция, что оно не вымрет никогда. Class-based ООП тащем-то уже вышло из моды и потихоньку переходит в разряд легаси, но сама идея "взаимодействия stateful объектов через сообщения" is here to stay.

>>1250292
Бля, круто.

http://www.zerocracy.com/policy.html

>>1250339
>Быстрее перепилят архитектуру процессоров.
Пробовали - не взлетело
https://en.wikipedia.org/wiki/Intel_iAPX_432

>>1250292
Бля, заебись:
https://www.yegor256.com/2017/11/28/microtasking.html#comment-3783143762

Ъ-p2p разработка.

Хочу прям сейчас работать в zerocracy, но нет нихуя опыта в Java. Обидно.

Посмотрел я повнимательнее на подход Егора и возник вопрос. Допустим у нас есть класс "книга" у которой в приватных полях есть название, текст, автор итд. Мне необходимо отрендерить библографическую ссылку. Он предлагает инкапсулировать соответствующий метод в этом классе. Т.е. получается, на каждый тип документа (xml, html, tex, doc, odt, plain-text) надо нахуячить отдельный метод (ну или тот же, но перегруженный)? Т.е. если какой-нибудь умник придумает еще один формат, то он должен меня потеребить, чтобы я намонстрячил еще один метод?

>>1250832
У него был про это пост:
https://www.yegor256.com/2016/04/05/printers-instead-of-getters.html

>>1250870
Как Егорка сериализацию изобретал

>>1250870
О спасибо, мне нравится, примерно так и представлял. Ушел читать блог.

>>1250922
>мне нравится
И у тебя получилось динамическое Media непонятно откуда пришедшее. Как ты будешь печатать это медиа, если там, например, данных нету? Исключениями швыряться?
По сути объект с типом возвращает объект без типа. Это привнесение динамических языков в статический язык без какой-то необходимости. Анти-паттерн.

>>1250950
>Как ты будешь печатать это медиа, если там, например, данных нету?
Там всегда есть данные. Подход к разработке гарантирует, что данные есть всегда. Ведь, прежде чем печатать, я попрошу какой-либо объект туда данные положить. Этот объект гарантированно правильный и умеет класть данные в Media. Тип у объекта как раз есть - Media.

>>1250708
Насколько я понял, без опыта ты там будешь работать бесплатно за циферки в профиле. Это выгодно только если ты архитектор (в их терминологии) или ревьювер, ну или просто можешь хреначить таски как бешеный за 10 минут. Остальные разрабы на этом по факту теряют деньги.

>>1250870
И в чем смысл? Это конечно лучше традиционного псевдо-ОО с геттерами и аннотациями, но все еще хуже обыкновенного ФП, где вместо объекта Book у нас была бы просто мапа {:isbn "...", :title "..."} и ОДИН(!) метод для сериализации мапы в жсон\хмл. Результат тот же, только без тонн бойлерплейта.

>>1250950
>Как ты будешь печатать это медиа, если там, например, данных нету?
Объект иммутабельный, поля приватные. Там не может не быть данных, так как все необходимые данные передаются в конструкторе. Если у тебя есть объект, значит он инициализирован. Ты думаешь в терминах сишных структур, а надо думать в терминах объектов (если пишешь на объектно-ориентированном языке).

>По сути объект с типом возвращает объект без типа.
Это называется "programming to an interface". Объявляешь интерфейс и используешь его, а конкретные детали реализации скрываешь. Опять же, это самые основы ООП, бро.

>>1251041
>Объект иммутабельный, поля приватные. Там не может не быть данных, так как все необходимые данные передаются в конструкторе.
Не понял. Вот у тебя есть объект Media, и что ты с ним будешь делать? По сути его можно лишь сдампить на диск, а потом открыть в блокноте и почитать. Все.
Можно еще попробовать десериализовать объект обратно.
По сути именно так, например, сериализация в C# (не знаю как в java) и работает https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.iserializable.getobjectdata?view=netframework-4.7.2.

>>1251074
Что именно ты не понял? Ты спросил, что должен делать Media, если в нашем объекте Book окажутся пустые поля:
>Как ты будешь печатать это медиа, если там, например, данных нету?

Я тебе отвечаю: такой ситуации быть не может, потому что для того, чтобы создать объект Book, тебе нужно вызвать его конструктор, который инициализирует все поля. После инициализации поля не могут быть изменены, так как они объявлены private final. Следовательно, после создания объект всегда находится в "хорошем" состоянии, пустых полей нет, все инициализировано. Ок?

>Вот у тебя есть объект Media, и что ты с ним будешь делать?
Не понял вопроса. В статье же дан пример:

JsonMedia media = new JsonMedia("book");
book.print(media);
JsonObject json = media.json();

Не улавливаю, что тут непонятно?

Алсо, глянь это: https://g4s8.github.io/fully-encapsulated/

>>1173405 (OP)
Лол, у него еще и свой язык есть:
https://github.com/yegor256/eo

Правда он пока не разобрался, зачем нужны дженерики:
https://github.com/yegor256/eo/issues/1

>>1251126
https://en.wikipedia.org/wiki/Overengineering

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

>>1251176
>https://en.wikipedia.org/wiki/Overengineering
ООП - это почти всегда оверинжиниринг, да. Егор эту проблему и пытается решить.

>>1251672
>Как построить дерево на иммутабельных объектах?
Чувак, ты серьезно? Еще спроси, как факториал посчитать на чистых функциях, лол. Ну-ка бегом читать любую книжку по программированию для первокурсников.

>>1251678
Я серьезно. На мутабельных с геттерами и сеттерами - легко.

>>1251679
При каждой модификации ты пересоздаешь все дерево, только-то и всего. Функциональный путь.

>>1251679
>Я серьезно.
Так я тоже:
>бегом читать любую книжку по программированию для первокурсников

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

>>1251688
Не могу найти. Можешь ссылку дать?

>>1251690
https://en.wikipedia.org/wiki/Persistent_data_structure
http://learnyouahaskell.com/zippers
https://arjunkrishnababu96.github.io/tree-implementation-in-haskell/
https://dkalemis.wordpress.com/2014/01/23/trees-in-haskell/
https://hypirion.com/musings/understanding-persistent-vector-pt-1
etc

>>1251691
А на жаве?

>>1251692
Что "на жаве"?

>>1251703
Реализация.

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

>>1251711
Не могу написать. Не могу готовых примеров нагуглить. Их нет, видимо.

>>1251712
>Не могу написать.
Перечитай еще раз. Если что-то непонятно, задавай вопросы.

>Не могу готовых примеров нагуглить.
Зойчем вы тгавите пейсателя? http://mikefroh.blogspot.com/2011/03/immutable-binary-trees.html

>Их нет, видимо.
))
https://github.com/google/guava
https://docs.oracle.com/javase/9/core/creating-immutable-lists-sets-and-maps.htm
http://www.functionaljava.org

>>1251717
>http://mikefroh.blogspot.com/2011/03/immutable-binary-trees.html
public class ImmutableBinaryTree<T extends Comparable<T>> implements ImmutableSet<T> {

private final ImmutableBinaryTree<T> left;
private final ImmutableBinaryTree<T> right;

private ImmutableBinaryTree<T> addSubtree( ImmutableBinaryTree<T> subTree ) {
final ImmutableBinaryTree<T> newLeft = left !=null ? left.addSubtree(subTree.left) : subTree.left;
final ImmutableBinaryTree<T> newRight = right !=null ? right.addSubtree(subTree.right) : subTree.left;
return new ImmutableBinaryTree<T>(newLeft, newRight, value);
}

А так можно?

>>1250251
В жавах и шарпах аллокация объекта в большинстве случаев равносильно bump pointer + чуть чуть инициализации. Добавляешь капельку escape analysis и половина твоих объектов лежит уже на стеке. На их рантаймы не зря тысячелетия человеколет потратили. Хотя да, сам дизайн языков во многом этому мешал.
Вообще про то, как пытались сделать (и сделали) high-performance управляемый код, можно почитать в серии статей http://joeduffyblog.com/2015/11/03/blogging-about-midori/

>>1251725
Как "так"? Либо формулируй нормально, что тебе непонятно, либо иди ртфм.

>>1251860
Да понял, кажется. В сравнении с мутабельным деревом тут нельзя просто изменить ноду - нужно обратиться именно к самому корню, чтобы тот нашел нужную ноду, сделал дело и пересобрал дерево. В мутабельном же можно прям из самой ноды все что нужно сделать.
Вот этот момент смутил:
public static void main(String[] args) {
ImmutableSet<Integer> immutableSet = new ImmutableBinaryTree<Integer>(null, null, firstValue);
for ( int i = 0; i < 100; i++ )
{
immutableSet = immutableSet.add(value);
}

Переменная immutableSet - не final. А если ссылку на такое дерево хранит другой объект - при изменении дерева это и объект затронет?

>>1251926
>при изменении дерева
А оно не изменяется

>>1251936
> immutableSet = immutableSet.add(value);
То, что оно само не меняется, не значит, что не меняются его части. Это иммутабельность по Егору.

>>1251926
>В сравнении с мутабельным деревом тут нельзя просто изменить ноду - нужно обратиться именно к самому корню
Ну, да, ты ведь не можешь изменить ноду (она иммутабельная), тебе нужно создать новое дерево. На практике иммутабельные структуры еще и персистентны, то есть все предыдущие версии у тебя остаются неизменными, поэтому на самом деле при "пересборке" дерева ты просто делаешь ссылку на предыдущую версию. На примере списков: вот есть l1 = [2 3], ты делаешь l2 = l1.with(1), то есть [1 2 3]. Ничего на самом деле не копируется, ты просто создаешь новый список, у которого голова - твой новый элемент (единица), а хвост - старый список (l1). Теперь у тебя доступны обе версии списка, ничего копировать не пришлось и потребление памяти не изменилось; обе версии ссылаются на одну и ту же память, но так как они иммутабельные, для нас это не имеет никакого значения, и юзер этого списка об этом никогда не узнает. Ну, думаю ты уловил идею.

>Переменная immutableSet - не final. А если ссылку на такое дерево хранит другой объект - при изменении дерева это и объект затронет?
Не совсем понял, в чем именно вопрос. Ты спрашиваешь, мол вот если сделать x = 1, а потом сделать x = 2, то затронет ли это изменение остальные места в коде, где я использую число 1. Нет, не затронет. А те, где используется х - затронет (но в приведенном тобой коде ты же видишь, что оно нигде больше не используется).
Короче, мне кажется ты путаешь identity (переменную, именованную ссылку) и value (ее значение, например число или дерево), потому что в джаве из-за ее тяжелого низкоуровневого си-подобного наследия они как бы да, перепутаны и tightly coupled друг с другом. По-моему самое понятное объяснение этого здесь: https://clojure.org/about/state

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

https://www.yegor256.com/2018/08/22/builders-and-manipulators.html
А твои методы БИЛДЕРЫ или МАНИПУЛЯТОРЫ?

У Егора есть что-нибудь про то, как работать со сложными объектами? Например, нужно заменить Tire на каждом из Wheel у Car.
Метод List<Wheel> wheels() "оторвет" колеса у машины.
Кроме того, у Car могут быть не только несколько Wheel, а еще и Engine, несколько Door, Trunk и куча всего. Как получить к ним доступ? Можно было бы завести WheelRegistry и не "отрывать" колеса, а только "указывать" на них, но WheelRegistry не представляет никакой объект в реальной жизни, еще и доступ к него очень сложно получить без "прописки" в state или статики.
Сложно, короче.

>>1253405
> У Егора есть что-нибудь про то, как работать со сложными объектами? Например, нужно заменить Tire на каждом из Wheel у Car.

Сделать новую машину с новыми колесами и новыми шинами.

>>1253405

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

>>1253450
void replaceWheels(Wheels wheels) {
return new Car(this.engine,
this.trunk,
this.doors,
wheels,
this.lights,
this.seats,
etc)
}

?

>>1253465

Именно. Алсо, если у тебя в твоем etc дохуя пунктов, то ты что то делаешь не так. двери, багажник и прочие лонжероны должны быть объединены в кузов, все электроборудование в электрику и.т.д.

Кажется, мы нашли антипода егорки:

https://www.youtube.com/user/jblow888/

>>1253586

https://www.youtube.com/watch?v=ZHqFrNyLlpA

https://www.youtube.com/watch?v=TH9VCN6UkyQ

https://www.youtube.com/watch?v=5Nc68IdNKdg

Охуеть тут шизики собрались, 2.5 треда наговнили.

>>1253597
>>1253595
>>1253587
>>1253586
Так это он про геймдев.

>>1253649

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

>>1253649
Из того, что я читал от Джона, он считает, что его подход должен быть ВЕЗДЕ. Абсолютно. Его язык пиздатый, но иногда его очень заносит. Кейси Муратори (который Handmade Hero стримит) намного приятнее слушать.

>>1173405 (OP)
dfg

>>1253405
car.withNewTires(...)

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

>>1253586
Бойан, вроде обсуждали его уже.

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

Ну и в будущей джаве это все и так будет (вот-вот уже!), так что НЕНУЖНО.

>>1253688
У Jai приятный синтаксис, куча как классных фич (SOA/AOS; вроде как нормальная компайл-тайм рефлексия; переменные для управления функций и стратегий аллоцирования и тд) и безумных фич, которые могут как взлететь, так и сгореть (метапрограммирование как-то начало плюсами попахивать; управление билдом из самого кода).

>>1253687
Оторванные от реальной жизни маняпримеры - классы Book или Name с парой методов, рассматриваемые в вакууме. Чтобы дать нормальный реальный пример надо прямо сейчас работать над таким, и это была бы огромная простыня кода. Как пример пока можешь рассмотреть два случая с обогревателем из игры:

1) У обогревателя есть несколько компонентов, к которым можно получить доступ либо напрямую (public) через имя поля, либо через метод
public <T> T getComponent(Class<T> type) {
. for(IComponent component : components) {
. . if(type.isInstance(component)) {
. . . return type.cast(component);
. . }
. . return null;
. }
}
Как видишь, тут есть почти все, что Егор ненавидит. Как такое провернуть "правильно"? Сейчас компоненты можно легко изменять, а если их сделать иммутабельными, то придется пересобирать всю структуру обогревателя, а она немаленькая.

2) Обогреватель периодически "выпускает тепло" в окружающую среду. Сейчас это реализовано через статический класс:
HeatMap.pushHeat(heat);
А как такое провернуть "правильно"? new Heat(heat) будет просто висеть, никем незамеченный. Хранить HeatMap как стейт? Так его надо при создании объекта откуда-то взять, а он еще сам измениться в дальнейшем может с большой вероятностью.

>>1253714
>У Jai приятный синтаксис
Дальше не читал, сразу видно малолетнего дауна-борщехлеба, до свидания.

>>1253730
>два случая с обогревателем из игры
Щито? Из какой игры? Простыню твою не читал - погугли, что такое ecs, юнидирекшнл датафлоу, вот это все. Вам лишь бы велосипеды поизобретать, ей-богу.

Хотя ладно, чуть-чуть прочитал:
> if(type.isInstance(component)) {
>. . . return type.cast(component);
Пиздец. ПИЗДЕЦ. У вас за такой адовый говнокод до сих пор не убивают? Синглтонами еще приправь, воще заебись будет.

>Обогреватель периодически "выпускает тепло" в окружающую среду. Сейчас это реализовано через статический класс:
Определись с зависимостями. По Егору хотя я на самом деле не ебу, как там по Егору, я в нем не эксперт у тебя скорее будет объект "атмосфера", который будет смотреть на все источники тепла\холода и моделировать движение воздуха, или что там у тебя. В обычной компонентной модели у тебя просто будет в эвентлупе кидаться событие от энтити с твоим компонентом.

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

>>1253730
>Сейчас компоненты можно легко изменять, а если их сделать иммутабельными, то придется пересобирать всю структуру обогревателя, а она немаленькая.
Жуткий страх пересобирания обогревателя означает, что это приходится делать раз в наносекунду? У вас что-то не так с предметной областью.

>>1253778
> ecs
Это и есть ecs.

>какое-то "выпускает тепло", при этом что именно ты делаешь
Есть тепловая энергия в помещении, "выпустить тепло" - значит добавить к этой энергии некоторое значение.

>хотя я на самом деле не ебу, как там по Егору, я в нем не эксперт
Тогда лучше молчи.

>>1253850
Значит, что это игра и нужна производительность. Обогреватель не сам по себе живет, не одна система хранит один из его компонентов у себя.

>>1253907
>Обогреватель не сам по себе живет
Нарушена инкапсуляция же.

>>1253998
Зато скорость есть.

>>1254029
Т.е. всё-таки есть необходимость раз в наносекунду пересобирать обогреватель? Значит что-то не так с предметной областью.

>>1254036
Если бы все объекты были иммутабельными, то пришлось бы.

>>1254036

Внезапно, да, такова предметная область. Любая игра (даже пошаговая) - это интерактивная симуляция в софт-реальном времени, у которой цикл ввод-контроллер-модель-представление должен происходить за 16-32мс (частота кадров царские 60 и бомжарские минимальные 30FPS соответственно). И тепло обогреватель выпускает каждые 16-32мс.

>>1253907
>Это и есть ecs.
Не-а. Хотя ецс - это как мвц, каждый под этим понимает что захочет, но я ведь уточнил

>Есть тепловая энергия в помещении, "выпустить тепло" - значит добавить к этой энергии некоторое значение.
Я тебе в своем посте описал несколько вариантов того, как можно "добавить к этой энергии некоторое значение". Ты жопой читаешь?

>Тогда лучше молчи.
Совсем охуел, петушара? Вместо того, чтобы сказать "спасибо" за подробный ответ или предложить уточнения и контраргументы, типичный двачер начинает говнить, видимо потому что его говнокод назвали говнокодом. Фу таким мудаком быть.

>>1254042
>>1254066
Нахуя пересобирать обогреватель, чтобы выпустить тепло? Алсо, если объекты иммутабельные, то "пересобирание" как раз почти ПОЧТИ бесплатно, але.

>>1254066
А пересобирать-то нахера? Собрали один раз и пусть себе живёт. Или по условию задачи у вас на каждый тик приходится менять параметры обогревателя/заменять его компоненты итд?

>>1254141
Хуйню ты посоветовал. Я хотел услышать ответов от адептов Егора, почитающих Слово его.

>>1254276
>Или по условию задачи у вас на каждый тик приходится менять параметры обогревателя/заменять его компоненты итд
Такое может быть. Например, кто-то его ремонтирует и меняется lastMaintainedTick у компонента Maintanable.

>>1254036
И да, скорость еще и зависит от скорости доступа к компонентам. Два случая, к примеру:
1) Энергосеть рассчитывает потребление энергии за тик и обращается к компоненту обогревателя, но надо еще узнать, выключен он или нет. Быстрый путь: от самого компонента перейти к обогревателю и обратиться к компоненту Flickable (с нарушением инкапсуляции). Долгий путь: пройти по списку всех Flickable и проверить каждый.

2) При построении контекстного меню действий с обогревателем, игра должна знать, какие действия можно совершить. Для этого можно просто обратиться напрямую к компонентам обогревателя, а можно пройтись по каждому из списков возможных для обогревателя компонентов.

>>1254294
В играх нужна производительность и data oriented код, а не ООП и тем более иммутабельность.

>>1254294
>Хуйню ты посоветовал.
Тыскозал? Я тебе перечислил почти все возможные варианты.

>Я хотел услышать ответов от адептов Егора
Ты и услышал, долбоеб.

>Долгий путь: пройти по списку всех Flickable и проверить каждый.
Это как раз быстрый путь, долбоеб, только название хуевое. У потребляющих энергию энтитей есть EnergyConsumer компонент, по которому энергосеть проходится и высчитывает нагрузку, или какая там у тебя логика. При включении\выключении этот компонент обновляется.

>от самого компонента перейти к обогревателю и обратиться к компоненту Flickable
Пиздец просто. Еще синглтонов и кастов добавь, юнитиребенок с говном вместо мозга.

>>1254313
Тащем-то дата-ориентед дизайн не исключает иммутабельности (персистентность вот исключает).

А как Егор относится к имьютабельным ссылкам? Например как тем же атомам в кложуре

>>1254390
Чего нет в жабе, то не нужно.

>>1254390
>имьютабельным ссылкам
Чего-чего? Ку-ку, атомы - это мутабельные ссылки (на то они и ссылки), в которые можно положить иммутабельные данные.

К кложуре Егор вроде относится хорошо (емнип даже патчи хикке в жиру слал, да и его стиль как ни крути получается ей в какой-то степени вдохновлен), так что полагаю и к ее конкуренси примитивам тоже.

Вообще, было бы интересно пописать в его стиле на кложе, потому что те же иммутабельные объекты с полями там создаются одной строчкой: (deftype Yegor [isGood isHole]) - и все, можно дергать этот класс из жавы, никакого бойлерплейта. Плюс лесенки как на третьем оп-пике там с помощью макросов выпрямляются в одну строчку: (-> (Diff. (new Secret) (new Guess)) VerboseDiff. (Attempts. 5) Farewell.) - а с лесенкой хуй проссышь куда там 5 относится.

Единственно, deftype сам по себе не поддерживает добавление методов, все методы должны быть сначала объявлены в интерфейсе\протоколе, но блядь, это опять же ооп- и егор-православно, так что это может даже и плюс, а не минус.

>>1254294
>Такое может быть. Например, кто-то его ремонтирует и меняется lastMaintainedTick у компонента Maintanable.
Возможно, здесь действительно придется вводить мутабельность, но не факт.

>И да, скорость еще и зависит от скорости доступа к компонентам. Два случая, к примеру:
1. Энергосеть должна это спрашивать у обогревателя, а не у его компонентов же. Обогреватель сам посчитает, исходя из потребления компонентов. Разве не так должно быть?

2. Аналогично - контекстное меню запрашивает коллекцию компонентов у обогревателя.

А действительно, как получить нужный компонент?

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

В текущем варианте есть только один тип записи, который хранит массив компонентов. Запись собирается на фабрике с инициализированными компонентами. Доступ к компонентам осуществляется через int тип-переменную в цикле:
for(IComp comp : comps) {
if(comp.isType(ct)) {
return comp.bytes();
}
}
Дальше вызывающий объект пердолит байты в нужный вид. Внешне вызовы выглядит так:
String name = new Name(record).string();
byte[] hash = new Hash(record).hash();

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

>>1255846
>А действительно, как получить нужный компонент?
в java ты их можешь хранить как угодно.

а вообще компоненты одного типа нужно хранить как структуры в одном массиве.

>>1255846
> И это ослабляет связность.
Это же хорошо.

>>1255846
>2018 год
>оопущенцы до сих пор не могут разобраться, как прочитать данные из файла

>>1255928
Вопрос в том, как добраться до нужного. Пикрелейтед.

>>1256468
Я про cohesion, ты coupling имеешь ввиду.

>>1256613
Прочитать-то легко, вопрос в том, как это все красиво оформить.

Сап, двач! Кто-нибудь купил книженцию Егора elegant objects? Может поделитесь пиратской копией?

Как по-егоровски сделать математическую либу?

Integral int("cos(x)*x");
string solution = int.solve()
double defSolution = int.definiteSolution(PI/2, PI);

Так как-то?

>>1257020
Я купил. Каждый вечер читаю по главе и наполняюсь Его мудростью.
Объекты становятся все элегантнее и элегантнее.

>>1257020
>"Do not waste your money on the book; It will teach you nothing—or worse, it may teach you to hold on to absurd, opinionated, borderline superstitious programming habits."—Mario V.

>"I bought your first book and read it for 10 mins. Then realized it was a copy paste from your website and threw it to the trash can. I regret it tho, because I now own a dog and sometimes I need paper for him to shit on."—Phantom190

Нах она тебе нужна?

>>1257043
Неосиляторы ООП бугуртят

>>1257043
>Do not waste your money on the book
Ай донт интенд ту

>Нах она тебе нужна?
Я хочу понять что говорит автор. Я не особо согласен, но он явно опытнее чем я. Любопытно. Применять я в жизни это не буду.

>>1257075
>Применять я в жизни это не буду.
Ты не хочешь писать хороший код? Странно.

>>1257080
Я чё, CTO своей компании? Мне как скажут, так я и пишу

>>1257043
>этот бугурт неосиляторов

>>1257032
А зачем в строках все делать? Это уже математический дсл у тебя получается. Достаточно сделать класс Cos и т.д., плюс вместо методов solve и definiteSolution у тебя должен быть один интерфейс Solution и два реализующих его класса.

>>1256878
Погугли "сериализация" что ли.

>>1257075
Почитай его блог для начала. Там неструктурированно, но чтоб окунуться хватит.

>Применять я в жизни это не буду.
Зачем тогда читать? Опыт\знания надо применять.

>>1257085
Впрочем, справедливо.

>>1257222
>Погугли "сериализация" что ли
Тут не сработает.

>>1257276
>как мне сделать сериализацию?
>Погугли "сериализация"
>Тут не сработает.

>>1257335
При чем тут сериализация, наркоман? Во-первых, компоненты в файле никак не помечены, сразу необходимая информация идет. Во-вторых, счеть с файла данные и "воссоздать" объект или наоборот записать никаких проблем нет.

>>1257346
>компоненты в файле никак не помечены
Не может быть.

>>1257405
В начале записи есть только 8 байт которые определяют длину, тип записи и присущую ему последовательность компонентов. Дальше уже один компонент съедает 8 байт, следующий 4 + число в этих четырех байтах и тд.

>>1257415
>компоненты в файле никак не помечены
>тип записи и присущую ему последовательность компонентов
Всё помечено же.

>>1257806
Глазами читай, пожалуйста.

>>1258018
Нет ты. Заодно погугли "сериализация".

>>1258050
>Во-вторых, счеть с файла данные и "воссоздать" объект или наоборот записать никаких проблем нет

>>1258018
Если бы не было помечено, хрен бы ты что смог разобрать.

>>1258195
Сами-то компоненты не помечены - мы про них речь вели.

>>1258216
Они помечены в
>последовательность компонентов

>>1258222
>В начале записи есть только 8 байт которые определяют длину, тип записи и присущую ему последовательность компонентов
4 байт - длина записи
4 байт - тип записи
Все. Если бы САМИ КОМПОНЕНТЫ были помечены, то перед данными каждого из них шли метаданные с типом самого компонента.

При чем тут вообще сериализация, если я о другом спрашивал?

>>1258227
>то перед данными каждого из них шли метаданные с типом самого компонента.
Это только один из способов пометить данные. В твоем примере использован другой.

>>1258349
> При чем тут вообще сериализация, если я о другом спрашивал?

>>1258357
А о чем ты по-твоему спрашивал?

>>1258375
Я спрашивал о том, как добраться до данных уже воссозданного объекта. Некрасивый метод: get/setName(), get/setHash(), get/setLinked, etc. Вдобавок я привел свой метод, который, как по мне, уже чуть лучше, но все еще не то.

https://soundcloud.com/frontend-weekend/fw-68

свежак с Егором

>>1258430
>платил за работу программисту на родине 300 долларов
>продавал ту же работу на американском рынке за 2000 долларов
Какой же он мерзкий.

>>1258508
Чем он мерзкий? Тем, что честный?
Любая аустсорсинговая компания так делает. Особенно украинская.

Ну а что? Ему за помещение платить, за оборудование, брать на себя бизнес-риски и тд. Это капитализм, детка. Лучший мир мы в 1991 отвергли.

>>1258395
>как добраться до данных уже воссозданного объекта
До данных никак не надо добираться. Объект не должен позволять манипулировать его данными.

Иначе у тебя не объекты, а хранилища данных. Тогда не нужны методы вообще, все свойства - public, но это не ООП.

>>1258555
Коммипидор незаметен.

>>1258637
А если это, внезапно, КЭШИРОВАННЫЕ ДАННЫЕ, суть объекта которых предоставлять запрошенные однажды данные? Это во-первых. А во-вторых, данные - read only.

Хорошо, как по ООП узнать имя записи на диске, если оно есть? Известно начало записи, ты можешь прочитать первые четыре байта, чтобы узнать порядок компонентов. Что дальше?

>>1259235
>Хорошо, как по ООП узнать имя записи на диске, если оно есть? Известно начало записи, ты можешь прочитать первые четыре байта, чтобы узнать порядок компонентов. Что дальше?
Запиливаешь класс, абстрагирующий файл от всего остального кода. Он должен десериализовывать записи из файла в объекты соответствующего класса. А эти объекты должны иметь какой-нибудь интерфейс, типа printable, hasName, ну или что-то похожее, в зависимости от постановки задачи.

>>1259405
>А эти объекты должны иметь какой-нибудь интерфейс, типа printable, hasName, ну или что-то похожее, в зависимости от постановки задачи
Не вариант. Во-первых, это добавляет кучу полей в класс. Во-вторых, это добавляет кучу "пустых" реализаций методов интерфейса. Все это ослабляет связность. В-третьих, меняется один из компонентов или добавляется новый - и все классы, а может даже и интерфейс, придется изменять.
Я уже делал класс под каждую запись в псевдо-ОО версии, но там без кастов не обошлось.

>>1259422
>Во-первых, это добавляет кучу полей в класс.
Схуяли?

>Во-вторых, это добавляет кучу "пустых" реализаций методов интерфейса
Не делаешь implements для класса - нет и пустых методов.

>В-третьих, меняется один из компонентов или добавляется новый - и все классы, а может даже и интерфейс, придется изменять.
Значит что-то не так с декомпозицией, или с постановкой задачи.

>>1259485
Напиши небольшие примеры кода.

>>1259917

interface Named {
public Printer showName(Printer printer);
}

class Record1 {
.....нет никаких пустых реализаций.....
}


class Record2 implements Named {
private String name;
........

public Printer showName(Printer printer) {
return printer.print(name);
}
}

>>1260133
Дело в том, что я не знаю, какая конкретно это будет запись.
IRecord record = file.record(offset);

>>1260143
>>1260133
Хотя можно попробовать что-нибудь типа такого, если без кастов.
RecordType rType = file.recordType(offset);
for(Map.Entry<RecordType, IRecordProcessor> entry : recordTypeRegistry.entrySet()) {
if(rType.equals(entry.getKey())) {
entry.getValue().processRecord(file, offset);
}
}

>>1260143
Может все-таки погуглишь "сериализация"?

>>1260157
Объяснишь при чем тут сериализация?

>>1260153
>если без кастов.
Без кастов никак, если заранее неизвестен тип записи.

>>1260163
Ну а ты чем занимаешься?

>>1260578
Десереализацией, очевидно.

>>1260578
Тем, что пытаюсь обработать объекты которые имеют много общего, но и различия не только в стейте. Ты можешь опустить уровень собирания из байтов и представить, что у тебя уже есть объекты.
Все сводится к тому, что я перебираю объекты, но не могу знать больше положенного, что могу с ним сделать. Каждый объект как коробка с двумя кнопками и наклейкой - я могу прочитать наклейку и узнать, что внутри, но не могу с этим содержимым ничего сделать, пока не распакаю коробку - кастану.

>>1260788
>но не могу с этим содержимым ничего сделать, пока не распакаю коробку - кастану
Пусть объект сам делает это что-то, очевидно же.

>>1260973
Объект сам не знает, что конкретно внутри. Да и это не его задача.

>>1261167
Объект не знает что у него внутри? Охуительные истории рассказываешь.

>>1261169
Массив объектов с общим интерфейсом. Чтобы сделать это "что-то" нужно взять какой-то один объект из массива. Чтобы сделать что-то другое, понадобятся два других объекта.
Почтовый ящик, в котором лежат письмо и почтовое извещение сам должен тебе вскрыть и прочитать письмо, а потом еще и на почту сходить посылку забрать?

>>1261194
>Почтовый ящик, в котором лежат письмо и почтовое извещение сам должен тебе вскрыть и прочитать письмо, а потом еще и на почту сходить посылку забрать?
Нет, должен быть дворецкий, который достает корреспонденцию и раскладывает её на стопочки - газеты, письма, извещения итд.

>>1261873
Сегрегация тоже не выход: появляется что-то новое и приходится новую стопочку сочинять (сильное зацепление). К тому же эти стопочки придется с собой таскать, чтобы доступ был. Может оказаться, что некоторые из стопочек пусты 99% времени и тянутся мертвым грузом (слабая связность).

>>1261886
>появляется что-то новое

Это что-то новое - совсем что-то принципиально фром скретчи полностью на 100% бля буду новое и не попадает ни под одну из имеющихся классификаций? Да неужели?

>>1261886
>появляется что-то новое и приходится новую стопочку сочинять
Зачем, когда есть полиморфные контейнеры?

>К тому же эти стопочки придется с собой таскать, чтобы доступ был.
Зачем их таскать? На моменте сортировки уже произошло, если говорить языком структурного программирования, "ветвление вычислений" и за работу с этой стопкой отвечает другой кусок программы.

Стопка пуста - соответствующий код не выполняется, и нет никакого мертвого груза.

>>1261917
Представь кухню, где нет посудомойки и кофемашины, но они однажды могут там появиться, как и десятки других вещей.

>>1261931
Затем, что у содержимого разное поведение.

Если я правильно понял, то вот поведение дворецкого:
if(mailItem.isLetter()) {
letters.add(mailItem);
} else if(mailItem.isPaper()) {
papers.add(mailItem);
}

Доступ к стопкам:
public List<Letter> letters() {
return letters;
}

public List<Paper> papers() {
return papers;
}

Не ОО, но примерно так.

>чувак уже неделю не может разобраться, как ему десериализовать объект из файла

Какие же оопущенцы дегенераты, пиздец просто.

Бамп Егоркиной мудростью https://www.yegor256.com/2018/09/18/fear-of-coupling.html

>>1173405 (OP)
>4 пик
Венсана Касселя покусали пчелы?