Na dzisiaj wzorzec prosty i przyjemny: State(Stan). Jak sama nazwa wskazuje służy on do radzenia sobie z wszelkimi sytuacjami, gdzie występują pewne stany, od których zależy to, co zostanie wykonane w ramach operacji. Weźmy pod uwagę przykład znany wszystkim(aczkolwiek rozpaczliwie uproszczony): winda, a konkretnie jej drzwi.

Dzisiaj kilka słów na temat wzorca Flyweight – “waga piórkowa”. Wzorzec ten należy do grupy wzorców strukturalnych. Flyweight zajmuje się udostępnianiem pojedynczego obiektu wielu klientom. Wspólny dostęp znajduje zastosowanie gdy występuje potrzeba zarządzania dużą ilością obiektów(setki, tysiące, itp), które posiadają jakąś niezmienną część. Dość prymitywnym przykładem może być proces tworzenia oferty sprzętu: zamiast do każdego długiego opisu powiedzmy procesora, wraz z wszystkimi danymi technicznymi,...

W jaki sposób pokonać ograniczenia standardowego protokołu inwentarza usług, nie łamiąc przy tym zgodności ze standardami? Wzorzec Canonical Protocol zaleca wykorzystania jednego, standardowego, protokołu do komunikacji między usługami w ramach jednego inwentarza. Domyślnie oczywiście, protokołem tym są jakiegoś rodzaju usługi webowe (Basic WS, WS-*, REST), jednak nie jest to twarde wymaganie. Niezależnie od wyboru standardowego protokołu, mogą zdarzyć się sytuacje, kiedy jest on z jakichś przyczyn ni...

W jaki sposób infrastruktura przechowująca stan usług może być skalowana i zabezpieczona przed awarią? Odpowiedzią na to pytania jest wzorzec Service Grid. Jego nazwa może być nieco myląca. Nie ma on bowiem nic wspólnego z gridami oraz raczej niewiele z usługami w klasycznym pojęciu SOA. Service Grid jest nazwą dla podejścia, w którym wiele instancji infrastruktury przechowującej stan usług jest równolegle aktywnych (zwykle na wilu fizycznych maszynach). Instancje te współdzielą między sobą informacje d...

Jest to wzorzec z grupy porządkujących logiczny warstwy inwentarza (?) [inventory] usług. Pozostałe dwa z tej grupy to Entity Abstraction i Process Abstraction. Wszystkie trzy wzorce pomagają zidentyfikować różne grupy odpowiedzialności w "kandydatach na usługi". Skutkuje to wydzieleniem współnych zakresów odpowiedzialności do nowych usług lub łączeniem usług odpowiadających za ten sam aspekt rozwiązania. Utility Abstraction zajmuje się konkretnie funkcjonalnością wykorzystywaną we wszystkich fragm...

To właściwie dwa wzorce: Capability Composition oraz Capability Recomposition. Pierwszy z nich rozwiązuje problem usługi, która w celu wykonania swojego zadania potrzebueje logiki, która nie mieści się w jej zakresie odpowiedzialności. Aby problem rozwiązać, można poszerzyć zakres odpowiedzialności usługi, jednak prowadzi to do duplikacji logiki. Innym, lepszym i poprawnym, rozwiązaniem jest włączenie wywołania innej usługi jako elementu realizacji logiki tej pierwszej. Właściwie wydaje się to zup...

Dżemik z egzotycznych owoców - Abstract Factory :) Zgodnie z zapowiedzią prezentuję własną interpretację jednego z zadań kończącego rozdział książki p.t. „C# 3.0 Design Patterns.”. Rozdział ten dotyczył wzorca projektowego „Abstract Factory”. Krótko o tworzeniu własnych typów generycznych w C# Zadanie, opis wzorca Implementujemy, produkujemy (jemy i sprzedajem ;))