Wpis z mikrobloga

@PhoenixSoul:

1. Formatowanie
2. Zmienne private static i metody public static, które z nich korzystają to proszenie się o kłopoty, to nie przejdzie.
3. Obiekt Transaction lepiej zrobić immutable skoro i tak nie używasz setterów, czyli zmienne instancji na private final i same gettery
  • Odpowiedz
@PhoenixSoul: Ponieważ widzę, że rozwiązanie zaczyna zmierzać w stronę czegoś w miarę dobrego to moje uwagi:
1. FileDataConverter to nie jest dobra nazwa dla tej klasy, ona nic nie konwertuje, a tego spodziewałbym się po nazwie
2. Konstruktor jak i jakakolwiek metoda nie powinna mieć parametrów takiego samego typu koło siebie (konstruktor Transaction), jest to błędogenne (być może jakiś builder do tej klasy by się nadał)
3. Nigdy nie rzucaj ręcznie NullPointerException. Jeśli
  • Odpowiedz
@PhoenixSoul: Braki w OOP, ale też braki w zrozumieniu samych mechanizmów języka, takich, jak np. exception handling, użycie poprawnych struktur danych, itp.

Myślę, że zgłębienie zasad SOLID (ale nie wkucie ich na pamięć, bez zrozumienia) powinno pomóc.
  • Odpowiedz
if(row[0] == null) throw new NullPointerException(); nie rob tak. potem jeszcze masz catcha i robisz sysout. nie steruj tak wyjatkami sa kosztowne (See Bloch's Item 57 in Chapter 9 of Effective Java) .

oprocz tego nie korzystaj z linked listy
  • Odpowiedz
3. Nigdy nie rzucaj ręcznie NullPointerException. Jeśli jakiś argument jest niepoprawny to IllegalArgumentException


@PhoenixSoul: @Legol: to jest dyskusyjna kwestia.
Jest taka niepisana zasada (wielu programistów tak robi), że IllegalArgumentException rzuca się intencjonalnie, żeby pokazać, że przekazany argument do metody jest niewłaściwy. Natomiast NullPointerException rzucany jest automatycznie, jeśli coś się popsuło w kodzie (najczęściej kiedy referencja do obiektu jest nullem i próbujemy wywołać na tej referencji metodę).

Z drugiej strony, cała
  • Odpowiedz