Dzisiejszy post będzie o moim własnonożnie zrobionym kontenerze IOC (inversion of control). Najpierw kilka słów, czym jest wzorzec IOC.

W wielkim uproszczeniu wzorzec IOC polega na przeniesieniu poza obiekt wszelkich funkcjonalności nie związanych bezpośrednio z jego przeznaczeniem. Celem jest:

• zdefiniowanie jasnych odpowiedzialności poszczególnych klas
• stworzeniem abstrakcji dzięki której zmiana jednego elementu systemu nie będzie wpływała na inne
• uniezależnienie się od implementacji poszczególnych części systemu

Tyle do IOC, natomiast kontener IOC jest specjalną klasą, która na nasz zlecenie konstruuje za nas obiekty, których potrzebujemy dbając o wszelkie zależności między nimi.

Realizacja wygląda w ten sposób, że deklaratywnie określamy jakie są zależności między obiektami i na podstawie naszego opisu całą techniczną stroną tworzenia obiektów zajmuje się kontener IOC.

Kontener wraz z przykładem użycia można ściągnąć z tąd (licencja BSD).

Mój kontener IOC składa się z dwóch podstawowych częsci:

• fabryka obiektów
• adaptery dla różnych formatów określania zależności między obiektami

Fabryka obiektów tworzy i zarządza obiektami biorąc pod uwagę czas ich istnienia. Zarządza obiektami, których stan trzymany jest przez całą sesję użytkownika jak i może ich stan być trzymany nieskończenie długo i dostępny między sesjami użytkowników ( do tego potrzebny jest mechanizm cache typu APC lub XCache z odpowiednim adapterem).

Co do adapterów to na dziś dzień stworzony jest jeden adapter, który czyta XML-e. Pokrótce o tym jak opisywać obiekty w tymże XML-u.

<object-config>
    <application>
        <!-- For now empty, objects declared here will be cached by APC or something similiar -->
    </application>
    <session>
        <object class="FooFoo">
            <property name="someParameter">baz_foo</property>
        </object>
    </session>
    <request>      
        <object class="Foo1">
            <property name="param2">other_baz</property>
            <property name="param1">baz</property>
        </object>
 
        <object class="Foo2">
            <property name="param2">baz_faz</property>
            <property name="param1">baz_baz</property>
        </object>
 
        <object class-match="/Foo[0-9]+/">
            <property name="param3" type="class">@self</property>
        </object>
 
        <object class="Bar" id="FooBar">
            <property type="class" name="param1">Foo1</property>
            <property type="const" name="param2">FooConst</property>
            <property type="id" name="param3">Foo2</property>
            <proxy class="FooProxy"/>
        </object>
 
    </request>    
</object-config>

Jak widać albo i nie . Stopień niżej od roota są trzy tagi – “application”, “session”, “request”, które grupują w sobie tagi object. Te trzy tagi określają czy stan obiektu będzie trwał dla sesji czy dla pojedynczego requestu czy wiecznie dla całej aplikacji.

Tagi object określają konfigurację poszczególnych obiektów. Kolejne właściwości obiektu ustawiamy za pomocą tagów “property”. Obowiązkowym atrybutem tagu “property” jest “name”, mówi on o nazwie parametru w konstruktorze lub nazwie settera przez który ma być wstrzyknięta właściwość obiektu. Dzięki temu rozwiązaniu, nie ma znaczenia w jakiej kolejności podamy właściwości, zawsze zostaną one właściwie wstrzyknięte.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Dziś zakończył się PHPCon 2010 Poland - pierwsza polska konferencja poświęcona językowi PHP organizowana przez Polską Grupę Użytkowników Linuksa. Planeta php.pl prawdopodobnie niebawem zapełni się pewnie jeszcze sporą ilością relacji, ale nic dziwnego. Do tej pory zloty PHP praktycznie nie istniały; wszyscy jechali tam, zadając sobie pytanie, jak to wypadnie. Czy wypadło dobrze? Zapraszam do krótkiej minirelacji.

W marcu w Lookr.tv ukazał się dwuczęściowy filmik przedstawiający nową wersję Filmweb.pl. Z mniej więcej miesięcznym poślizgiem szeroka publiczność może go używać. Na pierwszy rzut oka widać, że z pierwowzorem serwis łączy tylko nazwa (i baza filmów / użytkowników). Wygląd Gradient tu, gradient tam, wszędzie gradient! Ogólnie nie narzekam. Wolę strony jasne z ciemnym tekstem [...]

Poniższy tutorial będzie wprowadzeniem do epizodu tutoriali o języku skryptowym (proceduralnym) PL/pgSQL. Język pl/sql został wymyślony przez Oracle, jego prostota i zarazem potężna siła daje nam wszystko czego potrzeba nam do pracy z postgresql. Język ten pozwala nam na wiele więcej działań niż sam SQL, począwszy od deklaracji zmiennych poprzez pętle skończywszy na triggerach (albo i nie).

Wprowadzenie do PL/pgSQL

Krótki i w miarę logicznie opisanym słowem wstępu jest artykuł na wiki o PL/pgSQL, link poniżej. Lecz ja chciałbym to omówić po swojemu, tak by każdy z Was to zrozumiał i przekonał się nad wielkością tego języka, zaczynajmy. Tak jak nam mówi manual składnia funkcji jest następująca:

CREATE FUNCTION "nazwaFunkcji"( argumenty [, ... ] ) RETURNS [typZwracanegoObiektu] AS $BODY$
  DECLARE -- blok nie obowiązkowy
    -- Możemy w tym bloku definiować zmienne, w "locie" zmiennych definiować nie możemy 
  BEGIN
    -- ciało funkcji
 
    RETURN [zwracanyObiekt] -- klauzula prawie nie obowiązkowa, o tym poniżej
  END;
$BODY$ LANGUAGE 'plpgsql';

Tak mniej więcej przedstawia się schemat konstrukcji funkcji w PL/pgSQL, Pominąłem kwestię bloków w bloku, w sensie że w bloku BEGIN … END możemy zdefiniować kolejny blok kodu. Nigdy mi to nie było jeszcze potrzebne, i wątpię by Wam było, to jest pewnego rodzaju przerost formy nad treścią. Jak widać stosuje tutaj podwójne dolary w sensie $BODY$, można się zapytać dlaczego? Otóż nie musicie stosować podwójnych dolarów zamiast nich możecie zrobić po prostu AS ‘ — i tutaj reszta kodu. Tylko nie wiem czy stać Was na nerwy stracone przy escepowaniu znaków. Otóż przy podwójnych dolarach możemy zachować taką konstrukcję:

SELECT * FROM users WHERE f_name='foobar';

Natomiast przy konstrucji z apostrofem:

SELECT * FROM users WHERE f_name=''foobar'';

Tam nie ma cudzysłowu przy foobar tylko podwójny apostrof. Także używajcie sobie czego chcecie, do woli. A i jeszcze jedno, to co sobie wstawicie pomiędzy podwójne dolarki nie ma znaczenia, ja wyniosłem z pracy nawyk wstawiania tam nazwy funkcji, co mi się osobiście trochę mało podoba, no ale nawyk pozostał. Przedstawiona przeze mnie powyżej konstrukcja nie jest oczywiście odzwierciedleniem tej z manuala, gdyż jest mało jasna, i rzadko się używa np CREATE OR REPLACE gdy co chwilę zmieniamy typy zmiennych przesyłanych w liście argumentów.

Argumenty funkcji PL/pgSQL

Lista argumentów może być podawana dwojako, a nawet trzyjako. Pierwszym z sposobów podawania argumentów do funkcji jest:

CREAT.... "nazwaFunkcji" ( INT, NUMERIC, TEXT, VARCHAR ) .... $BODY$
  DECLARE
    "_nazwaZmiennejInt" ALIAS FOR $1;
    "_nazwaZmiennejNumeric" ALIAS FOR $2;
    "_nazwaZmiennejText" ALIAS FOR $3;
    "_nazwaZmiennejVarchar" ALIAS FOR $4;
  BEGIN
   ....

drugi sposób:

CREAT.... "nazwaFunkcji" ( "_nazwaZmiennejInt" INT, "_nazwaZmiennejNumeric" NUMERIC,  "_nazwaZmiennejText" TEXT, "_nazwaZmiennejVarchar" VARCHAR ) .... $BODY$

trzeci sposób:

CREAT.... "nazwaFunkcji" ( "_nazwaZmiennejInt" INT, OUT "_nazwZwracanejZmiennej" INT, OUT "_nazwaZwracanejZmiennej2" INT ) .... $BODY$

Dzięki tej trzeciej metodzie możemy zwracać więcej niż jeden argument. Możemy też definiować typy zmiennych i też je zwracać o tym zraz.

Zwracane typy

Tak jak wyżej napisałem funkcje PostgreSQL mogą zwracać typy danych które też sami zdefiniujemy, metody mogą zwracać zarówno typ VOID, jeżeli nie potrzebujemy niczego zwrócić to po prostu ustawiamy RETURNS VOID i dzięki takiej konstrukcji klauzula RETURN w ciele kodu jest niewymagana, proste nie? PostgreSQL to nie PHP, źle mu prześlesz typ danych zdefiniowany jako INT a prześlesz jako ‘1′ i będzie to string, w PHP to przejdzie ale w postgre nie. Więc tutaj musimy się pilnować jeżeli chodzi o przesyłanie zmiennych. To samo tyczy się wszystkich typów oraz tych zwracanych, jeżeli w końcowej wersji uzyskamy inny typ niż ten który zdefiniowaliśmy to dostaniemy błędem po oczach próbując przypisać np NUMERIC do INT i w sumie funkcja się nie wykona, nic nie zwróci a weź to debuguj :>

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Pewnego razu gdy medytowałem nad sensem świata, pewna ciekawa rzecz zaprzątnęła moim umysłem. Pytanie co było pierwsze – funkcja czy klasa ? Pytanie, co jest bardziej pierwotnym pojęciem w programowaniu?

Nie ma to może żadnych poważniejszych implikacji dla nas koderów, jednak można dojść do całkiem ciekawych wniosków. Odpowiedzią na pytanie zadane w tytule jest: pierwszy był… void .

A tak już całkiem na serio. W matematyce, w algebrze zbiorów najszerszym pojęciem jest klasa, jest ona bytem szerszym od zbioru. Klasa agreguje różne zbiory.

W programowaniu, klasa ma podobne znaczenie, jest czymś co określa pewien rodzaj obiektów. I tu właśnie zaczynają się schody, bo jak wiemy w klasie są metody, czyli funkcje. Więc jak to jest ? Czy może istnieć klasa która składa się z funkcji ? A może, istnieje sobie np. klasa funkcji kwadratowych, czyli wszystkich funkcji w postaci Ax2+bx+c czy klasa funkcji ekspotencjalnych. Co ciekawe np. w języku php da się stworzyć takie klasy:

class SquareFunction {
 
    protected $_a = 1;
 
    protected $_b = 1;
 
    protected $_c = 1;
 
    public function __construct($a,$b,$c){
 
        $this->_a = $a;
 
        $this->_b = $b;
 
        $this->_c = $c;
 
    }
 
    public function __invoke($x){
 
        return $this->_a*pow($x,2) + $this->_b*$x + $this->_c;
 
    }
 
}
 
$func = new SquareFunction(5,6,4);
 
echo $func(10);

Oczywiście jest tu trochę php-owej magii związanej z funkcją __invoke(dostępna od 5.3), dzięki której można wywoływać klasę jako funkcję. Nie mniej jednak logicznie rzecz biorąc jest to podejście słuszne.

Wracając jednak do pytania podstawowego co było pierwsze. Doszedłem do wniosku przemyśliwując sprawę gruntownie, że oba pojęcia są pojęciami pierwotnymi. Nie da się zdefiniować klasy bez funkcji i funkcji bez klasy. Tak jak nie da się podzielić elektronu na pół, ponieważ jest cząstką punktową, a jak wiemy matematyczny punkt jest niepodzielny.

Przypomina mi cała sprawa rzecz wziętą z fizyki, mianowicie dualizm korpuskularno falowy, funkcja jest jednocześnie funkcją i klasą.Z istniejących języków programowania najlepiej oddaje ten dualizm Javascript, gdzie funkcja jednocześnie jest klasą i powiem szczerze, że po tych przemyśleniach okazuje się, że jednak JS ma jakiś głębszy sens

Dziś stała się rzecz, na którą dużo osób czekało. Do trunk-a PHP został commitowany patch umożliwiający typowanie argumentów dla nie obiektów w funkcjach.

Od teraz możliwe jest to:

function foo(int $bar){
    return $bar + 5;
}

Z tego co pamiętam, typować argumenty można silnie i słabo, tzn: jeżeli w liście argumentów podamy int to wtedy funkcja zaakceptuje tylko argument o typie int. Jeżeli jednak zdeklarujemy to jako (int) to wtedy wszystko co się da rzutować na int-a przejdzie.

Feature zapewne znajdzie się w wersji 5.4 interpretera.

Piekło zamarzło! Wczoraj na blogu Ilia Alshanetsky pojawił się wpis zatytułowany Scalar Type Hints are Here!. Wynika z niego, że do SVN-a dodana została długo oczekiwana funkcjonalność dająca możliwość określenia typu argumentu przekazywanego do funkcji. Oprócz array oraz nazwy klasy, można stosować typy proste jak int, czy string. W praktyce będzie to wyglądać następująco:

function(int $i)
{
    // jakieś operacje na zmiennej $i
}

Niestety muszę ostudzić wasz entuzjazm. Modyfikacja ta nie jest jeszcze wprowadzona do oficjalnego wydania języka. Poza tym zanim trafi ona pod nasze strzechy, trochę czasu minie. Nie pamiętam, bym widział hosting z najnowszą wersją PHP.

Z podobnych funkcjonalności brakuje mi jeszcze możliwości określenia typu zwracanego przez funkcję. Może niedługo się pojawi?