Теперь представим ситуацию, что меняется тип данных какого-то параметра. В 4 варианте, придётся поменять лишь getter и setter: Было int getCode(), setCode(int v) Стало String getCode(), setCode(String v)
В варианте Ксакепа при сохранении всё заменится автоматически, если будет использоваться полиморфизм: Было save(KEY, code) -> save(String key, int value) Стало save(KEY, code) -> save(String key, String value) Всё прекрасно, все довольны. Но с получением - беда.
А значит: 1 вариант. В Start, Saver и Other нужны константы с ключами. Запись будет выглядеть так: Prefs.save(KEY, "value"); Плохо - нужно тягать константы 2 вариант. Не использовать константы, а писать ключ сразу. save("key", "value"). Плохо - можно ошибиться в написании, сложно рефакторить 3 вариант. Создать класс и хранить в нём ключи. Класс PrefKeys. Запись: save(PrefKeys.KEY, "value") Хорошо. Но требует лишнего класса 4 вариант - закинуть всё Prefs Хорошо - не нужны ключи в др клсх
Чтобы всем всё было понятно, вот пример. Допустим, есть классы: - Start - читаем логин и пароль - Saver - записываем логин и пароль - Other - читаем логин, записываем пароль. Ну и сам Prefs.
Если Prefs не знает ничего о хранимых значениях, как того требует Ксакеп. То нам нужно передавать ключ и значение, чтобы сохранить, и ключ, чтобы загрузить значение.
vl@volk, и тогда получается, что для сохранения параметра нужно передавать key и значение, а значит нужно тягать за собой константы или помнить имена всех ключей.
aNNiMON, в любом случае задача класса состоит в том, чтобы перекинуть некоторый объект (настройки) куда-то там далеко в неведомую вселенную (на карту памяти). И он не должен знать о том, что это поля username/score, или ещё какие. Слишком сильная связь получается.
Я пока что вижу так: должен быть некоторый объект, собственно, черный ящик. И вот его пусть и записывает (или сериализует) этот класс.
let live
