Dekorator - zmiany bez dziedziczenia

więc chodź, pomaluj mój świat

Jak obiecałem ostatnio pora zabrać się w końcu za wzorce. Pierwszym, nad którym się odrobinę poznęcamy będzie Dekorator.

Dekorator to wzorzec należący do rodziny wzorców strukturalnych i jego głównym zadaniem jest umożliwienie rozszerzenia funkcjonalności konkretnego obiektu poprzez "dodanie" do niej czegoś od siebie, rozwinięcie jego możliwość o to, co oferuje konkretny dekorator.
Zdaję sobie sprawę, że trochę enigmatycznie może to brzmieć, ale mam nadzieję, że po przeczytaniu całego wpisu, wszystko stanie się jasne i proste :)

Ach te wzorce...

kolejny rok czas zacząć...

Zima już nas zostawiła, wszelkie śniegi, które na chwilę do nas zawitały również już się potopiły tak więc najwyższa pora rozruszać stawy i sprawdzić czy palce potrafią jeszcze pisać w takt pojawiających się w głowie słów. A że powrót do formy po tak długiej przerwie do przyjemnych nie należy, a im dużej się go odwleka, tym jest trudniejszy, to aby sobie to wszystko uprzyjemnić i ułatwić postanowiłem zacząć nowy rok od nowej serii wpisów. Tym razem pod młotek idzie temat długo przeze mnie pomijany - Wzorce Projektowe.

Na wstępie jednak zaznaczę, że w przeciwieństwie do serii o tym jak pisać obiektowo oraz o SOLID (tutaj pragnę nadmienić, że ostatnie dwa wpisy pojawią się w niedługim czasie) będzie to dość luźna seria i choć plany na kilka najbliższych wpisów już mam, to jestem otwarty na propozycje i jeżeli w zakamarkach Waszych głów czai się wzorzec, który nie daje Wam spokoju, to piszcie w komentarzach, a ja postaram się co nieco rozjaśnić (o ile oczywiście będę w stanie :).
A jeżeli brakuje Wam pomysłów to zawsze możecie ponownie sięgnąć po klasykę i zastanowić się czy nie ma tam niczego, co wymagałoby wyjaśnienia :)

Chcąc nie chcąc, na wstępie, czyli dzisiaj, musi być trochę, tak przez wszystkich kochanej, suchej teorii, czyli słów kilka o tym, czym wzorzec jest, po co i dlaczego je stosować, co daje ich znajomość oraz jak je dzielimy.

Niech Wam testy przejdą :)

Ostatnio trochę Was zaniedbałem za co serdecznie przepraszam i obiecuję, że w nadchodzącym roku postaram się nadrobić dwumiesięczny brak aktywności na blogu :) To tyle w kwestii usprawiedliwiania się, w końcu kończy się rok i nie ma co płakać nad tym, co nie wyszło w stu procentach tak jak byśmy chcieli. Natomiast tym, co wyszło dobrze albo nawet lepiej niż zakładaliśmy również trzeba przestać się zachwycać i zrobić miejsca na kolejne sukcesy :)

Dzisiaj krótko i w klimacie TDD - Niech za rok, po odpaleniu, poniższe testy Wam przejdą :)

SOLIDny kod cz. 4 - Liskov substitution principle

zacznijmy od podstaw

Zasada podstawienia Liskov brzmi:

Funkcje które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów.

Sprowadza się to do tego, że w każdym miejscu gdzie wykorzystujemy klasę bazową (rozszerzaną) lub interfejs możemy wykorzystać każdą klasę potomną i nie wpłynie to na zmianę zachowania czy też wynik działania, nie wpłynie negatywnie na działania aplikacji.

Prototype i this - wiem, że nic nie wiedziałem

Kolejna prezentacja stworzona przez Piotrka Repetowskiego i Mirka Filipa. Tym razem na temat działania prototype i this w JavaScripcie. Obejrzyjcie, bo warto:)

Człowiek nie zdaje sobie sprawy o ilu rzeczach nie wie i ile kryje się "pod maską" dopóki ktoś mu tego w jasny i klarowny sposób nie przedstawi:)

Nie mam wątpliwości, że dzięki tej prezentacji dowiecie się "kilku" interesujących (i możliwe, że przydatnych) rzeczy:)

Prezentacja do obejrzenia tutaj.

Programista - zawód niewdzięczny...

Bycie programistą nie jest proste, a im lepszym się stajesz, im więcej widzisz i wiesz, tym cięższe staje się Twoje życie. I wcale nie mam na myśli tej ciągłej konieczności bycia "na bieżąco", uczenia się nieustannie nowych języków, paradygmatów, technik, bibliotek i wszystkiego tego, co dobry programista wiedzieć powinien, aby być "wartościowym towarem" na rynku pracy.
Nie, to naprawdę nie jest problematyczne, a im trafniejszy był wybór Twojego zawodu, tym bardziej te wszystkie rzeczy Cię cieszą. Rozwój może być wycięczający i męczący, ale w gruncie rzeczy każdy z nas chce to robić i w dodatku chce to robić bez przerwy, zarówno w pracy jak i po godzinach.

Czasami szkoda czasu na najlepsze rozwiązania

Kilka dni temu rozmawiałem z członkiem mojego zespołu na temat niektórych defectów, które zgłaszamy.
Stwierdził on, że o ile zazwyczaj nie ma się nad czym rozwodzić i kłócić, to zastanawia się, czy w niektórych przypadkach nie jest to zwyczajny przerost formy nad treścią (nie cytuję, więć z góry przepraszam za wszelkie odstępstwa). O co mianowicie chodziło?
Zastanawiał się czy rzeczywiście zawsze warto inwestować czas w poprawianie kawałka kodu tak, aby był jeszcze lepszy, skoro spełnia on swoje założenia i wcale zły nie jest.

Whatever

świętymi bądźmy... ale trzeba znać umiar

Ostatnimi czasy zdarzało mi się trafiać w review kodu na zażarte dyskusje na temat pewnego jego fragmentu. Czasami rozmowy tam prowadzone zmieniały się w dialogi nie za pośrednictwem komentarzy i klawiatur, a werbalne.
Gdy się wsłuchiwałem (bądź wczytywałem) w nie, ciężko było trzymać stronę któregokolwiek z dyskutantów, a to dlatego, że moim zdaniem każdy z nich miał rację, a rozmowa sprowadzała się do kwestii estetycznych i osobistych preferencji aniżeli do "obrony jakości kodu" przed "nieodpowiednimi" linijkami.

No i tak sobie te dyskusje trwały do momentu, gdy w końcu obaj rozmówcy decydowali się na skorzystanie z "telefonu do przyjaciela", co sprowadzało się do skierowania spojrzeń w kierunku najbliższego programisty i zadania mu jakże istotnego pytania - "A Ty co o tym sądzisz?".

Zdarzało się tak, że owym programistą byłem ja. I cóż mogłem odpowiedzieć?

O tworzeniu obiektów w JavaScriptcie słów kilka...

Ciekawa prezentacja zrobiona przez moich kolegów z zespołu (Piotrka Repetowskiego i Mirka Filipa) dotycząca tworzenia obiektów w JavaScripcie i problemów, które można po drodze napotkać.

Cóż mogę napisać? Polecam i czekam na więcej (a wiem z dobrych źródeł, że owo "więcej" jest jedynie kwestią czasu:).
Co prawda jest ona w języku angielskim, ale z dużą ilością kodu, więc każdy, kto zna JS'a powinien wszystko bez większych problemów zrozumieć:)

Prezentacje znajdziecie pod tym linkiem.

Jeżeli coś jest niejasne to piszcie w komentarzach, a ja postaram się ich namówić na udzielenie odpowiedzi :)

Enumy w PHPie? Oczywiście, że się da!

Ostatnio, przeglądając jedno z reviewew mój kolega z zespołu rozpoczął rozmowę na temat naszych pseudo-enumów w aplikacji.
Nie odkryliśmy tutaj koła na nowo i nasze "klasy enumeracyjne" wyglądały tak, jak w większości frameworków, bibliotek i aplikacji, które widziałem, a które zostały napisane w PHP:

interface PseudoEnum
{

    const SUCCESS = 1;
    const FAILURE = 2;
}

Dobre rozwiązanie? No cóż, osobiście od dawna bolałem nad tym, że takie konstrukcje nie pozwalają nam na jedną z jakże istotnych funkcjonalności, które w przypadku zwykłych obiektów PHP posiada, a które są bezproblemowe w językach, gdzie coś takiego jak enum istnieje. O czym mowa? Chodzi o typowanie.

Pomimo cudownych i deskryptywnych nazw, te stałe, jakby na to nie patrzyć, w gruncie rzeczy są int'ami i w chwili, gdy któraś metoda mogła przyjąć wartość tylko i wyłącznie taką, jaka została zadeklarowana wcześniej w naszym pseudo-enumie, to musieliśmy tworzyć do tego celu specjalne metody sprawdzające.
Nie mogę powiedzieć, że było to zadowalające rozwiązanie, ale jakoś z tym żyliśmy.