Здравствуйте. 
Есть информация в приложении которая определяется один раз и нужен доступ к ней из любого класса приложения
Допустим информация о подключении к базе дынных или информация об авторизированном пользователе.
Хотел бы узнать мнение профи.  Кто и как хранит и получает данную информацию. Какие паттерны применяет.

Ну это называется не паттерн, хотя вопрос понятен...

Я лично использую или файлы пропертис или SQL таблички или XML. Все зависит от типа информации. Если данных немного то файлы пропертис - самое оно. Если много, тут без SQL никак не обойтись. Если нормального SQL под рукой нет - то беру Hypersonic SQL (встроенный в JDK Derby DB не люблю).
Если структура данных сложная и требуется обеспечить чтение и для другой программы/платформы - лучше двигать в сторону XML.

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

Все таки, я наверно немного некорректно вопрос задал ... 

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

Я так понял, вам нужен паттерн Singleton
В системе будет существовать только один обьект этого класса, инициализироваться он тоже будет только один раз, и из любого места программы вы сможете получить ссылку на этот обьект через статический метод getInstance() и вызывать нужные вам методы этого класса.

Например, если пользователь вводит логин-пароль, то их удобно хранить в статических переменных (Singleton). Или ( только для строковых данных ) можно положить в системные свойства  ( System.setProperty(..)  , System.getProperty(..)    ). Тоже доступно везде в приложении. 

Однако если приложение имеет параметры в файле, то их, параметры, в некоторых случаях лучше каждый раз извлекать из файла, а не хранить в переменной. Например, есть параметры соединения - адрес и порт. Тогда можно пересоединить приложение не останавливая (актуально для серверных приложений) его. Просто редактируется проперти файл и дается команда reconnect. 

Скорее я неправильно понял 

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

Есть еще другой способ, правда я от него потом отказался. В каждой аппликации все свои классы наследовать от одного класса (можно и абстрактного) и в теле этого класса держать все свои глобальные переменные - тогда автоматом в каждом классе будут доступны все глобальные данные. Удобно, но как то показалось хлопотно.

Видел в сети и другие реализации - типа Dymanic Scoping, Single Factory и проч. но не применял.  

А чем он так плох? ума не приложу. Отличный паттерн ИМХО. Это конечно не значит, что любую задачу нужно под него подгонять. Но тем не менее, я лично не вижу недостатков.

Да, singleton, похоже мне подойдет.

Спасибо за помощь    

А хотя бы тем, что это потенциальная брешь и в сложных системах которые работают через рефлексию вполне возможно инстанциировать несколько экземпляров одного и того же Singleton класса. Есть также проблемы и при сериализации/десериализации.

такая брешь имхо называется: сам дурак

Эта брешь - в конкретной реализации синглетона.
А есть брешь в самой идее синглетона, если синглетон не константный объект, а приложение многопоточное.
В случае если нужно хранить константные данные, вместо синглетона в Java можно использовать интерфейс (недостаток - проблемы с переводом на другие языки программирования):

И что тогда рекомендуется использовать в многопоточных приложениях вместо sbgleton ???

Ну если сильно захотеть, то можно и *** сломать =)

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

А какие проблемы с многопоточностью? Вроде синхронизацию никто не отменял?

Всё зависит от того, для чего нужен синглетон.
Допустим, сначала был один сервер и его параметры хранились в синглетоне.
Эти параметры - константы, по крайней мере, в пределах одного запуска программы.
Но потом появляется второй сервер, который используется, когда связь с основным теряется. Придётся всю программу переделывать.
Например, если есть две нити, одна работает с основным сервером, а другая с запасным, параметры сервера можно хранить в ThreadLocal.