to prawda że w zasadzie to
design patterns are not goals which we should strive for
ale nieprawdą jest jakoby
Hence, don't use patterns at when beginning your design of a project, use them after you've got a comprehensive structure in place, and only where they make sense
tu znów, będę uparty, kłania się brak znajomości pełnego katalogu wzorców. z resztą facet pisze że
To be clear, I've never read the Gang of Four book these patterns are defined in, so it's possible there's reasoning in the book that would alleviate my concerns. In fact, all of my knowledge about these patterns has come from online resources such as Do Factory
do tego zapewne nie przestudiował wszystkich tylko wybrane (te które zrozumiał).
Chodzi o to że pewne wzorce, takie jak jego Adapter, którego przykładem się posiłkuje, faktycznie nie są CELEM, tylko wychodzą niejako samoistnie jako dodatki w trakcie implementacji.
ale już takie podejścia jak Visitor czy Observer są celami samymi w sobie - one są podstawą architektury jakiegoś konkretnego kawałka aplikacji, a nie czymś co może wyjść samoistnie - bo nie ma niczego innego czym można by je zastąpić (w sensie: każde inne podejście, funkcyjne czy jakiekolwiek będzie równoważne).
Czyli mówiąc inaczej, taki Observer nie może wyjść "przez przypadek". Nie, Ty dokładnie chcesz takiej architektury w której jeden obiekt jest źródłem jakichś powiadomień, a wiele innych chce je odbierać - Ty tylko decydujesz jak to zaimplementować a każdą taką implementację nazwiesz "Observer".
Nie udało mi się namierzyć w sieci autorki tekstu (w sensie: osoby o takim nazwisku z historią pisania o technologii), a fotka kradziona jest od aktorki. 
