Wzorce ProjPraca programistów polega na rozwiązywaniu problemów “X”. Wiele z nich się powiela i zostały one już wcześniej rozwiązane. Przez wiele lat rzemiosło programowania obiektowego się doskonaliło. Powstała duża liczba wzorców i zasad ,a najlepsze z nich doczekały się swoich nazw i kategorii.
Posiadając wiedzę na temat wzorców jak i pospolitych rozwiązań jesteśmy w stanie rozwiązywać złożone problemy.Te rozwiązania są powszechne mamy do nich zaufanie, ponieważ wiemy ,że dużo wcześniej przed nami ktoś te wzorce z powodzeniem stosował.
Fundamentem wzorców projektowych są zasady S.O.L.I.D (solid object oriented design) i one będą opisane w następnym wpisie ,a na razie trochę wstępu.
Co to jest wzorzec projektowy
Wzorce projektowe są to gotowe szablony rozwiązań abstrakcyjnych. Nie są magicznym pudełkiem, który sprawi ,że aplikacja będzie cudowna ,ale są jakby mapą i instrukcją prowadzącą do określonego celu.
Nie znajdziesz frameworka, który automatycznie dodał jest do twojej aplikacji…chociaż poprawka są pewne frameworki ,które narzucają pewne wzorce jak ASP.NET MVC ,ale i tak najczęściej użycie wzorców wiąże się refaktoryzacją (tak istnieje takie słowo lepiej zapisać go do swojego słownika 
) twoje kodu i do generalizacji problemu.
Wzorce projektowe nie są przeznaczone tylko do programowania mogą być one znalezione w innych rejonach jak inżynieria i architektura.
Pewien słynny architekt Christopher Alexander napisał w 1970 roku definicję “wzorca projektowego” , która została uznana za powszechną . Może być ona znaleziona pod oficjalną definicją “Design Patterns” w Wikipedii.
The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. — Christopher Alexande
Jak widzisz definicja ta również bez problemu odnosi się do programowania.
Kategorie wzorców
Kolekcja wzorców, która rosła przez wiele lat doczekała się nawet swoich własnych kategorii. Jest ich trzy.
- Creational PatternsWzorce tworzenia –zajmują się konstrukcją obiektów i ich referencjami
- Structural Patterns Wzorce strukturalne – zajmują się związkami pomiędzy obiektami i tym jaka powinna być interakcja pomiędzy nimi . Wszytko to w celu ułożenia złożonego obiektu.
- Behavioral Patterns Wzorce zachowania –zajmują się komunikacją pomiędzy obiektami. Głównie występują w algorytmach i w skomplikowanych systemach odpowiedzialności pomiędzy obiektami.
Każdy z tych szablonów postaram się omówić w przyszłych wpisach.
Konieczność poznania wzorców
Wzorce są esencją programowania i tworzenia aplikacji. Pomagają nam rozwiązać problemy, zanim jeszcze usiądziemy przed komputerem, czyli na etapie projektowania. Wzorce pozwalają na stworzenie dobrego zorientowanego obiektowego oprogramowania, ponieważ są stworzenie według pewnych solidnych zasad.
Wzorce są też dobrym sposobem komunikacji pomiędzy członkami zespołu –bez przejmowaniem się nisko-poziomymi detalami w implementacji.
Wzorce są niezależne od języków programowani i danych platform. Czyli ucząc się ich wiesz ,że ta wiedza może być użyta do każdego języka obiektowego.
Kolejną ich zaletą jest fakt ,że na przestrzeni lat nie zmieniają się w przeciwieństwie do technologii i platform. Dowodem są książki o wzorcach, które są nadal aktualne.
Użyteczność
Użyteczność wzorców kryje się za faktem ,że są to już sprawdzone rozwiązania mające określony poziom efektywności. Inną sprawą jest fakt ,że programując już jakiś czas w C# bądź w innym języku obiektowym, możesz czasami zdać sobie sprawę ,że nieświadomie stosujesz niektóre wzorce projektowe.
Jednak do bycia dobrym programistą musisz te wzorce sprawnie identyfikować .Tak aby w przyszłości nie mieć problemów z komunikowaniem się z pozostałymi członkami zespołu. Rozumiejąc wzory będziesz rozumiał strukturę danych rozwiązań.
Zawsze szybciej mówi się o właściwościach danego wzorca niż o detalach jak np. implementacja mogłaby zadziałać.
Wzorce projektowe to nic innego jak ponowne użycie znanych rozwiązań. Nie wszystkie problemy są sobie równe. Rozumiejąc i widząc pewne cechy wspólne związane z problemami, które już wcześniej rozwiązałeś jesteś w stanie wybrać dobre rozwiązanie.
Przez dekady w programowaniu obiektowym większość problemów zostały już rozwiązane niezliczenie liczbę razy.
Nawet jeśli problem, z którym walczysz jest unikatowy to i tak łamiąc go na mniejsze części odnajdziesz właściwą solucje.
Czym nie są wzorce
Nie wszystkie problemy programistyczne wymagają zastosowania wzorców projektowych. To prawda, że wzorce rozwiązują złożone problemy ,ale raczej nie chcesz przekształcać tych prostych problemów na złożone, tylko po to, aby można było zastosować jakiś wzorzec X.
Wiele programistów, którzy są zafascynowani wzorcami popadają w małą pułapkę i próbują stosować wzorce wszędzie gdzie się da. Efekt stosowania wzorców dla prostych aplikacji jest wręcz odwrotny do tego co same wzorce projektowe zakładają . Mają one wszystko ułatwiać.
Jeśli napisaliśmy działający kod do aplikacji X i nie planujemy go rozwijać, to raczej nie powinnyśmy się nad sobą użalać ,że kod może być lepiej napisany, skoro on już jest. 
Osobiście sam niepotrzebnie popadałem w depresje związaną z nieokreśloną definicją dobrego kodu . Zawsze, gdy kończyłem pisanie kodu odnajdowałem lepsze rozwiązanie “X”. Wcześniej nie mogłem go zauważyć, ponieważ nie wiedziałem czegoś “Y”. Ale z punktu widzenia studiów inżynierskich, przy pisaniu projektów na zaliczenie przedmiotów sam wygląd kodu i fakt, że zastosowałem wzór “Z” , aby program działał 0,1 sekundę szybciej, nie miało większego znaczenia.
W życiu też tak jest, jeśli firma ma napisać prosty program mając do dyspozycji niewielki okres czasu to będzie go pisała na żywioł, bez stosowania jakiekolwiek wzorca.
Prezentacja przed klientem szkieletu gotowej aplikacyjne okaże się na pewno bardziej skuteczna niż pokazanie diagramów klas narysowanych na kartkach.
Jednym słowem nie ma doskonałego kodu nawet z wzorcami ,ale z perspektywy klientów i firm dobry kod, to kod, który spełnił cele X i tyle. Jeśli kod robi to, co miał robić, to znaczy ,że jest dobry.
Koniec wstępu
W następnym wpisie o zasadach stosowanych we wzorcach.
