есть. пиши только так и не иначе: if (...) { } else { }

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

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

я только "за" ?

мне тоже нравится эта идея)

не помню у кого это подсмотрел

там оч хороший ответ на твой вопрос

ок, посмотрю. Спасибо. Хотя мне так больше нравится: { if (isAlcoholic()) {return "Напиток алкогольный";} else {return "Напиток безалкогольный";} } аккуратнее как-то

ок, посмотрю. Спасибо. Хотя мне так больше нравится: { if (isAlcoholic()) {return "Напиток алкогольный";} else {return "Напиток безалкогольный";} } аккуратнее как-то

без фигурных скобок только если

в целом же... хз есть ли в java что-то для удобного pattern matching

Можно вопрос по коду Java? Насколько принято так писать? { if (isAlcoholic()) {return "Напиток алкогольный";} else {return "Напиток безалкогольный";} }

Можно и так return isAlcoholic() ? 'Напитак алкогольный' :'Напиток безалкогольный';

в целом же... хз есть ли в java что-то для удобного pattern matching

Scala. (:

да, так тож норм

Scala. (:

return when (isAlcoholic()) { True -> 'Алкоголь' False -> 'Не алкоголь' }

если я правильно помню как оно там в котлинах

В котлинах так.

Только ещё else могут потребовать.

без фигурных скобок только если

в целом у меня даже больше вопрос про такой стиль : if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); } для меня он очень сложно читаем, в отличие от скажем if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); } в общем то в этом и был вопрос - насколько чаще пишут как в варианте 1 чем как в варианте 2

лучше подумай как избавиться от ифов

например doSomething - что это?

это учебная задача, я только учусь. но я понял

меньше веток условий - меньше логики - меньше возможностей допустить ошибку

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

котаны, а кто SWEBOK осиливал? что думаете о предмете?

это конфа об аниме?

это конфа об аниме?

Патчим KDE2 под FreeBSD

Патчим KDE2 под FreeBSD

посоветуете что-нибудь из новинок?

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

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

кассика

в целом у меня даже больше вопрос про такой стиль : if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); } для меня он очень сложно читаем, в отличие от скажем if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); } в общем то в этом и был вопрос - насколько чаще пишут как в варианте 1 чем как в варианте 2

Общепринят первый вариант, второй совсем экзотика

не помню у кого это подсмотрел

дядя Боб за это тоже топит

вот чисто теоритический вопрос

положим у нас микросервисная архитектура (что бы больше ограничений)

и есть например микросервис каталога товаров, есть микросервис с заказами, есть микросервис с чатами (что-то типа консультации с продавцами или споры по каким-то проблемам с оными)

во всех трех надо дать возможность искать по имени продукта в каталоге

в заказах и чатах по имени покупателя

вот... есть два варианта: 1. вынести поиск в отдельный микросервис 2. поиск есть у каждого микросервиса, и для денормализации мы пишем что-то типа pub/sub который ивнты о том что например пользователь себе имя поменял прокидывает всюду

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

минус тоже есть - он начинает многова-то знать о вещах которые у нас есть... хотя может это мне как-то кажется.

зачем чату искать заказы?

зачем чату искать заказы?

ну тип бизнес идея в том что ты можешь попробовать оспорить заказ с продавцом посредствам чата (там еще можно voip будет потом)

есть прикольная фича - наорать)

а потому что бы найти нужный тебе "диспут" проще тебе надо имя продукта ввести

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

нет, ты ищешь чаты по названию продукта

ну или картинки на крайняк

чаты ищешь

а не заказы. В модуле заказа ты идешь заказы по названию продукта

ну то есть это разные модули и ищешь ты то за что отвечают модули

значит это должен быть поиск внутри сервиса чатов

окей. Это микросервисы. У каждого - своя база данных

да

ну и потом, я хочу юзать эластику для нормального поиска

например

каждому по эластике?

ну и юзай

да

если надо

ок, понял тебя

правда я не представляю, сколько чатов там должно наплодиться, чтобы эластика была оправдана

а чем объективно плоха идея одного микросервиса который занимается поиском?

тем, что от него начинают все зависеть

сложнее деплоить раздельно

правда я не представляю, сколько чатов там должно наплодиться, чтобы эластика была оправдана

эластика не только по объему данных нужна. А например для учета морфологии и более релевантной выдачи.

сложнее отдать его отдельной команде разрабов

ERROR: S client not available

тем, что от него начинают все зависеть

они не зависят от поиска. Поиск может зависеть от кучи сервисов

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

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

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

чем больше команд, тем больше шансов, что кто-то нарушит контракт

ну... почти. Он будет подписываться на изменения (аля вэбхуки) и таким образом получать инфу о том что надо что-то у себя добавить/обновить

чем больше команд, тем больше шансов, что кто-то нарушит контракт

не проблема. Есть интеграционные тесты

ну... почти. Он будет подписываться на изменения (аля вэбхуки) и таким образом получать инфу о том что надо что-то у себя добавить/обновить

предвижу сильный рост сетевого трафика

предвижу сильный рост сетевого трафика

тоже не большая проблема. Трафик будет внутренний.

и скорее всего это будут очереди сообщений

или zeromq

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

очереди это просто способ организации, трафик все равно будет

очереди это просто способ организации, трафик все равно будет

пофигу пока. Меня больше интересует с точки зрения SRP, coupling и coheasion

ну и в целом возможностей для улучшений/изменений

ну тогда надо исходить из того, что у тебя меняется вместе, а что независимо

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

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

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

не понял?

ну как часто бизнес просит поменять что-то в чатах, и как часто это влияет на поиск?

изменения логики чатов крайне редко аффектит поиск

тогда норм

пусть живет отдельно

ну а почему говорил что не стоит париться о траффике

так это потому что по сути никаких микросервисов у меня пока нет

и не планируется

но есть желание разделить и изолировать систему

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

до отдельных команд и полноценных микросервисов мы не доросли еще, но монолит нормально сделать хочется

Просто делаешь микросервис поиска

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

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