@Shalom Twoja odpowiedź nie jest odpowiedzią na moje pytanie.
Wiem, że dekorowaniem można sobie rozszerzać zachowanie klasy tak jak to mamy w przypadku strumieni z java.io.
Chciałbym po prostu wiedzieć dlaczego Daklu potępił rozwiązanie w oparciu o metodę add.
Konkretny przykład:
W moim przykładzie powiedzmy, że chciałbym dynamicznie konstruować walidatory ogłoszeń, bo ogłoszenie na każdej ze stron wyróżniać mogą się innymi danymi i innym stopniem ważności.
(Sposób z add)
W takim przypadku postanowiłem, że zrobić N klas walidatorów dziedziczących po JobAdValidator. Potem dla każdej klasy przetwarzającej serwisy będę przekazywał listę walidatorów, a klasa serwisu w pętli odpali kolejno te walidatory.
(Sposób z dekoratorem)
W przypadku, gdybym miał użyć dekoratora zrobiłbym tak - wychodzę od bazowego walidatora, i go dekoruje go kolejnymi walidatorami. Wtedy uzyskuje jeden walidator, który przekazuje do serwisu i ten serwis wywołuje go bez uruchamiania pętli.
Na moje oko oba podejścia są w miarę okej; choć pierwsze bez dekoratora jest moim zdaniem czytelniejsze.