Okiem JellyTech -> Java trick(s) 🤓

November 24, 2022

NullPointerException… czyli koszmar każdego programisty Javy. Na ratunek przychodzi rozwiązanie znane już od Javy 8 – klasa Optional. Natomiast w jaki sposób najlepiej posłużyć się tą klasą?

Zerknijmy na poniższy fragment kodu:

‍

‍

Interface UserRepository opisuje metodę „findByName”, która powinna zwracać Optional<User>. Czy napewno jest to dobra praktyka ? 🤔 Klasy implementujące powyższy interface będą udostępniały dość niewygodną metodę, której wynik może nie zawierać wartości, więc należy go będzie sprawdzić, aby uniknąć NullPointerException. Przykładowy kod mógłby wyglądać następująco:

‍

czy w opakowaniu Optional znajduje się żądany obiekt a przypadku braku np. zgłosić wyjątek.

A może warto zastanowić się nad innym rozwiązaniem 🤔:

‍

I właśnie teraz dochodzimy do pytania: Jeżeli w przypadku nie znalezienia obiektu chcemy zawsze zgłaszać standardowy wyjątek, który oczywiście powinniśmy przechwycić (odrębny temat rzecz jasna😊) to może jest to lepsze rozwiązanie??

‍

Metoda defaultowa będzie miała na celu jak najszybszą walidację, a wrazie braku znalezienia obiektu rzuci wyjątkiem, co w jawny sposób deklaruje w sygnaturze metody.

Dzięki tej zmianie wywoływanie metody „findOrThrow” będzie miało dokładnie jedną linijkę i przy wprowadzaniu logiki biznesowej otrzymujemy bardzo czytelny zapis. Clean Code Rules!!! 😊😊😊

‍

Przedstawiony przykład jest zachęceniem do głębszego przemyślenia tematu czytelności, prostoty oraz ciągłego rozwoju własnego kodu.

‍

Galeria zdjęć

No items found.

Wideo

Back to previous site

In JellyTech's view -> Java trick(s) 🤓

Wojtek Rozwałka

November 24, 2022

NullPointerException...is every Java programmer's nightmare. To the rescue comes a solution already known since Java 8 - the Optional class. However, how best to use this class?

Let's have a look for this code snippe:

‍

Interface UserRepository describes a method "findByName" that should return Otpional<User>. Is this surely a good practice ? Classes implementing the above interface will provide a rather inconvenient method whose result may not contain a value, so it will have to be checked to avoid NullPointerException. An example code could look like the following:

‍

Whether the Optional package contains the desired object and if not, for example, report an exception.Or maybe you should consider another solution

🤔:

‍

And that's where we come to the question: if in the case of not finding an object we want to always report a standard exception, which of course we should intercept, but that's a separate topic 😊 then maybe this is a better solution???

The default method will be aimed at the fastest possible validation and if the object is not found, it will throw an exception, which it explicitly declares in the method signature. Thanks to this change, calling the method "findOrThrow" will have exactly one line and when introducing business logic we get a very readable record. Clean Code Rules!!! 😊😊😊

‍

The presented example is an encouragement to think more deeply about the topic of readability, simplicity and continuous development of your own code.

‍

And what do you think of the presented solution?

‍

Gallery

No items found.