Наверное, чтобы что-нибудь компилировать это хороший вариант. Может быть для того, чтобы разрабатывать, используя IDE как тонкий клиент. Я собираюсь попробовать, кстати, должно быть интересно, пугает только необходимость быть постоянно подключенным к интернету.
А в играх думаю огромное количество ядер не помогает. Память, конечно, хорошо, но 256 ГБ можно и в десктопный Ryzen вставить.
Мне кажется это нарушит принцип рефлексивности: для любой ненулевой ссылки на значение х выражение х.equals(х) должно возвращать true.
Поэтому в первой строке надо возвращать true, если в метод equals пришёл тот самый, у которого вызывается метод.
Так делать лучше не стоит, т.к. при возврате константы вся производительность хеш-таблиц сведеться к массиву.
Не к массиву, а к связному списку. В лучшем случае к дереву. Но в случае с энтити это не важно, потому что использовать энтити в качестве ключей в HashMap категорически не рекомендуется. В том числе по озвученой вами причине. Есть ещё случай, когда у энтити есть коллекция дочерних элементов и тип коллекции — Set. Но в такой коллекции не должно быть много элементов. Если этих элементов много — оформлять такую связь через JPA категорически не рекомендуется, потому что нельзя контролировать получение этих элементов из базы данных. Лучше просто сделать ссылку на родительскую сущность в дочерних сущностях, а OneToMany не писать.
Может вы путаете с числом, на которое нужно умножать(сдвигать) полученный результат при вычисление хеш-кода? по книге Джошуа Блоха, это как раз число 31.
Не путаю. Но 31 возвращать и правда не обязательно, можно вернуть и 42 )). Главное, чтобы все этити упали в один бакет.
по поводу lombok и jpa можно почитать эту статью.
Обратите внимание, к статье много моих комментариев по тому же поводу, что и здесь ))
Если планируется использовать jpa entity в мапах, сетах и сравнивать, лучше самостоятельно переопределить методы equals и hashCode.
Вы может и не планируете. А другой разработчик планирует и вас не спросит, потому что вы будете работать с кодом в разное время. И вполне вероятно, что он не знает, что надо сравнивать энтити только по id, возвращать false, если id == null и что hashCode() должен вернуть 31. И словит баги, которые воспроизводятся не очень часто, но очень метко. Он об этих багах наверное даже и не узнает и хорошо, если их поймают не в продакшне.
Особенно неприятно, если equals переопределили для тестов. Тогда даже если разработчик в курсе, что надо что-то делать с equals, он может на это забить. Потому что править все тесты с энтити ему может показаться скучным и неинтересным.
Поэтому для сравнения энтити в тестах лучше использовать методы типа reflectionEquals из AssertJ
P. S. Всё это, конечно, актуально только когда у энтити нет естественного ключа. Если он есть, то нужно использовать его
Если вы джава разработчик, то куда бы ты не пришёл, там с высокой вероятностью будет JPA. Поэтому тем, кто не владеет JPA придётся отклонить бОльшую часть предложений о работе. Если это не проблема, то можно JPA не изучать.
Если бы php внутри компаний, занимающихся разработкой, был бы так же распространён, как JPA среди джава проектов, то для того, чтобы работать программистом, php был бы ключевым навыком.
Я примерно в это же время точно так же выбрал ноутбук. В целом мобильность это очень важно, особенно, когда дома фактически и нет ))). Но по производительности i7 на ноуте это как i7 с десктопа предыдущего поколения или вообще на два поколения отстаёт
Я вот думаю взять Ryzen со встроеной видеокартой, огромным кулером и двумя медленными вентиляторами. Тихо будет. ААА игры работать наверное не станут, ну и ладно. Все о чём я мечтал 10 лет назад не сомневаюсь заработает без проблем )) .
во-первых большинство диаев плохо такие сценарии поддерживает
Я джавой занимаюсь в основном, тут вроде нормально всё. У нас, правда, DI де факто один — Spring, но в других наверное проблем не будет.
во-вторых это как раз размазывание логики которая довольно критична
В моём случае будет класс, в котором два метода. Один вызывает init, другой вызывает deinit. Мне кажется по сравнению с синглтоном логика размыта не будет.
Вопрос — как бы вы дизайнили такую штуку. Запихнули бы всю логику прямо в код регистрации DI вместо инкапсуляции такого поведения в отдельном типе?
Ну да. Ознакомился бы с документацией к IoC контейнеру, нашёл бы как зарегистрировать коллбеки для которые выполняются при запуске и остановке и туда бы вписал init и deinit.
потому что на моей работке где это было как раз делали синглтон
В мире Linux — «все есть в репозиториях» — поставил из репозитория — устаревшая, кривая и не рабочая версия.
Устаревшая — это вполне вероятно. А вот чтобы кривая и нерабочая — такое редко бывает.
Скачиваешь пакет, ой, у меня же не deb/rpm/pac
А что у вас?
Собираю из исходников несколько дней.
Надо ещё проверить на предмет наличия экзешника. Например Shotcut (редактор видео такой) можно скачать в виде standalone приложения, скопировать в какую-нибудь директорию и просто запустить.
Кстати чем синглтон не угодил не очень понятно — то что теперь они рулятся через AddSingleton() фунцию в DI фреймворке ничего по сути не меняет.
Я бы сказал, что меняет вообще всё. Паттерн синглтон не столько о том, что должен быть один объект какого-то класса, сколько о том, как написать код так, чтобы второй объект было нельзя сделать.
Синглтоны в контейнере такого не навязывают. Я думаю, если бы контейнера не было, а была бы просто сборка всего контекста вручную, где объект создаётся через new один раз, а потом всем передаётся в конструктор в качестве аргумента, никто и не подумал бы называть это синглтоном.
Ну, инструмент в виде редактора у вас уже есть, плагины к нему тоже есть. Единственное что нужно сделать это прикруть вызов pandoc к какому-нибудь хоткею. Вам и с этим не хочется возиться?
Можно мне либо нормально спроектированный язык разметки, либо нормально реализованный визивиг?
Можно. Выбирайте любой язык разметки, который вам нравится, потом в своём любимом редакторе делайте таблицу. Наверняка там уже есть куча плагинов, которая делает этот процесс удобным. А потом с помощью pandoc конвертируйте в markdown. Или сразу в хабровскую версию html.
Plaintext ввод с markdown был бы куда более эргономичен.
Прочитал ваш комментарий, увидел вот это "был бы" и не понял. Ведь markdown на хабре всегда был. Проверил. И вроде он ещё есть, но его совершенно серьёзно собираются убрать навсегда. И совершенно серьёзно хотят чтобы технические специалисты писали тексты в этом самом WYSIWYG редакторе.
Я честно говоря не понимаю как так вышло. Может быть редакторам так удобнее. Не знаю.
Опять же для id это может быть не всегда верно, т.к. при создание entity поле не будет заполнено
Да, поэтому если id равен null equals должен возвращать false. Независимо от того, чему равен id другой энтити. А чтобы можно было найти сущность после появления id, нужно из hashCode всегда возвращать 31
Слов с сочетанием ЙЕ предостаточно: вуайерист, Йемен, конвейер, фейерверк и т.д.
Ну да. Иногда даже возникает ощущение, что Й тут действительно звучит. Но положа руку на сердце, я не уверен, что замечу какую-то разницу, если в этих словах Й убрать.
Слов с сочетанием ЙЭ сейчас нет ни одного.
Неудивительно, ведь для этого есть буква Е )))
У вас не возникает соблазна писать Емен и конвеер, раз уж звук Й в этих Е уже находится?
Соблазна не возникает потому, что я знаю, как пишутся эти слова. Но если бы я не знал, то наверное у меня не возникло бы желания поставить туда Й
Ну или взять Ъ. В современном русском он обозначает /й/. Почему слово /сйем/ не писать как сйем?
Мне кажется в вашем примере Ъ обозначает, что не нужно сливать согласную со следующей гласной. А звука там вообще никакого нет. Звук Й находится в букве Е. Можно было бы наверное писать сйэм.
Это будет иметь смысл если только они не будут замедлять выполнение. Обработка исключений — это дорого
Тут стоит упомянуть, что исключения это инструмент, предназначенный для использования там, где исключительные ситуации возникают редко и обрабатывать их в основном не придётся. На то они и исключительные.
весь этот метод [… ] в 50% случаев будет вылетать в oops [… ] — если он вызывается сотни миллионов раз то исключения напрочь убьют производительность.
Если в 50% случаев метод выбрасывает эксепшн, то лучше не использовать эксепшны в этом методе. В этом случае явно у нас нет исключительной ситуации, а есть один из ожидаемых исходов. Эксепшны, по крайней мере в Джаве, практически бесплатны, если возникают редко, но, как вы справедливо заметили, очень дороги, если их приходится часто обрабатывать.
Гугль хорошо описал большинство "за" и "против" и в итоге отказался от них даже в C++
По ссылке, которую вы дали в явном виде озвучен вывод гугла — в случае эксепшнов "за" перевешивают "против", то есть эксепшны это скорее хорошо, чем плохо. Гугл отказался от них из-за большого количества легаси кода.
"тащить и не пущать" — это плохая практика, это всё равно что отказаться от утюгов и стиральных машин дома и заставить людей отдавать стирать и гладить вещи в спецсервисы, а то пожары случаются
Кстати, если бы пожары и затопления случались часто — давно бы уже запретили держать дома что утюги, что стиральные машины ))
Не поймите меня неправильно, я не за повсеместное использование goto.
Да мне кажется мы друг друга отлично поняли ))
Я за то, чтобы включать голову, и писать понятный код.
А я ещё за то, чтобы делать как сделано в джаве. То есть выделить полезные применения и сделать отдельными фичами, убрав заведомо вредные варинаты использования.
В случае с С++, я бы наверное стал искать какой-нибудь линтер, который разрешает делать только хорошо. Если конечно в случае с С++ его получится написать, тут я плохо разбираюсь.
Тем не менее, я считаю, что в этих нескольких случаях применение было оправданным с точки зрения написания читаемого кода.
Не сомневаюсь. На самом деле очень любопытно, что это за случаи. То есть можно ли среди них найти какой-то новый тип использования goto, помимо известных мне.
Действительно. Похоже про 128 мегабайт на Ryzen это я просто очень хотел, чтобы так можно было сделать ))
Наверное, чтобы что-нибудь компилировать это хороший вариант. Может быть для того, чтобы разрабатывать, используя IDE как тонкий клиент. Я собираюсь попробовать, кстати, должно быть интересно, пугает только необходимость быть постоянно подключенным к интернету.
А в играх думаю огромное количество ядер не помогает. Память, конечно, хорошо, но 256 ГБ можно и в десктопный Ryzen вставить.
Поэтому в первой строке надо возвращать true, если в метод equals пришёл тот самый, у которого вызывается метод.
Не к массиву, а к связному списку. В лучшем случае к дереву. Но в случае с энтити это не важно, потому что использовать энтити в качестве ключей в HashMap категорически не рекомендуется. В том числе по озвученой вами причине. Есть ещё случай, когда у энтити есть коллекция дочерних элементов и тип коллекции — Set. Но в такой коллекции не должно быть много элементов. Если этих элементов много — оформлять такую связь через JPA категорически не рекомендуется, потому что нельзя контролировать получение этих элементов из базы данных. Лучше просто сделать ссылку на родительскую сущность в дочерних сущностях, а OneToMany не писать.
Не путаю. Но 31 возвращать и правда не обязательно, можно вернуть и 42 )). Главное, чтобы все этити упали в один бакет.
Обратите внимание, к статье много моих комментариев по тому же поводу, что и здесь ))
Вы может и не планируете. А другой разработчик планирует и вас не спросит, потому что вы будете работать с кодом в разное время. И вполне вероятно, что он не знает, что надо сравнивать энтити только по id, возвращать false, если id == null и что hashCode() должен вернуть 31. И словит баги, которые воспроизводятся не очень часто, но очень метко. Он об этих багах наверное даже и не узнает и хорошо, если их поймают не в продакшне.
Особенно неприятно, если equals переопределили для тестов. Тогда даже если разработчик в курсе, что надо что-то делать с equals, он может на это забить. Потому что править все тесты с энтити ему может показаться скучным и неинтересным.
Поэтому для сравнения энтити в тестах лучше использовать методы типа reflectionEquals из AssertJ
P. S. Всё это, конечно, актуально только когда у энтити нет естественного ключа. Если он есть, то нужно использовать его
Если вы джава разработчик, то куда бы ты не пришёл, там с высокой вероятностью будет JPA. Поэтому тем, кто не владеет JPA придётся отклонить бОльшую часть предложений о работе. Если это не проблема, то можно JPA не изучать.
Если бы php внутри компаний, занимающихся разработкой, был бы так же распространён, как JPA среди джава проектов, то для того, чтобы работать программистом, php был бы ключевым навыком.
Я примерно в это же время точно так же выбрал ноутбук. В целом мобильность это очень важно, особенно, когда дома фактически и нет ))). Но по производительности i7 на ноуте это как i7 с десктопа предыдущего поколения или вообще на два поколения отстаёт
Я вот думаю взять Ryzen со встроеной видеокартой, огромным кулером и двумя медленными вентиляторами. Тихо будет. ААА игры работать наверное не станут, ну и ладно. Все о чём я мечтал 10 лет назад не сомневаюсь заработает без проблем )) .
Да, в продукты, лицензированные этими самыми
плохими, негоднымикопилефтными лицензиями )))Я джавой занимаюсь в основном, тут вроде нормально всё. У нас, правда, DI де факто один — Spring, но в других наверное проблем не будет.
В моём случае будет класс, в котором два метода. Один вызывает init, другой вызывает deinit. Мне кажется по сравнению с синглтоном логика размыта не будет.
Ну да. Ознакомился бы с документацией к IoC контейнеру, нашёл бы как зарегистрировать коллбеки для которые выполняются при запуске и остановке и туда бы вписал init и deinit.
А где deinit вызывали?
Устаревшая — это вполне вероятно. А вот чтобы кривая и нерабочая — такое редко бывает.
А что у вас?
Надо ещё проверить на предмет наличия экзешника. Например Shotcut (редактор видео такой) можно скачать в виде standalone приложения, скопировать в какую-нибудь директорию и просто запустить.
Я бы сказал, что меняет вообще всё. Паттерн синглтон не столько о том, что должен быть один объект какого-то класса, сколько о том, как написать код так, чтобы второй объект было нельзя сделать.
Синглтоны в контейнере такого не навязывают. Я думаю, если бы контейнера не было, а была бы просто сборка всего контекста вручную, где объект создаётся через new один раз, а потом всем передаётся в конструктор в качестве аргумента, никто и не подумал бы называть это синглтоном.
Ну, инструмент в виде редактора у вас уже есть, плагины к нему тоже есть. Единственное что нужно сделать это прикруть вызов pandoc к какому-нибудь хоткею. Вам и с этим не хочется возиться?
Я вас не совсем понимаю. Вам хотелось бы, чтобы для вас всё это кто-то построил?
Можно. Выбирайте любой язык разметки, который вам нравится, потом в своём любимом редакторе делайте таблицу. Наверняка там уже есть куча плагинов, которая делает этот процесс удобным. А потом с помощью pandoc конвертируйте в markdown. Или сразу в хабровскую версию html.
Прочитал ваш комментарий, увидел вот это "был бы" и не понял. Ведь markdown на хабре всегда был. Проверил. И вроде он ещё есть, но его совершенно серьёзно собираются убрать навсегда. И совершенно серьёзно хотят чтобы технические специалисты писали тексты в этом самом WYSIWYG редакторе.
Я честно говоря не понимаю как так вышло. Может быть редакторам так удобнее. Не знаю.
Да, поэтому если id равен null equals должен возвращать false. Независимо от того, чему равен id другой энтити. А чтобы можно было найти сущность после появления id, нужно из hashCode всегда возвращать 31
Ну да. Иногда даже возникает ощущение, что Й тут действительно звучит. Но положа руку на сердце, я не уверен, что замечу какую-то разницу, если в этих словах Й убрать.
Неудивительно, ведь для этого есть буква Е )))
Соблазна не возникает потому, что я знаю, как пишутся эти слова. Но если бы я не знал, то наверное у меня не возникло бы желания поставить туда Й
Мне кажется в вашем примере Ъ обозначает, что не нужно сливать согласную со следующей гласной. А звука там вообще никакого нет. Звук Й находится в букве Е. Можно было бы наверное писать сйэм.
Тут стоит упомянуть, что исключения это инструмент, предназначенный для использования там, где исключительные ситуации возникают редко и обрабатывать их в основном не придётся. На то они и исключительные.
Если в 50% случаев метод выбрасывает эксепшн, то лучше не использовать эксепшны в этом методе. В этом случае явно у нас нет исключительной ситуации, а есть один из ожидаемых исходов. Эксепшны, по крайней мере в Джаве, практически бесплатны, если возникают редко, но, как вы справедливо заметили, очень дороги, если их приходится часто обрабатывать.
По ссылке, которую вы дали в явном виде озвучен вывод гугла — в случае эксепшнов "за" перевешивают "против", то есть эксепшны это скорее хорошо, чем плохо. Гугл отказался от них из-за большого количества легаси кода.
Кстати, если бы пожары и затопления случались часто — давно бы уже запретили держать дома что утюги, что стиральные машины ))
Да мне кажется мы друг друга отлично поняли ))
А я ещё за то, чтобы делать как сделано в джаве. То есть выделить полезные применения и сделать отдельными фичами, убрав заведомо вредные варинаты использования.
В случае с С++, я бы наверное стал искать какой-нибудь линтер, который разрешает делать только хорошо. Если конечно в случае с С++ его получится написать, тут я плохо разбираюсь.
Не сомневаюсь. На самом деле очень любопытно, что это за случаи. То есть можно ли среди них найти какой-то новый тип использования goto, помимо известных мне.