Używanie napisów w aplikacji

Napisy?

Typ string jest jednym z najczęściej używanych typów danych w aplikacji. Gdy go potrzebujemy to po prostu otwieramy cudzysłów, wpisujemy wartość i zamykamy cudzysłów. Bardzo często nawet nie zastanawiamy się, czy to dobre podejście.

Niestety w dłuższe perspektywie takie podejście oznacza problemy. A to robimy literówkę w kluczu podczas pobierania wartości z słownika, o której dowiadujemy się dopiero podczas wykonywana kodu (o ile go przetestujemy). A to musimy w 20 miejscach poprawić komunikat wyświetlany użytkownikowi, a nie zawsze CTRL + H to dobre rozwiązanie.

Dlatego warto się na chwilę zatrzymać i zastanowić się, czy nie można zrobić tego lepiej.

Rodzaje napisów w aplikacji

Na przestrzeni lat zauważyłem, że napisy w aplikacji możemy podzielić na dwa rodzaje:

  • wewnętrzne aplikacji – używane tylko w kodzie, na przykład nazwa ustawienia, klucz do słownika itp.
  • wyświetlane użytkownikowi w interfejsie aplikacji

Znając już rodzaje napisów w aplikacji, możemy dla każdego z nich przygotować mechanizm, który ułatwi pracę z nimi.

Napisy wewnętrzne aplikacji

Do stringów tego rodzaju wykorzystuje klasy z stałymi. Napisy grupuje według użycia i dodaje je do dedykowanych klas. Na przykład nazwy ustawień z pliku konfiguracyjnego będę znajdować się w klasie SettingsNames:

Później korzystam z tych stały w aplikacji. Dzięki temu unikam wszelkiego rodzaju literówek, bo w każdym miejscu używam tej samej wartości. Dodatkowo intellisense podpowiada dostępne wartości, co też jest bardzo pomocne:

Na ogół używam stałych (słowo kluczowe const w c#), ale czasami to nie wystarcza. Przykładowo WPF nie umożliwia bindowania do stałej, dlatego czasami korzystam z klas z polami statycznymi typu readonly, ale to są pojedyncze przypadki i na ogół w WPF:

Napisy wyświetlane użytkownikowi

Drugim rodzajem stringów używanych w aplikacji są napisy wyświetlane w interfejsie użytkownika (czy też innych miejscach np. wygenerowany dokument). Do nich wykorzystuje pliki resourców. Dzięki temu również na poziomie kodu mam napisy pogrupowane w klasy, podpowiedzi intelisense oraz dodatkowo z czasem mogę zdecydować się na tłumaczenie aplikacji na inne języki.

A w jaki sposób organizować napisy w resourcach? Widziałem różne sposoby. Niektórzy mają jeden duży plik, w którym są wszystkie napisy. Inni tworzą plik per moduły. Na przykład jeden dla użytkowników, drugi dla produktów i tak dalej. Myślę, że nie ma jednego idealnego sposobu i wszystko zależy od aplikacji, którą tworzymy.

Osobiście najczęściej tworze pliki resource per plik widoku. Nie ma tutaj znaczenia, czy to jest cały widok, czy tylko jakaś kontrolka osadzana w innym widoku. Dodatkowo mam jeszcze pliki globalne, dla całej aplikacji oraz poszczególnych modułów, w których wrzucam często używane napisy.

U mnie takie podejście sprawdza się w aplikacjach, ale niestety musimy się nastawić, że z czasem, gdy będziemy tłumaczyć aplikacji, będziemy musieli trochę zmienić pliki resourców. Może się okazać, że w jednym z widoków z racji braku miejsca chcemy inaczej przetłumaczyć globalny napis, więc przestajemy korzystać w tym miejscu z globalnego resource, a dodajemy wpis w dedykowanym resource dla danego widoku.

Dodatkowo mam jeszcze pliki resourców dla niektórych klas w aplikacji. Są to głównie klasy logiki biznesowej, w której są komunikaty, np. błędy walidacji, czy inne informacje.

Osobiście do logów też korzystam z plików resourców. Są to dedykowane pliki, które później na ogół nie są tłumaczone i są tylko w języku angielskim lub polskim.

Przykład

Tym razem przykład (https://github.com/danielplawgo/WorkingWithStrings) jest bardzo prosty. Jest to prosta aplikacja consolowa, który wyciąga wartość z app settings (tak wiem, jest jeszcze, drugi mechanizm, który generuje ładne silnie typowane klasy) i wyświetla komunikat użytkownikowi z pliku resource. Po pobraniu przykładu, wystarczy go uruchomić. Jest nie potrzebna dodatkowa konfiguracja.

Podsumowanie

Jak życie pokazuje, warto zastanowi się nad tym w jaki sposób organizujemy używanie napisów w aplikacji. Za każdym razem, gdy potrzebuje dodać nowego stringa, zastanawiam się do jakie kategorii należy. Następnie tworzę nową stałą lub nowy wpis w pliku resource. Narzut na tą dodatkową pracę nie jest zbyt duży, szczególnie, że szukanie literówki w pobieraniu jakiś danych może zająć dużo więcej czasu.

A jak Ty organizujesz używanie napisów w aplikacji?

1 thought on “Używanie napisów w aplikacji

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *