Rysunek 1. obrazuje wygląd wzoraca projektowego: Fabryka, i możliwe nazwy klas.

Rysunek 2. obrazuje wygląd wzoraca projektowego: Chain Of Responsibility, i możliwe sprawdzenia.

Zadanie ma na celu przeniesienie walidacji (sprawdzenia poprawności) filtrów, z klasy ExpensesService do Fabryki, która jest tworzona, zmiany powinny się odbywać w obrębie metody getFilteredExpenses i metod powiązanych (jeśli występują).

Metoda assertFilter powinna posiadać cztery sprawdzenia, dobrze będzie je rozdzielić na oddzielne metody, aby łatwiej czytać kod (Clean Code), przykładowe nazwy dla zobrazowania czytelności kodu:

- checkIfFromDateExistsToAndToDateIsMissing

- checkIfToDateExistsAndToDateIsMissing

- checkIfMonthExistsAndYearIsMissing

- checkIfYearExistsAndMonthIsMissing

Konstrukcja każdej z powyższych metod będzie podobna, pseudokod:

```

    void checkIf_And_IsMissing(all necessary parameters) {

        if (key in filters form parameters are missing)     

            throwException(FilterExpensesParameterEnum.correct_value_from_Enum, next parameters - if necessary)

          // to jest metoda abstrakcyjna w klasie 

    }

```

Pamiętaj, że klasa ExpensesFilterParametersValidator powinna zostać oznaczona adnotacją @Component, to prawidłowego działania.

Po zmianach, w klasie ExpensesService trzeba wstrzyknąć ExpensesFilterParametersValidator i wykorzystać metodę, która jest dostarczona wraz z tą klasą: assertFilter

Uruchom testy, jeśli występują błędy (nie muszą występować) - popraw je.

HINT: Możesz w enumie ExpensesExceptionErrorMassage, dodać do metody getMessage parametr z nazwą pola, którego brakuje i zbudować String `"Missing: " + missingKey` - nie jest konieczne, jednak ułatwia czytanie kodu.

HINT: Nowo tworzone klasy możesz umieścić w nowym pakiecie filters: 'pl.dicedev.filters'

Robert Szczygielski Dice Dev. Polityka Prywatności i Regulamin Szkoleń Online

Strona www stworzona w kreatorze WebWave.