Как костыль, конечно, годно, но лучше, конечно, все эти приседания отправить PR-ом в соответствующий плагин, чтобы это работало из коробки, а не вот эта вот мешанина из xml-я и java-кода.
За использование в контроллере репозиториев и базюшных сущностей нужно бить по рукам железной линейкой. Работа со слоем данных должна быть только в сераисах.
Если вышло обновление - заниматься ретестами каждый раз?
А при чём тут опенсорс? Ретест для mission critical штук нужен при любом изменении, нет?
Если обнаружен баг - отправлять разработчику багрепорт и ждать от него что он все бросит и кинется его исправлять?
Это как раз ситуация с вендорским решением. Если код открыт, то у тебя -всегда- как правило есть возможность залезть в исходники, поправить и даже отправить фикс в апстрим.
очень часто никакого отношения к enumeration не имеет
Именно поэтому enum приватный и напрямую наружу не торчит, потому что его использование обусловлено лишь гарантией единственности экземпляра со стороны самой jvm. Например в гугловой гуаве до появления лямбд через подобный механизм реализованы некоторые функции (Functions.toStringFunction(), Functions.identity(), ...)
GoF его преподносит
Ничего GoF не преподносит. Вообще эта книжка про шаблоны проектирования, и там приведены лишь возможные реализации этих самых шаблонов конкретно на языке java. Нигде в ней не говорится, что это единственно верный вариант.
То, что эти примеры начали бездумно копировать, полагаясь на авторитет авторов, говорит лишь о том, что люди по своей сути ленивы и, если можно не думать, предпочитают именно так и поступать.
как Effective Java рекомендует делать синглетоны
Но это единственно рабочий "изкоробочный" способ сделать синглтон без использования сторонних библиотек/фреймворков с минимальными усилиями.
Очищать должен тот, кто нагадил. Т.о. очистка состояния должна выполняться после теста. А вот перед тестом перед предустановкой состояния для теста стоит добавить проверку, что состояние пустое.
Более того использовать Enum для синглетона - это рекомендация из книги Effective Java (имхо анти-рекомендация).
Основная беда enum-ов в качестве синглтонов - это неленивость и протекание ненужных сервису enum-методов. И первое, и второе решается тем, что enum должен быть приватным классом в синглтон-сервисе, а методы сервиса делегируют вызовы единственной константе в этом enum-е.
Spring начал становиться довольно популярным
И теперь его, не думая, пихают везде где нужно и где не нужно.
Singleton стал анти-паттерном
И именно поэтому его использует вышеупомянутый Spring? Синглтон - это просто объект-одиночка в рамках, как правило, приложения. Вне зависимости от механизма реализации данного поведения, будь-то spring, CDI, micronaut, etc.
Код из листинга 1 по функционалу эквивалентен следующему коду
Вообще нет. Так как код для NIO не сможет прочесть файл размером больше, чем выделенный буфер, а блокирующее чтение ограничено лишь максимально возможным размером для массива.
Ну, и строка для NIO создаётся неправильно, и в ней может оказаться мусор.
Потому что аббревиатуры, несуществующие в языке, на который осуществляется перевод, как правило, не переводятся.
Как костыль, конечно, годно, но лучше, конечно, все эти приседания отправить PR-ом в соответствующий плагин, чтобы это работало из коробки, а не вот эта вот мешанина из
xml
-я иjava
-кода.Не надо превращать
pom
-ник вant
/gradle
-скрипт.А где раздобыть первый? Судя по второму, он должен быть эпичен.
Разработчики этой системы, видимо, хабр не читают.
А что тут такого особенного, что не описано в документации?
... дочитав все новости? ... долистав всю ленту? ... досмотрев весь ютуб?
Ну, вообще-то да. Лень им, понимаешь, на себе носить ребёнка.
За использование в контроллере репозиториев и базюшных сущностей нужно бить по рукам железной линейкой. Работа со слоем данных должна быть только в сераисах.
Начальник или программист?
Как говорится, есть 2 типа разработчиков: те, кто думает, что soft delete - это крутое решение, и другие.
А что поменяется, если это будет не опенсорс?
А при чём тут опенсорс? Ретест для mission critical штук нужен при любом изменении, нет?
Это как раз ситуация с вендорским решением. Если код открыт, то у тебя -всегда- как правило есть возможность залезть в исходники, поправить и даже отправить фикс в апстрим.
Именно поэтому enum приватный и напрямую наружу не торчит, потому что его использование обусловлено лишь гарантией единственности экземпляра со стороны самой jvm.
Например в гугловой гуаве до появления лямбд через подобный механизм реализованы некоторые функции (
Functions.toStringFunction()
,Functions.identity()
, ...)Ничего GoF не преподносит. Вообще эта книжка про шаблоны проектирования, и там приведены лишь возможные реализации этих самых шаблонов конкретно на языке java. Нигде в ней не говорится, что это единственно верный вариант.
То, что эти примеры начали бездумно копировать, полагаясь на авторитет авторов, говорит лишь о том, что люди по своей сути ленивы и, если можно не думать, предпочитают именно так и поступать.
Но это единственно рабочий "изкоробочный" способ сделать синглтон без использования сторонних библиотек/фреймворков с минимальными усилиями.
Очищать должен тот, кто нагадил. Т.о. очистка состояния должна выполняться после теста. А вот перед тестом перед предустановкой состояния для теста стоит добавить проверку, что состояние пустое.
Это да, но оно не везде есть именно в таком виде. А вот без логеров продакшн-кода я не видел уже давно.
Основная беда enum-ов в качестве синглтонов - это неленивость и протекание ненужных сервису enum-методов. И первое, и второе решается тем, что enum должен быть приватным классом в синглтон-сервисе, а методы сервиса делегируют вызовы единственной константе в этом enum-е.
И теперь его, не думая, пихают везде где нужно и где не нужно.
И именно поэтому его использует вышеупомянутый Spring? Синглтон - это просто объект-одиночка в рамках, как правило, приложения. Вне зависимости от механизма реализации данного поведения, будь-то spring, CDI, micronaut, etc.
LoggerFactory.getLogger(MyService.class)
из большинства активно используемых логеров передаёт привет.Что за бредятина? Зачем нужен
getInstance()
, ежели и так имеется доступ к экземпляру?Но в суд нужно будет предоставить бумажную копию документа с распечатанной же электронной подписью.
А ещё BOM добавлял при сохранении Unicode.
Вообще нет. Так как код для NIO не сможет прочесть файл размером больше, чем выделенный буфер, а блокирующее чтение ограничено лишь максимально возможным размером для массива.
Ну, и строка для NIO создаётся неправильно, и в ней может оказаться мусор.