Kategoria: Wzorce Projektowe

MemoryCzęść NR.12 Komputery są dobre w zapamiętywaniu rzeczy. Gdy patrzysz na jakąś aplikację biznesową to zapewne nie jesteś zafascynowany tym, co ona może wyliczyć, ale co ona może zapamiętać. To główny cel naszych aplikacji wyświetlić wcześniej zapamiętane dane. 

Gdzie te dane są? W plikach, w bazach danych? 

Witaj w kolejnym wpisie z kursu programowania funkcyjnego w C#?

To niesamowite jak długo prowadzę ten cykl. 

W programowaniu funkcjonalnym koncentruję się na wykonywaniu samych funkcji niż na przetrzymywania stanów pośrednich. Funkcje w programowaniu funkcyjnym mają być czystymi funkcjami.

Funkcyjne programowanie polega na uniknięciu ukrytych wejść i wyjść jak:

• Używanie Wyjątków, aby kontrolować przepływ programu
• Funkcja nie modyfikuje stanu
• Funkcja nie trzyma referencji do obiektu, który miałby być zmieniony
• Funkcja nie zapisuje czegokolwiek w polach statycznych

Z drugiej strony pamiętanie stanów jest częścią aplikacji. Zawsze gdzieś będzie warstwa dostępu do danych. 

Mamy jednak kolejne ciekawe założenie programowania funkcyjnego. Zakłada ona, że raz wyliczona nie powinna zostać wyliczana ponownie. Możemy też założyć, że raz pobrana rzecz z bazy danych nie powinna być także odczytana ponownie do jakiegoś limitu czasu.

Czyli mówimy o Cache w naszej aplikacji o możliwości pamiętania tego, co już zrobiliśmy wcześniej, aby nie robić czegoś ponownie z takim samym rezultatem.

Mamy dwa style zapamiętywania rzeczy i omówimy je w tym wpisie.

Onion Napisać aplikację to jedno. Wdrożyć to drugie. Tylko jak później tę aplikację utrzymać i ciągle zmieniać?  Dodawać nowe funkcje, poprawiać błędy, zmieniać istniejącą logikę biznesową.

Można by powiedzieć, że to jest największa zmora programowania. W końcu każdemu zdarzyło się chociaż raz powiedzieć lub pomyśleć

"Ta aplikacja to takie gówno, że szybciej bym napisał lepszą od zera".

Czasami jak czas i pieniądze pozwolą, tak się dzieje. Piszemy aplikację drugi raz, bo poprzednia wersja jest Behemotem.

Mediator Ostatnio zrobiłem webinar na temat budowania aplikacji w C# od zera. Skoncentrowałem się na dobrych praktykach oraz na najlepszych paczkach NuGet, które obecnie są w ofercie dla C# i dla .NET. 

MediatR na pewno jest w pierwszej piątce najlepszy paczek Nuget.

MediatR pomaga Ci szybko napisać aplikację przy pomocy wzorca projektowego mediator oraz zastosować CQRS. 

FactoryWzór.15 Cześć witaj ponownie we wpisie na temat wzorów projektowych. Oprócz opisywania znanych wzorców projektowych chce także dać swoje 5 groszy i wyjaśnić, że nawet książkowe wzorce projektowe we współczesnym świecie mają lepsze alternatywy.

Dziś spojrzymy na wzorzec projektowy Fabryki.

Po co na fabryka, która ma wypluwać określone instancję obiektów.

Spójrz na ten przykład.

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:

• Current : referuję się do obecnego obiektu w tej pozycji
• MoveNext() : pozwala Ci przesunąć się do elementu następnego w tej kolekcji. Jeżeli operacja się powiodła otrzymujemy wartość true, jeśli nie to false
• Reset() resetuje do pozycji startowej

MachineWzór.14 W poprzednim wpisie omówiliśmy wzorzec projektowy stan. Wracamy do niego i przy okazji omówimy działania maszyny stanów. Poprzednim razie stworzyliśmy prymitywna maszynę stanów telefonu.

Pytanie, jak to można zrobić korzystając z gotowych rozwiązań jak np. z paczki statless

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:

• Stany są klasami z zachowaniami i te zachowania powodują zmianę z jednego stanu na drugi
• Stany i przejścia są typami wyliczeniowymi. Mam specjalny oddzielny komponent, który wykonuje te przemianę stanu.

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

IObservableWzór.12 Mówiąc o wzorcu projektowym Observer warto także wspomnieć o tym, że w najnowszym .NET-cię mamy dwa ciekawe interfejsy generyczne : IObserver<T> i IObservable<T>. Te dwa interfejsy miały swoją premierę z biblioteką Reactive Extensions (Rx)

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

• Stefan
• Jarek
• Bajek

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 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.

NullWzór.5 W pewnym wpisie omówiłem, że niektórzy architekci nie lubią wartość NULL, która występuję we wszystkich typach referencyjnych. Co, jeśli chciałbyś się tego pozbyć i zapomnieć o tym, jak C# 8 próbuje rozwiązać ten problem

No cóż, wtedy korzystasz ze wzoru projektowego Null Object

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.

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:

• 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 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.

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