Tree Co prawda kiedyś dawno temu (w 2011 roku) zrobiłem wpis z implementacją drzewa binarnego. Znając jednak siebie z 2011 roku nie zaszkodzi zrobić takie szybkie przypomnieje i użyć wzorca iterator.
Zaczynamy od tworzenia gałęzi i liści drzewa binarnego. Każda gałąź ma wartość i może, ale nie musi mieć następne gałęzi.
W konstruktorze przekazuje dalsze instancje tej samej klasy. Co oznacza, że możemy stworzyć prawdziwy łańcuch łączący te klasy, a raczej drzewo.
By Properties Iterator mówiąc krótko jest to obiekt, który przemieszcza się po strukturze obiektu. Iterator zazwyczaj ma referencję do obecnego obiektu, do którego ma dostęp i posiada także metodę by przejść do następnego elementu.
Mam także iteracje dwukierunkowe, które pozwalają ci także iść w przeciwną stronę.
W .NET mam już sposób na implementację tego wzorca . Jest nim interfejs IEnumerator<T> . Posiada on następujące metody:
MachnineWzór.13 Nasze zachowanie jest sterowane przez nasz stan. Jeżeli nie wyspałeś się dobrze to twoje zachowanie zapewne się zmieni. Jeżeli wypiłeś dużo alkoholu to nie będziesz prowadził samochodu. Stany więc decydują o tym co możesz i czego nie możesz zrobić.
Możesz oczywiście przejść z jednego stanu w drugi. Energetyk/Kawa może być takim wyzwalaczem, który zmienia twój stan. Poranne ćwiczenia mogę Cię też bardziej rozbudzić.
Wzorzec projektowy State jest bardzo prosty. Stan kontroluje zachowania, a sam stan może zostać zmieniony. Jak jednak ten stan zobrazować. Możemy to zrobić na dwa sposoby:
Oba te rozwiązania są właściwe. Drugi jest najbardziej popularny i kto wie być może już go użyłeś w swojej pracy. Pierwszy wymaga stworzenia wielu klas więc wydaje się on bardziej skomplikowany. Zauważ, że o ile wzorce projektowe mogą wydawać się cool czasami wygrywa rozwiązanie, które jest bardziej przejrzyste niż bardziej złożone. W końcu inni programiści muszą zrozumieć co chciałeś osiągnąć w kodzie
IObservable
Ich celem było obsłużyć strumień reaktywnych informacji.
Zobaczmy co interfejs IObservable<T> w ogóle robi. Jaki jest on mechanizm? Do podpinania się do zdarzeń używamy operatora += . W tym interfejsie będziemy używać metody Subscribe() . Ta metoda bierze za parametr tylko interfejs IObserver<T>
Wszystko to jest interfejsem więc w przeciwieństwie do delegat i zdarzeń nie mamy tutaj określonego mechanizmu działania. Możemy z tymi interfejsami zrobić co chcemy
A co z odpinanie się od obserwacji, czyli od subskrypcją. Idea ta jest wpierana przez interfejsy Metoda Subscribe() zwraca obiekt interfejsu IDisposable. Będzie to token, który metodę Dispose() odłączy się obserwacji obiektu observable.
EventWzór.11 Wzorzec projektowy Obserwator polega na tym,że jeden komponent informuje drugi, że coś się wydarzyło. Ten wzorzec jest używany wszędzie. W aplikacjach WPF i Windows Forms, jak i ASP.NET Web Forms i wszelkiej formie UI w platformie .NET mamy system zdarzeniowy. Ten system do program wysyła obiekty określający jakie zmiany zaszły przy interakcji z użytkownikiem.
Wzorzec Obserwator jest popularny i potrzebnym wzorcem w wielu miejscach w aplikacji nawet bez twojego kodu. Nic dziwnego, że twórcy C# postanowili zaszyć ten wzorzec do języka w postaci słowa kluczowego event
TemplateWzór.10 Wzorzec projektowy Strategy i Template Method są podobne do siebie. Jakie jednak są różnice . Wzorzec projektowy Strategy używa interfejsów i kompozycji do określenia zachowania algorytmu.
Natomiast Template Method używa dziedziczenia . Klasa ustala szkielet algorytmu i jego kolejności natomiast implementacja poszczególnych kroków jest w zupełnie innym miejscu. Tym zajmą się klasy, które będą dziedziczyć po tej klasie szablonu
Istnieje mnóstwo przykładów tego wzorca. Często jest on reprezentowany przez artykuły jedzenia. Przykładowo masz tutaj szablon robienia naleśnika.
How to?Wzór.9 Mam więc listę napisów (Stefan,Jarek,Bajek) i chciałbyś je wyświetlić w specyficzny sposób. Możesz to zrobić po przecinku : (Stefan,Jarek,Bajek).
A może wyświetlić je po kropce : (Stefan.Jarek.Bajek)
A może wyświetlić je korzystają z elementu <ul><li> w HTML
Każdy z tych formatów wymaga swojej logiki przetłumaczenia listy napisów na odpowiedni wynik.
Można by powiedzieć, że strategii.
Co, jeśli bym chciał wybierać tę strategię w trakcie działania programu? Zobaczmy jak wzorzec projektowy strategi działa.
SaveStateWzór.8 Używając wzorca projektowego Command, zapisywaliśmy akcje, które wykonywaliśmy w systemie i dzięki temu mogliśmy później te akcje cofać.
Istnieje wzorzec projektowy, który też spełnia tę funkcję. Wzorzec Memento przechowuje stan systemu w dedykowanym obiekcie tylko do odczytu.
Ten token będzie użyty do przywrócenia systemu
ConnectingWzór.7 Większa część kodu, który piszemy, ma różne komponenty (klasy), które gadają ze sobą poprzez bezpośrednią referencję. Jednakże zdarzają sytuację, w których chciałbyś ,aby obiekty nie były świadome swojej egzystencji.
Może chciałbyś, aby obiekty były świadome siebie, ale nie chcesz przekazywać za każdym razem referencyjni do nich
W końcu za każdym razem, gdy wysyłasz referencje obiektu, to przedłużasz jego życie w pamięci.
Mediator jest wzorce projektowym, który ma ułatwić komunikację pomiędzy obiektami, które fachowo nazywam kompomentami
Mediator ma dostęp do każdego komponenty . Oznacza to, że powinien być on albo publiczny polem statycznym, albo singletonem, który jest wstrzykiwany do każdego komponentu, który go potrzebuje.
Ask meWzór.6 Powiedzmy, że chcesz przypisać wartość do zmiennej. Wystarczy do tego prosty kod jak : a = 4
Zmienna została zmieniona, jednak nie ma żadnej historii, aby zapisać, że takie zdarzenie nastąpiło. Nikt nam przecież nie może dać poprzedniej wartości tej zmiennej. Nie możemy przecież zapisać i serializować faktu o zmiany wartości. Czyż nie?
Co, jeśli chciałbyś cofnąć swoje działanie przypisania zmiennej.
No cóż, skoro nie masz historii, nie masz informacji o poprzedniej wartości to zrobienie takiej operacji jest niemożliwe
Wzorzec projektowy "Command" stawia sobie ten właśnie cel. Zamiast działać na obiektach bezpośrednio, co by było, gdybyśmy mogli wysłać, im polecenia i instrukcje co trzeba zrobić.
Klasa reprezentująca tę polecenie będzie opisem tego, co trzeba zrobić i jak.
Event BrokerWzór.4 Poprzedni przykład wzorca jest trochę sztuczny. W prawdziwym świecie będziesz chciał, aby stwory, zyskiwały lub traciły bonusy w dowolny sposób. To jest coś, czego nie zrobisz, mając listę jednokierunkową czy łańcuch zobowiązań
Nie chciałbyś permanentnie zmieniać dane swojego stwora. Chcesz, aby ta zmiana działa w tymczasowo i tylko wtedy gdy jest ona potrzebna.
Potrzebny nam będzie scentralizowany komponent. Będzie on trzymał listę wszystkich modyfikatorów dostępnych w grze. Będziemy wyszukiwać te modyfikatory i dodawać je do stworów mając pewność, że wszystko odbywa się w dobrej kolejności.
Ten komponent nazywa się Event Broker. Co ciekawe jest on połączeniem kilku wzorców projektów jak Mediator, Observer, Command
Chain of ItemsWzór.3 Pomyśl, że pracujesz nad daną aplikacją i okazuje się, że coś zostało źle zaprogramowane. Kto jest za to odpowiedzialny? Ty? Twój szef, który dał Ci zadanie? A może analityk aplikacji? A może osoba biznesową źle zrozumiała proces, który próbujesz zaprogramować
To jest właśnie łańcuch odpowiedzialności. Dodatkowo jest to także wzorzec projektowy. Jego zadaniem jest wywołać elementy systemu jeden po drugim.
Implementacja tej filozofii wydaje się prosta. Potrzebna Ci jest lista jednokierunkowa oraz klasa abstrakcyjna, która posłuży za szablon do działania
SingletonWzór.2 Wzorzec projektowy Singleton urósł na podstawie prostego pomysłu : Co jeśli chcesz mieć instancję jednego pewnego komponentu w swojej aplikacji, bez względu na to ile razy go utworzysz przy pomocy konstruktora.
Przykładowo masz klasę, która ładuje pewne dane z bazy tylko raz w cyklu życia w aplikacji. Ta klasa jeszcze posiada tylko pola do odczytu.
Taka klasa jest dobrym kandydatem na wzorzec projektowy Singleton. Po co obciążać pamięć swojej aplikacji obiektami, które mają dokładnie te same dane.
Wzorzec projektowy Singleton można zaimplementować w C# na kilka sposobów
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:
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 zaawansowanych 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.
Przed pracą praktyczną nad kodem postanowiłem napisać kolejny wstęp do wzorców projektowych.
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 design) i one będą opisane w następnym wpisie ,a na razie trochę wstępu.
