Я не очень понял какое отношение ваша не любовь к Java-культуре имеет к этому конкретному шаблону. Шаблон первоклассного ключа отлично работает в любом объектно-ориентированным языке программирования. Поводов использовать его, например, на C++ не меньше, а то и больше, чем на Java. Более того, область его применения не ограничивается конфигурационными файлами. Мы с помощью него решаем множество разных задач.
Но даже если ограничить себя решением исключительно задачи хранения конфигурационного фала, то в реальном большом приложении всё не так просто как вам кажется.
> Число, строка, дата/время, путь до файла, ммм, регэксп? Мне кажется, что типы - они вне конфига уже.
Собственного, говоря, идея о том, что типов очень мало является типичным заблуждением, и это заблуждение не обошло стороной и язык Java - достаточно посмотреть на java.util.pref.Preferences. Причем, там даже видно, что авторы чуствовали, что где-то есть подвох, но не до конца понимали где он. Посмотрите на методы getXXX в Preferences - все они принимают вторым
( ... )
>> общий Config для модулей A и B так, чтобы его можно было бы централизованно загрузить, проверить на is_valid, отредактировать и т.п.
Properties config = new Properties().load(file); ... ConfigA a = new ConfigA(config); ... ConfigB b = new ConfigB(config);
>> Нужно ли всем этим методам зависеть от какого-то общего Config класса, который знает что-то про каждый из них?
Они же не от всего класса зависят, а только от своего параметра внутри этого класса. Так что не вижу проблемы.
>> главное, надо передавать строку с именем параметра
Не вижу разницы между тем, что передавать - строку или константу с именем строки. Но сколько вы смогли высосать из этой детали - впечатляет.
>> Отлично работает и даже по объему кода в чем-то сравнимо с шаблоном первоклассного ключа, но только в случаем монолитного приложения, когда параметров много и они в одном классе.
То есть вас всё устраивало и проблем не было, но вы от этого простого решения ушли, руководствуясь просто абстрактным принципом?
>Не вижу разницы между тем, что передавать - строку или константу с именем строки. Но сколько вы смогли высосать из этой детали - впечатляет.
Разница настолько большая, что прямо даже в два слова сложно объяснить. Напишу об этом на досуге отдельный пост. Грубо говоря, ключевое качество хорошего кода заключается в том, что человек может легко убедиться в правильности этого кода при его прочтении с минимальным для себя усилием, зная что этот код успешно проходит этап компиляции.
>То есть вас всё устраивало и проблем не было, но вы от этого простого решения ушли, руководствуясь просто абстрактным принципом?Не было бы пробем не уходил бы. Какак я уже сказал, класс-конфигурация отлично для меня работает в монолитных приложниях, и, конечно, ничто не мешает каждому модулю иметь свой собственный класс-конфигурацию. Но когда модулей становится всё больше и больше, а параметров конфигурации не очень много по отношению к объему кода и они (параметры) размазаны тониким слоем по коду так, что редко получается более одного
( ... )
Не будут ни в чем убеждать. Для меня возможность думать, что я убедился в правильности кода, вполне достаточна. Зачем именно она мне нужна - раскажу отдельно.
Но даже если ограничить себя решением исключительно задачи хранения конфигурационного фала, то в реальном большом приложении всё не так просто как вам кажется.
> Число, строка, дата/время, путь до файла, ммм, регэксп? Мне кажется, что типы - они вне конфига уже.
Собственного, говоря, идея о том, что типов очень мало является типичным заблуждением, и это заблуждение не обошло стороной и язык Java - достаточно посмотреть на java.util.pref.Preferences. Причем, там даже видно, что авторы чуствовали, что где-то есть подвох, но не до конца понимали где он. Посмотрите на методы getXXX в Preferences - все они принимают вторым ( ... )
Reply
Properties config = new Properties().load(file);
...
ConfigA a = new ConfigA(config);
...
ConfigB b = new ConfigB(config);
>> Нужно ли всем этим методам зависеть от какого-то общего Config класса, который знает что-то про каждый из них?
Они же не от всего класса зависят, а только от своего параметра внутри этого класса. Так что не вижу проблемы.
>> главное, надо передавать строку с именем параметра
Не вижу разницы между тем, что передавать - строку или константу с именем строки. Но сколько вы смогли высосать из этой детали - впечатляет.
>> Отлично работает и даже по объему кода в чем-то сравнимо с шаблоном первоклассного ключа, но только в случаем монолитного приложения, когда параметров много и они в одном классе.
То есть вас всё устраивало и проблем не было, но вы от этого простого решения ушли, руководствуясь просто абстрактным принципом?
Reply
>Не вижу разницы между тем, что передавать - строку или константу с именем строки. Но сколько вы смогли высосать из этой детали - впечатляет.
Разница настолько большая, что прямо даже в два слова сложно объяснить. Напишу об этом на досуге отдельный пост. Грубо говоря, ключевое качество хорошего кода заключается в том, что человек может легко убедиться в правильности этого кода при его прочтении с минимальным для себя усилием, зная что этот код успешно проходит этап компиляции.
>То есть вас всё устраивало и проблем не было, но вы от этого простого решения ушли, руководствуясь просто абстрактным принципом?Не было бы пробем не уходил бы. Какак я уже сказал, класс-конфигурация отлично для меня работает в монолитных приложниях, и, конечно, ничто не мешает каждому модулю иметь свой собственный класс-конфигурацию. Но когда модулей становится всё больше и больше, а параметров конфигурации не очень много по отношению к объему кода и они (параметры) размазаны тониким слоем по коду так, что редко получается более одного ( ... )
Reply
Увы, убедиться он не может, но думать, что убедился - да. Мне не нужно объяснять разницу - было время, я тоже думал как вы, и все аргументы знаю.
Reply
Reply
Leave a comment