Kilka dni temu zainicjowałem cykl postów związanych z wielowątkowością. Rozpocząłem dość standardowo, bo od wyjaśnienia istoty tego zagadnienia i przedstawienia prostych wątków. Wiedza zawarta w tamtym wpisie, powinna w wielu przypadkach okazać się wystarczająca - szczególnie jeśli w naszej aplikacji mamy tylko jeden wątek dodatkowy, który stworzony jest tylko po to by odciążyć wątek główny. Takie proste rozwiązanie nie będzie jednak zawsze do końca wystarczające. Problemy pojawią się w sytuacji gdy wąt...

Nie wiem jak Was, ale mnie osobiście irytuje zdarzenie w którym na górnej belce aplikacji pojawia się napis , a sam program wygląda jakby się gdzieś po drodze pogubił... Generalnie taki stan rzeczy może być spowodowany wieloma różnymi aspektami, choć zasadniczo w tym przypadku najczęściej można wskazać dwie przyczyny. Trzeba niestety tu otwarcie przyznać, że w głównej mierze są one spowodowane źle napisanym kodem przez programistów tychże aplikacji. Po pierwsze, w każdym programie może po prostu pójść c...

Jestem zafascynowany framworkiem PRISM, czytam, oglądam i piszę jakieś przykładowe aplikacje z wykorzystaniem tej biblioteki. Prism ułatwia tworzenia modularnych i dynamicznych systemów, dostarcza mechanizm do rozwiązywania zależności (Unity Container), umożliwia dynamiczną zmianę zachowania aplikacji poprzez wczytywanie dodatkowych modułów z katalogu lub aktualizację pliku konfiguracyjnego aplikacji - to tylko część z błyszczących bajerów. Prism wspiera Silverlight, WPF czy Windows Phone 7 oraz mocno ...

Zasada Common Reuse Principle mówi, że klasy w pakiecie/assembly są ponownie używane wspólnie. Jest to konsekwencja Reuse Release Equivalence Principle z której wynika, że klient posiada referencje do całej biblioteki a nie pojedynczej klasy. Z tego zaś wynika, że jeżeli polega na jednej klasie (wykorzystuje jedną klasę)  to może wykorzystywać wszystkie. W końcu publikując bibliotekę nie jesteśmy wstanie określić z których klas będzie ktoś używał (chyba że umieścimy tam jedną publiczną klasę ). To wsz...

W poprzednich częściach przeszliśmy przez zasady SOLID. S – Single Responsibility Principle (oraz cz. 2) O – Open Close Principle (oraz cz. 2) L – Liskov Substitution Principle I – Inversion Segregation Principle D – Dependency Inversion Principle Słowo SOLID bardzo dobrze odzwierciedla to, do czego te zasady prowadzą czyli do budowania solidnego kodu. Przez solidny kod rozumiem taki, który jest łatwy w modyfikacji i który szybko można dostosować do zmieniających się wymagań. Nie są to jednak wszy...

Postanowiłem poruszyć kwestię zasady oddzielania poleceń od zapytań. Pisał o niej ostatnio Piotr Zieliński. Cóż to takiego te „polecenia” i „zapytania”? Ujmując to zagadnienie bardzo ogólnie można powiedzieć, że cechy charakteryzujące klasę dzielą się na polecenia i zapytania. Pierwsze z nich służą do modyfikowania obiektu, drugie do uzyskiwania o nim informacji...

Posted by slanto on Zastosowanie wzorca Decorator na przykładzie produktu i ofert specjalnych. Wzorzec ten pozwala nam na dynamiczną zmianę/rozszerzanie zachowania istniejących klas.

Jestem fanem interfejsów jak to wcześniej już pisałem, zatem dzisiaj będzie temat łatwy i przyjemny o interfejsach właśnie. W sam raz na ciężki po długo weekendowy poniedziałek. Interface Segregation Principle mówi, że klient nie powinien być zmuszany do implementowania interfejsów, których nie używa. Z tego wynika, że interfejs powinien być minimalistyczny lub po prostu możliwie chudy. Idealnie by było, gdyby miał jedną metodę a poważnie, można by tutaj parafrazować Single Responsibility Principle i p...

To jest mój pierwszy post, ale od czegoś trzeba zacząć. Wybacz więc niedociągnięcia :). Na pierwszy temat rzucam porównanie wydajności kilku bibliotek (framework'ów) do wstrzykiwania zależności (Dependency Injection), które jest częścią paradygmatu odwróconego sterowania (Inversion of Control) - więcej można przeczytać tutaj. Ostatnio przeczytałem, że znaczna większość programistów korzysta z tych dobrodziejstw. Niby dobrze, o ile wiemy z czym mamy do czynienia. Część bibliotek jest przeładowana ...

Zasada odwracania zależności głosi, że moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Obie grupy modułów powinny zależeć od abstrakcji. Innymi słowy abstrakcje nie powinny zależeć od szczegółowych rozwiązań, to one (rozwiązania) powinny zależeć od abstrakcji. Użyte w treści reguły pojęcie abstrakcji należy interpretować jako klasę abstrakcyjną lub interfejs. Jak widać pozostaje tutaj swoboda wyboru jednego z tych dwóch bytów...