Które wzorce projektowe na początek?

Najbardziej przydają się te "oczywiste" których wielu ludzi używa nawet o tym nie wiedząc:
Strategy, Template Method, Adapter, Facade, Builder, Factory, Decorator

Możesz poznać różne wzorce projektowe - to nie szkodzi. Ale mam taką prośbę - nie staraj się ich używać. (chyba, że potrzebujesz do CV).

Z ciekawostek tu Mario Fusco opowiada które wzorce są już bez sensu (w Javie 8):

a tu Ted Neward , które wzorce służyły tylko łataniu słabości języka programowania
https://vimeo.com/110814038

Tak jak napisał @Shalom jest dużo wzorców projektowych które są stosowane często nieświadomie,np. :
Decorator - http://stackoverflow.com/questions/6366385/decorator-pattern-for-io
Template Method - http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/JdbcTemplate.html
Strategy -https://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html - możesz na przykład mieć jakąś kolekcje i na podstawie tego czy naciśniesz dany button taka będzie wykorzystana implementacja komperatora

Wszystko zależy od tego, co chcesz stworzyć. Mam taką starą książkę J2EE, w której jest sporo "niestandardowych" wzorców, choć de facto nie są niestandardowe, tylko obecnie nie tak popularne, jak kiedyś. To było jeszcze w czasach, gdy Java Spring był mało popularny.

Wg. mnie najbardziej istotne wzorce to m.in. Observer, Dependency Injection, Strategy, oczywiście MVC (tak tak, to wzorzec projektowy - architektoniczny - de facto wszystkie wzorce projektowe dotyczą, how surprising, projektowania, czyli architektury), Provider (tudzież Bridge), Adapter. Na początek te, plus wypisane powyżej, i wystarczy IMO.

"Możesz poznać różne wzorce projektowe - to nie szkodzi. Ale mam taką prośbę - nie staraj się ich używać."
Nie wiem czy dobrze zrozumiałem, ale właśnie to wzorce projektowe są jednym z fundamentów tego, że możesz rozczytać się w czyimś kodzie nie ruszanym od paru lat. Oczywiście bez sensu jest ich używanie na siłę, żeby było więcej wzorców, ale chyba nie można zakwestionować tego, ile wnoszą do projektu
Jest coś takiego jak zasady SOLID, z niej wynikają wzore projektowe, a z nich z kolei dobre praktyki programowania :)

A to ciekawe - gdzie dokładnie z reguł SOLID wynikają wzorce projektowe? A z wzorców dobre praktyki ?
Ale co jak zrobie wszystko na Singletonie - to jest od razu dobrze (bo jest wzorzec)?

Wzorce bardzo pomagają komunikacyjnie - możesz nazwać co zastosowałeś, ale IMO to powinno przebiegać tak:

• piszę kod, poprawiam, minimalizuję ... i widzę, że to jest jakiś wzorzec (ale tylko ewentualnie- nie jest to moim celem).

Natomiast Stary Kod najczęściej mi mówi : oho! w 2009 ten programista ogarnął Strategy no i powrzucał gdzie się dało.

Właśnie widzę , że dziś jeszcze nigdzie Brigde nie użyłem (zaraz poprawie).

@jarekr Może nie do końca dobrze się wyraziłem. Wzorce projektowe nie łamią zasad SOLID. Możesz zauważyć, że większość z popularnych wzorców (nie będę się upierał, że wszystkie, bo się aż tak nie interesowałem) przestrzega tych zasad. Przykłady: strategia i zasada LSP, template method i ocp, fabryka abstrakcyjna i DIP.
Z wzorców naturalnie wynikają dobre praktyki. Wierz mi, że lepiej jest oglądać oklepaną do bólu strategię niż własne próby wymyślenia jakichś fantazyjnych wzorców :)
Singleton jak zapewne wiesz jest bardzo często używany jako antywzorzec, więc akurat tego bym unikał.
Jako przykład dobrej praktyki: zdecydowanie lepiej czyta się chain of responsibility albo strategię niż ogromniastego switcha albo else-ifa nawet gdyby implementacje klas biorących udział w łańcuchu/strategii były banalne (zawsze zostawiasz sobie zabezpieczenie na przyszłość, gdyby wymagana funkcjonalność mogła urosnąć)

Ta strategia i LSP to akurat przykład wymagający mocnej wyobraźni.... (ale ponieważ LSP jest niejako podstawą programowania obiektowego - więc ... jasne).

Natomiast nie zgadzam się co do wynikania.

Dobre praktyki (o ile są jedne.. (a nie ma) ) są niezależne od wzorców.
Niektóre wzorce w w dobrym kodzie nie przeszkadzają. Początkujacym programistom czasem pomagają odnaleźć rozsądne rozwiązania.

Problem polega na tym, że większość tłuczonych w książkach i na rozmowach wzorców została opisana w połowie lat 90-tych.
Troszkę się zmieniło od tego czasu. (Wtedy myślałem, że będę tylko wybierał wzorce z palety i budował systemy w UMLu - nawet był taki soft Together, który to całkiem nieźle robił).
Wyszła z tego niejedna masakra i dużo kasy spłonęło w wygenerowanych kodach....

Widzę, że zaczęła się dyskusja pod tytułem "Czy wzorce projektowe mają sens?" po raz tysięczny.

1. Wzorce projektowe to sprawdzone sposoby na rozwiązywanie konkretnych problemów.
2. Użycie wzorców projektowych nie gwarantuje rozwiązania problemu.
3. Wzorce projektowe nie są jedynymi sposobami na rozwiązanie danego problemu.
4. Wzorce projektowe nie muszą też być najlepszym sposobem rozwiązania problemu.
5. Z moich obserwacji - ludzie potrafiący napisać coś, co w danym przypadku lepiej się sprawdzi od wzorca w 95% przypadkach znają te wzorce.

Odpowiadając na pytanie autora - najlepiej, żebyś poznał wszystkie z GoF: http://www.mcdonaldland.info/2007/11/28/40/

Wiem że warto znać wzorce projektowe, jednak jakoś do tej pory nie mialem potrzeby ich używania.
Których waszym zdaniem wzorców najczęściej się używa, a których nie warto sie uczyć.
Pytanie może bardzo ogólne, ale od czegoś trzeba zacząć. Na początek polecial mvc, nie licze na odpowiedzi w stylu Naucz sie wszystkich ;)

Wzorce to buzzword. Coś co zostało wymyślone po fakcie. Kiedyś czterech autorów książki chciało usystematyzować wiedzę na temat programowania, a ponieważ zauważyli, że wiele programistów używa podobnych schematów w kodzie, to wzięli i opisali te podobne schematy jako wzorce. Dzięki temu można o tym książki pisać, można się tego uczyć, można o tym dyskutować.

jednak jakoś do tej pory nie mialem potrzeby ich używania.

Jakby się uprzeć to wszystko jest wzorcem. Używałeś klas? No to używałeś wzorca klasy (że jest to wzorzec, a nie jakaś magiczna nieodłączna część języka świadczy choćby fakt, że klasy można tworzyć nawet w językach które nie mają pojęcia klasa (np. w C albo w starym JavaScripcie).

Same metody w obiektówce to też pewnego rodzaju wzorzec (metoda to funkcja przypisana do konkretnego obiektu, czyli już jest to pewien wzorzec, bardziej zaawansowana organizacja kodu niż proste funkcje. Zwykle jest to robione na poziomie samego języka programowania, co nie znacza, że przestaje to być wzorcem). W zasadzie warto programować w różnych językach programowania, wtedy się widzi, ile rzeczy oczywistych to w rzeczywistości też pewien wzorzec.

Generalnie tak - warto poznawać wzorce, i eksperymentować z nimi, bo to może być źródło wiedzy/doświadczenia programistycznego. Jednak koniec końców warto zobaczyć na własnej skórze, które wzorce się sprawdzają w jakiej sytuacji i używać z rozsądkiem. Nie chodzi o to, żeby robić religię z jakichś konkretnych wzorców, także nie chodzi o to, żeby na siłę czegoś się uczyć (lepiej jest poznawać wzorce w praktyce niż siedzieć z podręcznikiem i wkuwać bez sensu. Podręczniki o wzorcach projektowych mają 2 wady:

• zawierają rzeczy wyjęte z kontekstu, takie prawdy w proszku
• zwykle takie podręczniki czytają osoby początkujące, które mają za mało doświadczenia, żeby znaleźć dla nich konkretne zastosowanie (ja jak czytałem o wzorcach kiedyś to niektóre wzorce były "ooo, znam to, sam tak robię, nie wiedziałem że to ma taką nazwę" ale inne z kolei to były raczej "WTF, po co to. Nie rozumiem").

Dzięki wszystkim za odpowiedzi, upewniliście mnie żę najwyższy czas poznać wzorce i ocenić samemu ich przydatność. Zaczne od tych wypisanych przez Shalom. Dzięki