Enkapsulowanie preferencji Java API

Question

Wcześniej posiadałem niestandardową klasę preferencji dla moich aplikacji. Do mojego następnego projektu hobby chciałem przejść do interfejsu API Preferencji. Ale funkcje put i get wymagają wartości domyślnej i nie chcę rozpowszechniać wartości domyślnych w plikach źródłowych. Mimo że mój projekt jest mały, nie wyobrażam sobie zmiany wartości domyślnych całego kodu źródłowego. Jak wy korzystacie api? Myślę o zawijaniu api preferencji w innej klasie, ale jaki jest sens używania API, ponieważ odbiera tylko ciężar zapisania pliku na dysku, co nie jest trudne przy użyciu serializacji? Czy brakuje mi punktu?

Answer 1

Czy byłoby tak trudno ustawić wszystkie ustawienia domyślne w jednej klasie, aby nie zaśmiecały kodu?

Użyłem commons configuration w ostatnich projektach. Sprawdziłem interfejs API preferencji Java, ale podoba mi się elastyczność projektu Commons. I nie musisz podawać wartości domyślnych!

Answer 2

Łączymy tu kilka koncepcji. Wartość domyślna podana w kodzie powinna być specyficzna dla sytuacji lokalnej jako "rozsądna wartość domyślna". Jeśli chcesz mieć ustawienia domyślne dla całej aplikacji, potrzebujesz dostawcy preferencji, który umożliwia przechwycenie zarówno domyślnych preferencji, jak i nałożonych preferencji użytkownika. Coś, co może być wartościowym projektem samym w sobie.

Och, a "rozsądne wartości domyślne" to świetny sposób na uniknięcie konfiguracji, gdy nie jest to konieczne, ale pozwalają użytkownikowi lub narzędziu pakującego na dostarczanie lepszych wartości w razie potrzeby.

@comment, myślę, że rozumiem.

Przez "sytuację lokalną" mam na myśli w kontekście kodu. W przypadku interfejsu GUI potrzebna jest wartość wyświetlania reprezentująca dowolny wątek. Dlatego użyłbym czegoś takiego jak Worker.DEFAULT_TIMEOUT. Twój pracownik używałby tej samej wartości wewnętrznie, co wartość domyślna. W ten sposób pobierasz skonfigurowaną wartość lub domyślną wartość roboczą, gdy ustawiasz zachowanie pracownika.

Answer 3

Możesz umieścić wartości domyślne w pliku .preferences, który pakujesz do pliku .jar (lub w specjalistycznej klasie lub interfejsie ze stałymi).

Używam go do takich rzeczy jak pozycje/rozmiary okien, pamiętając domyślny folder do wybierania plików, ostatnio otwarte pliki i takie ciekawostki. Mogę wymyślić kilka interesujących rzeczy, które otrzymujesz "za darmo" z preferencjami API:

• robienie rzeczy w sposób zalecany przez OS; System operacyjny może nie pozwolić ci pisać "plików ustawień" w folderze aplikacji, a użytkownicy nie lubią być pytani, gdzie na dysku chcą zapisać ustawienia, i nie chcesz zaimplementować swojej niestandardowej logiki dla każdej platformy
• dane są zapisywane dla każdego użytkownika osobno OS
• sposób, aby zachować dane użytkownika, nawet jeśli aplikacja jest odinstalowane (lub podczas aktualizacji)
• nie potrzebują dostępu do bazy danych lub systemu plików

Ponadto nie lubię serializacji i nie polecam jej. Serializacja oznacza, że ​​musisz zachować ostrożność podczas zmiany zajęć w nowych wersjach aplikacji.

Answer 4

Następnie możesz przejąć pełną kontrolę nad tym, jak Preferencje powinny podążać za żądaną pamięcią, wdrażając AbstractPreferences.Można zobaczyć wdrożenie opartego na Linux tutaj:

http://www.docjar.com/html/api/java/util/prefs/FilePreferencesImpl.java.html

Powodzenia!