DekoratorWzór.1 Dekorator. Śmiało mogę powiedzieć, że jest to jeden z najważniejszych wzorców projektowych. Można powiedzieć, że jest on prawie częścią każdego systemu, ponieważ nie ma co ukrywać, jest on pożyteczny i użyteczny nawet do dzisiaj.

Dekorator pozwala dodać istniejącej klasie nowe zachowanie.  Nie zmienia on jednak działanie klasy podstawowej. Oznacza to, że spełnia następujące zasady S.O.L.I.D:

 

  • pojedynczej odpowiedzialności
  • zasady otwartej-zamkniętej

Dekorator jak i jego klasa bazowa mają tylko jedno zadanie. Dekorator pozwala nawet rozbić zachowanie klas, jeśli widzisz, że te rozbicie jest potrzebne. W tym przykładzie to pokażę.

Chciałbyś się zapewne nauczyć tego wzorca. Zamiast tego przyjrzymy się przykładzie Pizzy. Kod jest do pobranie na końcu artykułu.

Wyobraź sobie, że masz następujący zestaw klas.

ISP LSPZasada „Interface Segregation” stwierdza, że klient nie powinien być zmuszony do implementacji interfejsów, których nie używa. Celem tej zasady jest utrzymanie jednej odpowiedzialności wraz ze wzrostem jednego interfejsu. System nie powinien posiadać grubych interfejsów, a jeśli już takie istnieją to powinny być wydzielone na mniejsze grupy, które mają spójną funkcjonalność.

Pozwala to podklasom na stworzenie implementacji tylko grupy zachowania zamiast implementacji monolitycznej kontraktu, która będzie dziurawa i będzie zawierać wyjątki NotImplementedException informujące o braku implementacji danej metody.

Smart UI ASP.NET Web Forms i Visual Studio łatwo wprowadzają początkujących programistów w świat technologii webowych . Ktoś mógłby powiedzieć, że pisanie aplikacji w ASP.NET sprowadza się do przyciągania i upuszczania kontrolek do okna designer-a HTML. W ASP.NET każda strona HTML o rozszerzeniu pliku .aspx zawiera swój drugi plik z kodem pobocznym. W tym kodzie zawiera obsługę zdarzeń, dostęp do danych i logikę biznesową aplikacji.

Dla początkującego programisty, te proste założenia znacznie przyspieszają naukę frameworka. Nie zmienia to jednak faktu, że ten domyślny styl programowania jest wadliwy i już dla średnio zawansowanych aplikacji webowych tworzy następujące, poważne problemy.

Config ClassW poprzedniej pracy zgodnie z zalecanym wzorcem tworzyliśmy klasę konfiguracyjną której właściwości odpowiadały wartościom słownikowym  w pliku konfiguracyjnym.  Taka klasa rozwiązuje problem z magicznymi stringami i plikami konfiguracyjnymi. Wtedy  ja taką klasę  pisałem ręcznie co jest czystą głupotą ponieważ można napisać template T4 który zrobi to za nas.

Zasady

Przed pracą praktyczną nad kodem postanowiłem napisać kolejny wstęp do wzorców projektowych.



Powszechne zasady projektowe

Istnieje pewna liczba powszechnych zasad projektowych, z którymi szczerze mówiąc spotkałem się zanim jeszcze rozpocząłem swoją przygodę z programowaniem.
Niektóre zasady mogą wydawać się banalne ,ale moim zdaniem nawet początkujący programista powinien ich przestrzegać.
Jeśli myślisz, że się z nimi nie spotkałeś to możesz się zdziwić .Te zasady możesz znać, tylko nie wiedziałeś ,że mają one swoje określone nazwy. 

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 desing) i one będą opisane w następnym wpisie ,a na razie trochę wstępu.