Возвращать надо не java.sql.Connection, а обертку, у которой метод close() возвращает соединение в пул. Ведь Connection у нас реализует интерфейс AutoCloseable.
Я очень быстро разобрался с такими мыслями. Код я пишу так:
1. Подумал о правах доступа? — Пишу в комментарии: «Файлы создаются с правами доступа по умолчанию. Желающие изменить права доступа на особые призываются сделать это после вызова данного метода».
2. Подумал о занятии файла другим приложением? — Пишу в комментарии: «Класс рассчитывает на то, что другие приложения не будут открывать указанный файл во время выполнения данного метода».
3. Подумал о многопоточности? — Пишу: «Внимание! Класс не thread-safe».
4. Пришла мысль об атомарных операциях? — См. пункт 3.
5. О фреймворках? — Завожу тикет в джире на будущий рефакторинг.
6. О разных файловых системах за меня подумали разработчики виртуальной машины Java.
7. О количестве файлов в директории пусть думают сисадмины.
8. О предсказуемых названиях временных файлов я уже заранее подумал, поэтому у меня есть проверенные заготовки.
9. Появились сомнения качестве моего ГСПЧ? — // TODO использовать безоспасный Random.
10. Нормальная документация? Да вот же она. Уже готова.
Данная проблема называется «увеличения скоупа работ». Это стандартный проектный риск. Существует несколько способов управления данным риском. То, что я описал, это самый универсальный метод, остальные желательно согласовывать с заказчиком.
Я не очень представляю, где тут может помочь volatile. Предположим, поле accessor я сделал volatile. Что изменится? Доступ к экземпляру целевого класса у меня осуществляется через промежуточное поле с модификатором final, а его корректное значение вроде бы гарантируется.
1. Вы полагаете, что в каком-нибудь потоке будет ссылка на не до конца проинициализированный экземпляр целевого класса?
2. Вот, что Eclipse мне пишет: Read access to enclosing field TestClass.testField is emulated by a synthetic accessor method. Change visibility of 'testField' to default. Никогда не вдавался в подробности, что это такое, апросто ставил видимость default.
Да, я уже сам пожалел, что выбрал синглтон для примера.
Вы не знаете, есть ли у данного способа устоявшееся название? Я его назвал function pointer, потому что его на C можно реализовать при помощи указателей на функции. Среди объектно-ориентированных паттернов мне почему-то ничего похожего не попадалось.
1. Подумал о правах доступа? — Пишу в комментарии: «Файлы создаются с правами доступа по умолчанию. Желающие изменить права доступа на особые призываются сделать это после вызова данного метода».
2. Подумал о занятии файла другим приложением? — Пишу в комментарии: «Класс рассчитывает на то, что другие приложения не будут открывать указанный файл во время выполнения данного метода».
3. Подумал о многопоточности? — Пишу: «Внимание! Класс не thread-safe».
4. Пришла мысль об атомарных операциях? — См. пункт 3.
5. О фреймворках? — Завожу тикет в джире на будущий рефакторинг.
6. О разных файловых системах за меня подумали разработчики виртуальной машины Java.
7. О количестве файлов в директории пусть думают сисадмины.
8. О предсказуемых названиях временных файлов я уже заранее подумал, поэтому у меня есть проверенные заготовки.
9. Появились сомнения качестве моего ГСПЧ? — // TODO использовать безоспасный Random.
10. Нормальная документация? Да вот же она. Уже готова.
Данная проблема называется «увеличения скоупа работ». Это стандартный проектный риск. Существует несколько способов управления данным риском. То, что я описал, это самый универсальный метод, остальные желательно согласовывать с заказчиком.
<habracut/>
Я, пожалуй, с вами соглашусь. Лучше сделать код понадежнее, чем потом отлавливать неочевидные эффекты многопоточности.
Не узнал.
2. Вот, что Eclipse мне пишет: Read access to enclosing field TestClass.testField is emulated by a synthetic accessor method. Change visibility of 'testField' to default. Никогда не вдавался в подробности, что это такое, апросто ставил видимость default.
3. Согласен.
Либо можно забить на то, что при определенных обстоятельствах вдруг родится не один экземпляр а целых два.
Вы не знаете, есть ли у данного способа устоявшееся название? Я его назвал function pointer, потому что его на C можно реализовать при помощи указателей на функции. Среди объектно-ориентированных паттернов мне почему-то ничего похожего не попадалось.