За использование в контроллере репозиториев и базюшных сущностей нужно бить по рукам железной линейкой. Работа со слоем данных должна быть только в сераисах.
Если вышло обновление - заниматься ретестами каждый раз?
А при чём тут опенсорс? Ретест для 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 создаётся неправильно, и в ней может оказаться мусор.
встречу 1 на 1 с руководителем на 30 минут каждые две недели
Что может измениться за 2 недели? Для какой надобности мне встречаться с руководителем 1 на 1 каждые недели, чтобы что? А со стороны руководителя так вообще ж трешак: если в команде 10 человек, то это ж каждый день будут эти встречи.
Именно поэтому, чтобы такого не произошло, там стоит синхронизация на классе. После входа этот блок, все параллельные потоки не смогут получить доступ к полю instance, до завершения этого блока.
А что тут такого особенного, что не описано в документации?
... дочитав все новости? ... долистав всю ленту? ... досмотрев весь ютуб?
Ну, вообще-то да. Лень им, понимаешь, на себе носить ребёнка.
За использование в контроллере репозиториев и базюшных сущностей нужно бить по рукам железной линейкой. Работа со слоем данных должна быть только в сераисах.
Начальник или программист?
Как говорится, есть 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 создаётся неправильно, и в ней может оказаться мусор.
Хотя буквально парой абзацев выше:
Что может измениться за 2 недели? Для какой надобности мне встречаться с руководителем 1 на 1 каждые недели, чтобы что? А со стороны руководителя так вообще ж трешак: если в команде 10 человек, то это ж каждый день будут эти встречи.
Именно поэтому, чтобы такого не произошло, там стоит синхронизация на классе. После входа этот блок, все параллельные потоки не смогут получить доступ к полю
instance, до завершения этого блока.Лучшим для кого? Для америанцев? А что об этом думала британская корона?
Опосля гугло/яндекс/etc.-транслэйта текст кто-то вообще читал?
А чего вдруг? Почему не "услуга конвертации валют"?