Есть другой вариант добиться того же самого. Делаем тип Key. И у класса из которых берем пропертю заводим метод T get(Key key). Внутри делаем каст к T и возвращаем.
Если бы дело решалось кастом, то это шаблон был бы не нужен. В методе ключа может быть инкапсулирована разнообразная логика. Например, целые числа могут быть преобразованы в строки с помощью Integer.toString, а может с помощью Integer.toHexString. Даже если перобразование типов не нужно, то может потребоваться проверять допустимость значений, вставлять умолчания, посылать нотификации и т.п - у этого шаблона очень широкий круг применения.
Спасибо, Роман! Это просто отличный пример, за что я не люблю Джава-культуру.
Вы придумали себе проблему и успешно ее решили. Вы сделали из простой вещи сложную. Вы наплодили сущностей. Вы нагородили иерархию классов и даже UML-диаграмму нарисовали!
Чтобы мои нападки не выглядели голословными (извините, если чересчур резко), прокомментирую:
> в большом модульном приложении будет использоваться много разнообразных типов
Серьезно? Число, строка, дата/время, путь до файла, ммм, регэксп? Мне кажется, что типы - они вне конфига уже.
> Есть единственное место в коде, которое определяет конкретный экземпляр каждого первоклассного ключа, что-то вроде static final IntKey MY_KEY = new IntKey(...); и оно содержит всю информацию о его типе.
Неправда, о типе значения внезапно знает также весь код, который этим ключом пользуется. На фоне этого устранение типа из метода «getXXX» - капля в море.
> Тогда код для создания диалогового окна редактирования любых настроек нужно будет написать лишь единождыЭта голубая мечта сгубила, ох, очень многих
( ... )
Я не очень понял какое отношение ваша не любовь к Java-культуре имеет к этому конкретному шаблону. Шаблон первоклассного ключа отлично работает в любом объектно-ориентированным языке программирования. Поводов использовать его, например, на C++ не меньше, а то и больше, чем на Java. Более того, область его применения не ограничивается конфигурационными файлами. Мы с помощью него решаем множество разных задач.
Но даже если ограничить себя решением исключительно задачи хранения конфигурационного фала, то в реальном большом приложении всё не так просто как вам кажется.
> Число, строка, дата/время, путь до файла, ммм, регэксп? Мне кажется, что типы - они вне конфига уже.
Собственного, говоря, идея о том, что типов очень мало является типичным заблуждением, и это заблуждение не обошло стороной и язык Java - достаточно посмотреть на java.util.pref.Preferences. Причем, там даже видно, что авторы чуствовали, что где-то есть подвох, но не до конца понимали где он. Посмотрите на методы getXXX в Preferences - все они принимают вторым
( ... )
> как только параметры начнут зависить друг от друга, ваши ключи вдруг сразу окажутся неприменимы - обидно.
Согласен, в этом случае будет не применим. Однако, у меня есть опыт работы с реальными приложениями, где десятки независимых параметров хранятся с помощью первоклассного ключа и не разу не возникало необходимости сделать хотя бы пару параметров зависимыми. И это естественно для модульного приложениям - если модули не очень раздуты то в каждом модуле будет от силы один параметр (вообще параметры это зло и без необходимости их лучше не делать), а у разных модулей параметры очевидно независимы.
> Конфиг - это целое, и раздербанивать его на куски непонятно зачем.
Конечно, если ваше приложение монолитное и конфиг вашего приложение это нечто целое, то и шаблон первоклассного ключа вам для него не очень нужен. Вы его можете инкапсулировать в один цельный объект - код будет проще и понимать его будет проще.
По поводу веб-фрейморков прокомментировать, к сожалению, не могу - я не эксперт по созданию веб-приложений.
Comments 26
Reply
Reply
Reply
Вы придумали себе проблему и успешно ее решили. Вы сделали из простой вещи сложную. Вы наплодили сущностей. Вы нагородили иерархию классов и даже UML-диаграмму нарисовали!
Чтобы мои нападки не выглядели голословными (извините, если чересчур резко), прокомментирую:
> в большом модульном приложении будет использоваться много разнообразных типов
Серьезно? Число, строка, дата/время, путь до файла, ммм, регэксп? Мне кажется, что типы - они вне конфига уже.
> Есть единственное место в коде, которое определяет конкретный экземпляр каждого первоклассного ключа, что-то вроде static final IntKey MY_KEY = new IntKey(...); и оно содержит всю информацию о его типе.
Неправда, о типе значения внезапно знает также весь код, который этим ключом пользуется. На фоне этого устранение типа из метода «getXXX» - капля в море.
> Тогда код для создания диалогового окна редактирования любых настроек нужно будет написать лишь единождыЭта голубая мечта сгубила, ох, очень многих ( ... )
Reply
Но даже если ограничить себя решением исключительно задачи хранения конфигурационного фала, то в реальном большом приложении всё не так просто как вам кажется.
> Число, строка, дата/время, путь до файла, ммм, регэксп? Мне кажется, что типы - они вне конфига уже.
Собственного, говоря, идея о том, что типов очень мало является типичным заблуждением, и это заблуждение не обошло стороной и язык Java - достаточно посмотреть на java.util.pref.Preferences. Причем, там даже видно, что авторы чуствовали, что где-то есть подвох, но не до конца понимали где он. Посмотрите на методы getXXX в Preferences - все они принимают вторым ( ... )
Reply
Reply
Согласен, в этом случае будет не применим. Однако, у меня есть опыт работы с реальными приложениями, где десятки независимых параметров хранятся с помощью первоклассного ключа и не разу не возникало необходимости сделать хотя бы пару параметров зависимыми. И это естественно для модульного приложениям - если модули не очень раздуты то в каждом модуле будет от силы один параметр (вообще параметры это зло и без необходимости их лучше не делать), а у разных модулей параметры очевидно независимы.
> Конфиг - это целое, и раздербанивать его на куски непонятно зачем.
Конечно, если ваше приложение монолитное и конфиг вашего приложение это нечто целое, то и шаблон первоклассного ключа вам для него не очень нужен. Вы его можете инкапсулировать в один цельный объект - код будет проще и понимать его будет проще.
По поводу веб-фрейморков прокомментировать, к сожалению, не могу - я не эксперт по созданию веб-приложений.
Reply
Leave a comment