definicja

Trait to struktura, która formą deklaracji w dużym stopniu przypomina definicję klasy. Spójrzmy na poniższy przykład:

trait Write {

    public function write () {

        if (isset($this->myName))
            echo $this->myName;

    }

}

Słowo kluczowe trait służy do tworzenia cechy. Wewnątrz niej można umieszczać metody i atrybuty. Jak widać na powyższym skrypcie, istnieje tylko jedna funkcja z modyfikatorem dostępu – publicznym, która wysyła na wyjście wartość zmiennej $this->myName, o ile taką zdefiniowano w klasie, która z cechy korzysta. Sposób użycia ilustruje poniższy fragment kodu:

class Duck {
    use Write;

    private $myName;

    public function __construct ($name) {

        $this->myName = $name;

    }

}

$obj = new Duck ('Donald');
echo $obj->write();

Aby klasa mogła w pełni rozkoszować się zaletami cechy Write korzystamy ze słówka kluczowego use.

przykład praktyczny

Aby lepiej zrozumieć i wyjaśnić sobie niuanse nowej funkcjonalności napiszmy parę cech, które będą implementować metody o takich samych nazwach:

trait Duck {

    public function write ($message) {

        echo 'Duck ',$message;

    }

}

trait Monkey {

    public function write ($message) {

        echo 'Monkey ',$message;

    }
}

trait Frog {

    public function write ($message) {

        echo 'Frog ',$message;

    }
}

class Animal {
    use Frog,Monkey,Duck;

}

$obj = new Animal();

Wykonanie powyższego skryptu skazane jest na porażkę, ponieważ niedozwolone jest korzystanie z wielu cech posiadających takie same nazwy metod. W taki wypadku programista jest zmuszony do wybrania konkretnej funkcji (słowo insteadof), a dla pozostałych skorzystanie z mechanizmu aliasów (słowo as):

//insteadof PRZYKLAD

class Animal {
    use Frog,Monkey,Duck {Monkey::write insteadof Frog,Duck;}

}

$obj = new Animal();
$obj->write('test');
// mozemy uzyc tylko jednej z trzech metod

// as PRZYKLAD

class Animal {
    use Frog,Monkey,Duck {
        Monkey::write insteadof Duck,Frog;
        Duck::write as writeDuck;
        Frog::write as writeFrog;
    }

}

$obj = new Animal();
$obj->writeFrog('test');
$obj->writeDuck('test');
$obj->write('test');
// mozemy skorzystac ze wszystkich trzech metod

Oczywiście nic nie stoi na przeszkodzie, by sama klasa Animal posiadała metodę write. W takiej sytuacji w pierwszej kolejności zostanie wywołana właśnie ona. Warto jeszcze wspomnieć o sposobności zmiany modyfikatora dostępu dla cechy. Prezentuje to poniższy przykład:

trait Duck {

    private function write ($message) {

        echo 'Duck ',$message;

    }

}

trait Monkey {

    private function write ($message) {

        echo 'Monkey ',$message;

    }
}

trait Frog {

    private function write ($message) {

        echo 'Frog ',$message;

    }
}

class Animal {
    use Frog,Monkey,Duck {
        Monkey::write insteadof Duck,Frog;
        Duck::write as public writeDuck;
        Frog::write as public writeFrog;
        Monkey::write as public;
    }

}

$obj = new Animal();
$obj->write('test');
$obj->writeFrog('test');
$obj->writeDuck('test');

Wypada także zapamiętać, iż nie uda się nam utworzyć obiektu cechy lub skorzystać w jej przypadku z type hinting. Zainteresowanych zachęcam do własnych eksperymentów.

• pełnomocnik ochraniający [protection proxy] – jego zadaniem jest określanie, czy obiekty chcące uzyskać dostęp do obiektu chronionego posiadają wymagane uprawnienia
• pełnomocnik zdalny [remote proxy] – jest pośrednikiem w dostępie do obiektów zdalnych
• pełnomocnik sprytnego wskaźnika (odwołania) [smart proxy] – gdy oprócz dostępu do obiektu konieczne staje się podjęcie dodatkowych akcji – czynności

Powróćmy jednak do głównego bohatera tego wpisu.

Virtual proxy

Zadaniem tego wzorca jest reprezentowanie obiektu, którego utworzenie jest kosztowne z punktu widzenia całego systemu. Virtual proxy usiłuje maksymalnie opóźnić ten proces, w międzyczasie starając się w pełni zastąpić właściwy obiekt. Kiedy jest on już dostępny, wszystkie żądania deleguje bezpośrednio do niego. Prześledźmy to na bardzo prostym przykładzie.

Zakładamy taki oto scenariusz. Na potrzeby naszej aplikacji wykonujemy skomplikowane obliczenia matematyczne. Mamy do tego dedykowaną klasę, jednak utworzenie jej instancji jest bardzo czasochłonne. Jesteśmy też w stanie część obliczeń (głównie tych prostszych) wykonać bez jej udziału. W takim wypadku użycie virtual proxy wydaje się doskonałym rozwiązaniem. Popatrzmy na poniższy fragment kodu, zwracając uwagę na zamieszczone komentarze.

// wspolny interfejs
// implementowany dla posrednika
// i klasy wlasciwej

interface Calculations
{

    public function Sum ($a,$b);
    public function Difference ($a,$b);
    public function Even ($a);

}

Gdy posiadamy już interfejs, spójrzmy jak implementuje go klasa właściwa.

// zakladamy ze utworzenie instacji
// tej klasy jest czasochlonne
// i koniecznie tylko dla metody even
class Maths implements Calculations
{

    public function Sum ($a,$b)
    {

        return $a + $b;

    }

    public function Difference ($a,$b)
    {

        return $a - $b;

    }

    public function Even ($a)
    {

        return !($a & 1);

    }

}

I jak wygląda kod pośrednika wirtualnego.

// wirtualny posrednik tworzy instancje klasy
// wlasciwej tylko po wywolaniu metody Even. Zakladamy ze
// pozostale funkcje jest w stanie obsluzyc sam.
// Oczywiscie jesli obiekt wlasciwy juz istnieje
// deleguje zadania bezposrednio do niego
class MathsVirtualProxy implements Calculations
{

    private $maths = null;

    public function Sum ($a,$b)
    {

        if ($this->maths instanceof Maths)
            return $this->maths->Sum($a,$b);
        else
            return $a + $b;

    }

    public function Difference ($a,$b)
    {

        if ($this->maths instanceof Maths)
            return $this->maths->Difference($a,$b);
        else
            return $a - $b;

    }

    public function Even ($a)
    {

        if ($this->maths === null) {
            $this->maths = new Maths();
        }
        return $this->maths->Even($a);

    }

}

Zatem dopóki nie wywołamy metody Even(), dopóty nie zostanie utworzony obiekt klasy Maths, a VirtualProxyMaths będzie się go starał zastępować. Gdy instancja zostanie stworzona, to wszelkie odwołania będą kierowane już bezpośrednio do niej.

// przyklad aby spradzic jak to wyglada w praktyce
$object = new MathsVirtualProxy();
var_dump($object->Sum(1,2));
var_dump($object);
var_dump($object->Even(1));
var_dump($object);

Proszę pamiętać, iż przykład ten jest mocno „naciągany”. Miał on bowiem na celu proste wyjaśnienie omawianego wzorca, co mam nadzieję się udało.

1. Rejestracja

Choć wydaje się to banalne, to jest to warunek konieczny. Zatem jeśli mamy już własne konto w serwisie, pomijamy ten krok. Jeśli jest inaczej, zapraszam do formularza rejestracji, który znajdziecie TUTAJ.

2. Dodanie aplikacji

Teraz musimy zgłosić nową aplikację. Po zalogowaniu się, przechodzimy na stronę deweloperów. Jeśli jesteśmy tu pierwszy raz, to konieczne staje się udzielenie jej odpowiednich uprawnień.

Krok pierwszy – nadanie uprawnień

Teraz należy kliknąć przycisk „Set Up New App”.

Krok 2 – dodawanie nowej aplikacji

W pewnych okolicznościach możemy spodziewać się poniższego monitu. Jeśli nasze konto zostanie zweryfikowane, proces będzie kontynuowany. Aby tego dokonać możemy wybrać jedną z dwóch opcji: podpięcie karty płatniczej lub podanie numeru telefonu.

Krok 3 – monit weryfikacji konta

Pozostaje nam tylko określenie nazwy aplikacji, jej języka i akceptacja regulaminu. Jeśli wszystko przebiegnie bez dodatkowych problemów, to po kliknięciu kontynuuj, zakończymy pomyślnie proces zgłaszania i rejestracji aplikacji na facebooku.

Krok 4 – podstawowe informacje o aplikacji

Naszym oczom ukaże się panel zarządzania, identyczny jak na załączonym poniżej obrazku.

Krok 5 – panel zarządzania

Po lewej stronie umieszczone zostało menu, składające się z czterech pozycji:
About – Basic Info oferuje:

• App ID – ID naszej aplikacji
• App Secret – klucz który będziemy używać w trakcie korzystania z API, nie należy go ujawniać osobom postronnym
• App Name – nazwa aplikacji
• Description – opis aplikacji
• Locale – lokalizacja
• Icon – ikona
• Logo – logo
• Contact Email – email kontaktowy, wykorzystywany przez facebooka do komunikacji z autorem
• Privacy Policy URL – adres pod którym umieszczona została polityka prywatności, pole wymagane
• Terms of Service URL – adres pod którym znajdują się warunki usługi
• User Support Email – email kontaktowy dla użytkowników aplikacji
• User Support URL – adres zawierający wsparcie dla użytkowników

About – Roles pozwala między innymi na określenie administratorów, deweloperów i testerów. Oczywiście jesteśmy w stanie wybrać ich wyłącznie z grupy naszych znajomych. W About – Advanced warto zwrócić uwagę na Sandbox Mode. Aktywowanie ów funkcji, pozwala na używanie napisanego kodu wyłącznie przez deweloperów. Z punktu widzenia bezpieczeństwa, może nas zainteresować pozycja Server Whitelist. Umożliwia ona ustalenie adresów IP, z których będą pochodzić żądania naszej aplikacji.

I teraz przechodzimy do bardzo istotnej rzeczy. Należy sobie zdać sprawę, iż aplikacje na facebooku możemy umieścić na własnej witrynie (opcja menu Web) lub „bezpośrednio” na facebooku (opcja menu On facebook), z wykorzystaniem iframe. Jeśli zdecydujemy się na pierwszą możliwość, to w ustawieniach zobowiązani jesteśmy do określenia dwóch parametrów: Site URL (to adres naszej aplikacji) i Site Domain (domena naszej aplikacji). Iframe to rozwiązanie alternatywne. Wszelkie opcje z nim związane umieszczono w On facebook – canvas settings:

• Canvas Page – to wybrany przez nas adres aplikacji na facebooku
• Canvas URL – adres pod którym umieściliśmy nasz kod (źródło dla iframe)
• Secure Canvas URL – wersja adresu po HTTPS
• IFrame Size – rozmiar do wyboru: automatyczny lub z paskiem przewijania
• Canvas Width – albo stała szerokość iframe, albo maksymalna dostępna w oparciu o rozdzielczość ekranu użytkownika
• Bookmark URL – adres dla zakładki korzystających z aplikacji (po lewej stronie w profilu użytkownika) – domyślnie ten sam co Canvas Page
• Social Discovery – włączona informuje znajomych korzystającego z aplikacji, że jej używa poprzez umieszczenie stosownej informacji na wallu.
• Tab Name – w przypadku dodania aplikacji na fanpage’u, jest to nazwa zakładki jaka się wyświetli po lewej stronie w profilu ów strony – PRZYKŁAD
• Tab URL – kliknięcie Tab name otwiera podany tutaj adres
• Secure Tab URL – kliknięcie Tab name otwiera podany tutaj adres po HTTPS
• Edit URL – adres do edycji ustawień aplikacji dla jej administratorów

Zakładka Facebook Mobile przeznaczona jest dla programistów oprogramowania na iOS i Android.

3. Piszemy prostą aplikację

Dla programistów PHP został udostępniony pakiet SDK, dzięki którego bardzo szybko i prosto jesteśmy w stanie napisać kod wykorzystujący potencjał, jaki oferuje facebook API. Możemy go znaleźć i pobrać STĄD. Oprócz niezbędnych klas, dostarcza on trywialną ilustrację jego użycia. Najwyższy czas zacząć kodować. Spójrzmy na poniższy skrypt.

// zalaczamy plik
require 'src/facebook.php';

// tworzymy instancje klasy Facebook
// podajac id appki i secret key
$facebook = new Facebook(array(
  'appId'  => 'xxxx',
  'secret' => 'xxxx',
));

// zwraca UID lub 0 w przypadku niepowodzenia
$appUser = $facebook->getUser();
var_dump($appUser);

if ($appUser) {
  try {
    // pobieramy dane o uzytkowniku appki
    $userInfo = $facebook->api('/me');
    var_dump($userInfo);
    // wyswietlamy opcje wylogowania z aplikacji
    echo 'WYLOGUJ';
  } catch (FacebookApiException $e) {
    $appUser = null;
  }
}
if (!$appUser) {
    // jeśli nie to zachecamy do zalogowania
    echo 'ZALOGUJ';
}

Wydaje się, że powyższy kod nie wymaga dodatkowych wyjaśnień. Zwróćmy jednak uwagę na najważniejsze metody klasy Facebook:

• getLoginUrl($params) – zwraca adres umożliwiający użytkownikom logowanie się poprzez facebooka
• getLogoutUrl($params) – zwraca adres umożliwiający użytkownikom wylogowanie się poprzez facebooka
• api() – jedna z najważniejszych funkcji, pozwala korzystać z API facebooka

Oczywiście proces logowania nie jest zawsze konieczny. Informacje dostępne publicznie możemy śmiało pobierać poprzez API.

4. Zwiększanie uprawnień aplikacji

Introspekcja zmiennej $userInfo pokazuje, iż posiadamy dostęp tylko do podstawowych informacji na temat danego użytkownika. Całe szczęście jesteśmy w stanie poprosić o dostęp do dodatkowych operacji i danych:

// zalaczamy plik
require 'src/facebook.php';

// tworzymy instancje klasy Facebook
// podajac id appki i secret key
$facebook = new Facebook(array(
  'appId'  => 'xxxx',
  'secret' => 'xxxx'
));

// zwraca UID lub 0 w przypadku niepowodzenia
$appUser = $facebook->getUser();

if ($appUser) {
  try {
    // pobieramy dane o uzytkowniku appki
    $userInfo = $facebook->api('/me');
    var_dump($userInfo);
    // wyswietlamy opcje wylogowania z aplikacji
    echo 'WYLOGUJ';
  } catch (FacebookApiException $e) {
    $appUser = null;
  }
}
if (!$appUser) {
    // jeśli nie to zachecamy do zalogowania
    // chcemy miec dostep do emaila i mozliwosci
    // publikacji na wallu usera
    echo 'ZALOGUJ';
}

Więcej informacji na temat permissions znajdziecie TUTAJ.

Na koniec przykład z umieszczaniem wpisu na wallu użytkownika:

// zalaczamy plik
require 'src/facebook.php';

// tworzymy instancje klasy Facebook
// podajac id appki i secret key
$facebook = new Facebook(array(
  'appId'  => 'xxxx',
  'secret' => 'xxxx'
));

// zwraca UID lub 0 w przypadku niepowodzenia
$appUser = $facebook->getUser();

if ($appUser) {
  try {
    // umieszczamy na wallu wiadomosc test
    $facebook->api('/me/feed','post',array('message'=>'test'));
    // wyswietlamy opcje wylogowania z aplikacji
    echo 'WYLOGUJ';
  } catch (FacebookApiException $e) {
    $appUser = null;
  }
}
if (!$appUser) {
    // jeśli nie to zachecamy do zalogowania
    // chcemy miec dostep do emaila i mozliwosci
    // publikacji na wallu usera
    echo 'ZALOGUJ';
}

Aby dobrze zapoznać się z API facebooka, zachęcam do przeglądnięcia dokumentacji udostępnionej pod tym adresem: DOKUMENTACJA. Oczywiście jest to tylko wstęp do zagadnienia. Obiecuję więc powrót do tego tematu w najbliższym czasie.

Jest to wzorzec strukturalny, a jego głównym zadaniem jest oddzielenie implementacji od abstrakcji.

W tym lapidarnym stwierdzeniu ukryta jest esencja i ogromna moc tego wzorca. Aby go jednak w pełni zrozumieć, najlepiej będzie posłużyć się dwoma prostymi przykładami.

Przykład pierwszy – teoretyczny

Wyobraźmy sobie następującą sytuację. Chcemy stworzyć absolutnie perfekcyjne, pod każdym możliwym względem środowisko graficzne dla systemu operacyjnego. Oczywiście na rynku jest ogromna konkurencja. Każdy ma bowiem prawo stworzyć własny, idealny produkt. W kontekście poruszanego tematu mam na myśli autorską implementację ów środowiska, udostępnianego dla systemu operacyjnego – swego rodzaju klienta. Jak wiadomo cały czas pojawiają się nowsze wersje systemu, w których często wprowadzane są mniejsze lub większe modyfikacje. Aczkolwiek zdecydowana część pozostaje bez zmian. Zastosowanie mostu pomiędzy interfejsem środowiska graficznego a rdzeniem klienta, pozwala na odseparowanie ich od siebie, co niesie za sobą sporo korzyści. Łatwo zauważyć, że zarówno abstrakcja jak i implementacja mogą być rozwijane niezależnie. Poniższy rysunek obrazuje, to co starałem się wyżej wyjaśnić.

Przykład drugi – praktyczny

Na ten moment obraz wzorca wydawać się może być nieco mglisty i mało wyraźny. Dlatego też najprościej będzie go zaprezentować, dokonując prostej implementacji. Na starcie stwórzmy sobie interfejs środowiska graficznego:

// interfejs środowiska graficznego
interface Graphics
{

    public function Draw($string);
    public function Ln();
    public function Bold($string);

}
// implementacja srodowiska firmy A
class GraphicsA implements Graphics
{

    public function Draw ($string)
    {

        echo $string;

    }

    public function Ln ()
    {

        echo '';

    }

    public function Bold ($string)
    {

        echo '',$string,'';

    }

}

// implementacja srodowiska firmy B
class GraphicsB implements Graphics
{

    public function Draw ($string)
    {

        echo '',$string,'';

    }

    public function Ln ()
    {

        echo '


';

    }

    public function Bold ($string)
    {

        echo '',$string,'';

    }

}

Teraz czas na abstrakcję:

// abstrakcja rdzenia klienta
// uzywajacego srodowiska graficznego

abstract class System
{
    // MA srodowiska graficzne
    // implementujace interfejs
    // Graphics
    private $graphic;

    public function __construct (Graphics $graphics)
    {

        $this->graphic = $graphics;

    }

    // zwykly setter dla srodowiska
    public function SetGraphics(Graphics $interface)
    {

        $this->graphic = $interface;

    }

    public function Draw ($string)
    {

        $this->graphic->Draw($string);
        $this->graphic->Ln();

    }

    public function Bold ($string)
    {

        $this->graphic->Bold($string);
        $this->graphic->Ln();

    }

}

class MySystem extends System
{

    public function DrawSystemName ()
    {

        $this->Draw(__CLASS__);

    }    

}

class YourSystem extends System
{

    public function DrawMyNameBold ($name)
    {

        $this->Bold($name);

    }

}

Oraz wykorzystanie powyższego kodu:

$system = new MySystem(new GraphicsA ());
$system->DrawSystemName();
$system->SetGraphics(new GraphicsB ());
$system->DrawSystemName();

$systemB = new YourSystem(new GraphicsA ());
$systemB->DrawMyNameBold(__FILE__);
$systemB->SetGraphics(new GraphicsB ());
$systemB->DrawMyNameBold(__FILE__);

Pragnę zwrócić uwagę na fakt, iż zmiany w interfejsie graficznym nie przełożą się na modyfikacje w klasach rzeczywistych (których może być bardzo dużo!) dziedziczących po System, pod warunkiem hermetyzacji wywołań Graphics w obrębie ów klasy.
Jak zwykle zachęcam do eksperymentów i poszerzania wiedzy w obrębie nie tylko tego, ale również innych wzorców projektowych.

Po tym krótkim wstępie, bez zbędnego owijania w bawełnę, proponuję od razu przejść do kodowania. Aby rozpocząć przygodę z API, wystarczy utworzyć instancję klasy Zend_Gdata_YouTube.

require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata_YouTube');
$youtubeApi = new Zend_Gdata_YouTube();

Od teraz możemy swobodnie korzystać z interfejsu, jaki oferuje nam Youtube – a jest on dość pokaźny. Warto jednak zauważyć, iż wywoływanie niektórych metod, może wymagać autoryzacji, o której jeszcze napiszę parę słów. Na razie skupmy swoją uwagę na czymś prostym i szybkim w implementacji.

Prosta aplikacja

Naszym celem będzie napisanie aplikacji oferującej wyszukiwanie filmików Youtube po ich ID i prezentacja danych o ich autorach. Dla osób, które lubią wizualizację w formie use case’ów zamieszczam poniższą ilustrację.

Każda aplikacja potrzebuje widoku – w tym wypadku formularza HTML. Może on wyglądać chociażby tak:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pl" lang="pl">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <title>Youtube Api</title>
    </head>
    <body>
        <form action="youtubeapp.php" method="post">
            <fieldset>
                <legend>Wyszukaj po ID</legend>
                <input type="text" name="videoID" />
                <input type="submit" value="Szukaj" />
            </fieldset>
        </form>
        <h4><?php include_once 'data.php'; ?></h4>
    </body>
</html>

Co daje nam taki rezultat:

Żywię nadzieję, iż do tej pory wszystko jest w miarę zrozumiałe. Przed nami bowiem najważniejszy element całej układanki, czyli plik zawierający logikę – data.php:

if ($_POST) {

    require_once 'Zend/Loader.php';
    Zend_Loader::loadClass('Zend_Gdata_YouTube');
    $youtubeApi = new Zend_Gdata_YouTube();

    try {

        $entryAuthor = $youtubeApi->getVideoEntry($_POST['videoID'])
                                  ->getAuthor();

        foreach ($entryAuthor as $author) {

            echo $author->GetName()
                        ->getText();

        }

    } catch (Zend_Gdata_App_HttpException $e) {

        echo $e->getMessage();

    }

}

Jak widać wykonanie aplikacji z Zend_Gdata_YouTube jest trywialne. Pamiętajmy, że na tym nie kończą się możliwości „read-only”, klasy użytej w powyższym skrypcie. Wśród wielu oferowanych przez nią metod, warto wymienić tutaj:

• getUserUploads($username) – zwraca pliki użytkownika $username
• getUserFavorites($username) – zwraca ulubione użytkownika $username
• getUserProfile($username) – zwraca profil użytkownika $username
• getTopRatedVideoFeed() – zwraca listę najwyżej ocenianych plików na Youtube
• newVideoQuery() – pozwala tworzyć zapytania do Youtube

Jeśli chcemy wykonać operację, która wymaga praw zapisu lub odczytu np. informacji prywatnych, konieczne staje się skorzystanie z procesu autoryzacji.

Autoryzacja z Youtube API

Pierwszy krok to rejestracja tutaj, w celu uzyskania klucza developer key (konieczne jest rejestracja produktu). Youtube udostępnia dwie metody autoryzacji. Pierwsza AuthSub odsyła na witrynę logowania do konta i po pomyślnym procesie przekierowuje na stronę naszej aplikacji, wraz z tokenem niezbędnym do przeprowadzania jakichkolwiek operacji wymagających uwierzytelnienia. Po szczegóły odsyłam do dokumentacji. Druga metoda na której się skupimy to ClientLogin. Używa ona bezpośrednio loginu i hasła użytkownika, co odróżnia ją od wcześniej wspomnianego AuthSub. Zobaczmy jak wygląda to w praktyce:

    require_once 'Zend/Loader.php';
    Zend_Loader::loadClass('Zend_Gdata_ClientLogin');
    Zend_Loader::loadClass('Zend_Gdata_YouTube');

    // url autoryzacji - pod ten adres idzie POST request - zostawiamy bez zmian!
    $authURL= 'https://www.google.com/accounts/ClientLogin'; 

    try {
        $httpClient = Zend_Gdata_ClientLogin::getHttpClient(
                        // login uzytkownika
                        'adres@gmail.com',
                        // haslo uzytkownika
                        'haselko',
                        // serwis
                        'youtube',
                        null,
                        // krotkiidentyfikator naszej appki (look dokum.)
                        'kroktiIdentyfikatorNaszejAppki',
                        null,
                        null,
                        $authURL,
                        Zend_Gdata_ClientLogin::CLIENTLOGIN_URI,
                        // jesli nasze konto jest polaczone z kontem google to warto
                        // podac GOOGLE w przeciwnym wypadku pomijamy ten parametr
                        'GOOGLE'
                        );

        $devKey = 'tutajDeveloperKey'; // klucz Developer Key naszego produktu
        $applicationId = 'Test123'; // nazwa produktu
        $clientId = 'Moja appka'; // nazwa appki

        $youtubeAPI = new Zend_Gdata_YouTube($httpClient, $applicationId, $clientId, $devKey);

        // przesylamy ID prywatnego wideo wiec wymaga autoryzacji.
        $entryAuthor = $youtubeAPI->getVideoEntry('videoID')
                              ->getAuthor();

          foreach ($entryAuthor as $author) {

              echo $author->GetName()
                          ->getText();

          }

    } catch (Exception $e) {

        echo $e->getMessage();

    }

To dokładnie ta sama aplikacja, którą wcześniej zakodowaliśmy, jednak tym razem będzie ona działać również dla prywatnego kontentu (oczywiście musimy mieć do niego dostęp). Na koniec zachęcam do własnych eksperymentów i poszerzania wiedzy w tym temacie, o ile będzie to Wam potrzebne.

Nie przedłużając, popatrzy na umieszczony poniżej przykład:

class Car
{

    private $year;
    private $country;
    private $owner;
    private $counter;

    public function setYear ($year)
    {

        $this->year = $year;

    }

    public function setCountry ($country)
    {

        $this->country = $country;

    }

    public function setOwner ($owner)
    {

        $this->owner = $owner;

    }

    public function setCounter ($counter)
    {

        $this->counter = $counter;

    }

}

$carObject = new Car();
$carObject->setCounter(10);
$carObject->setCountry('PL');
$carObject->setYear(1985);
$carObject->setOwner('ME');

Klasa ta posiada zestaw właściwości i odpowiednie metody do nadawania im wartości. Choć używanie ich w ten sposób jest akceptowalne, co nie znaczy, iż procesu tego nie da się uprościć. Jeśli dokonamy małej modyfikacji w implementacji Car, możemy uzyskać omawiany fluent interface:

class Car
{

    private $year;
    private $country;
    private $owner;
    private $counter;

    public function setYear ($year)
    {

        $this->year = $year;
        //zmiana
        return $this;
    }

    public function setCountry ($country)
    {

        $this->country = $country;
        //zmiana
        return $this;

    }

    public function setOwner ($owner)
    {

        $this->owner = $owner;
        //zmiana
        return $this;
    }

    public function setCounter ($counter)
    {

        $this->counter = $counter;
        //zmiana
        return $this;
    }

}

$carObject = new Car();
$carObject->setCounter(10)
          ->setCountry('PL')
          ->setYear(1985)
          ->setOwner('ME');

Już na pierwszy rzut oka zastosowanie interfejsu ma sens; upraszcza i ułatwia zrozumienie tak tworzonego kodu. Fluent interface często wykorzystywany jest przy konfiguracji obiektów, choć może mieć też inne zastosowania. Jak zwykle zachęcam do własnych eksperymentów z tym prostym wzorcem.

model przetwarzania oparty na użytkowaniu usług dostarczonych przez zewnętrzne organizacje. Funkcjonalność jest tu rozumiana jako usługa (dająca wartość dodaną użytkownikowi) oferowana przez dane oprogramowanie (oraz konieczną infrastrukturę). Oznacza to eliminację konieczności zakupu licencji czy konieczności instalowania i administracji oprogramowaniem.

Osoby zainteresowane poszerzeniem wiedzy w tej tematyce, polecam zapoznanie się z artykułem dostępnym TUTAJ.

Case study

Nasz cel to użycie S3 do przechowywania wszystkich plików przesyłanych za pomocą prostego formularza, umieszczonego na stronie www. W tym celu pierwszym krokiem jest rejestracja na stronie http://aws.amazon.com. W jej trakcie lub w czasie aktywacji usługi Simple Storage Service, wymaganym etapem będzie dodanie karty kredytowej, jako formy płatności. Wszelkie informacje można uzyskać TUTAJ – w tym dokładny opis, system opłat i FAQ. Po pomyślnej rejestracji, logujemy się na nasze konto, przechodzimy do zakładki w której uzyskamy API Key i Secret Key (Account -> Account Activity -> Security Credentials). Będą nam potrzebne w trakcie pisania skryptu.

W tym momencie mamy już wszystko, oprócz odpowiednich bibliotek PHP, których użycie pozwoli nam na szybką implementację usługi Amazonu. W poniższym przykładzie posłużę się rozwiązaniem, udostępnionym przez programistów framework’a Zend (kliknij aby pobrać pliki). Z pobranego archiwum interesuje nas katalog library/Zend.

Amazon S3

Zanim przejdziemy do kodowania, parę dość istotnych uwag o samym Simple Storage Service. Wszystkie obiekty przechowywane w S3 są gromadzone w tzw. „buckets” – a ich nazwy są unikalne w obrębie całego systemu, a nie indywidualnego konta. Każdy obiekt w chmurze posiada również zdefiniowane uprawnienia i metadane oraz ścieżkę dostępu: http[s]://[subdomena].amazonaws.com/[unikalna_nazwa_bucket]/[nazwa zasobu]. Oczywiście w nazwach mogą wystąpić tylko określone zestawy znaków. Więcej na ten temat można dowiedzieć się z dokumentacji, do której odsyłam osoby zainteresowane (link). Przejdźmy do praktyki!

Kodujemy

Na poniższym, archaicznym skrypcie zobrazowałem proces umieszczania plików bezpośrednio w chmurze. Jak widać,  procedura jest dość prosta i nie wymaga dużego nakładu pracy po stronie dewelopera.

include_once 'Zend/Service/Amazon/S3.php';

if ($_FILES && is_uploaded_file($_FILES['test']['tmp_name'])) {

    if ($data = file_get_contents($_FILES['test']['tmp_name'])) {
        // tworzymy obiekt z danymi API KEY i SECRET KEY
        $s3 = new Zend_Service_Amazon_S3('API_KEY', 'API_SECRET');
        // ustalamy permissions - kazdy moze odczytac zasob otwierajac link
        $meta = array(
            Zend_Service_Amazon_S3::S3_ACL_HEADER
            =>
            Zend_Service_Amazon_S3::S3_ACL_PUBLIC_READ
        );
        // Co wazne sciezka musi zawierac nazwe bucketu.
        // Zakladamy tez, ze jest on juz zdefiniowany przez nas,
        // a nazwa pliku nie posiada zakazanych znakow
        if ($s3->putObject('nazwa_bucketu/'.$_FILES['test']['name'], $data,$meta))
            echo 'UDALO SIE';
        else
            echo 'Nie UDALO SIE';

    }
}

I do tego formularz:

<form enctype="multipart/form-data" method="post" action="amazon.php">
<input type="file" name="test" />
<input type="submit" value="slij" />
</form>

Możliwości klasy Zend_Service_Amazon_S3 nie ograniczają się tylko do metody putObject($object,$data,$meta).
Zarządzanie bucketami:

• createBucket($name) – tworzenie nowego bucketu o nazwie $name
• cleanBucket($name) – czyszczenie bucketu $name z wszystkich obiektów
• removeBucket($name) – usuwanie bucketu $name
• getBuckets() – zwraca listę wszystkich bucketów użytkownika
• isBucketAvailable($name) – sprawdza dostępność nazwy bucketu

Zarządzanie obiektami:

• putObject($object, $data, $meta) – umieszczanie zasobu w chmurze, musi zawierać w prefiksie nazwę bucketu użytkownika.
• getObject($object) – pobranie obiektu o nazwie $object, musi zawierać w prefiksie nazwę bucketu użytkownika.
• removeObject($object) – usuwanie obiektu o nazwie $object, musi zawierać w prefiksie nazwę bucketu użytkownika.

Z pozostałymi metodami klasy Zend’a można się zapoznać, przeglądając dokumentację. Zachęcam do eksperymentów i tworzenia bardziej zaawansowanych implementacji w oparciu o cloud computing.

obserwator w życiu

Często bowiem zdarza się tak, iż chcemy na bieżąco śledzić wynik jakiegoś meczu, jednak nie mamy na to czasu lub nieszczęśliwy splot wydarzeń nam to uniemożliwia. Jeśli posiadamy telefon komórkowy jest szansa, że nasz operator oferuje usługę śledzenia jego przebiegu, a co najbardziej interesujące – strzelanych bramek. Jeśli tak, to jesteśmy uratowani. Wystarczy wysłanie odpowiedniej wiadomości sms na konkretny numer. Od tego momentu pozostaje nam tylko czekać na informacje zwrotne, o interesującym nas wydarzeniu. Oczywiście na taką subskrypcję operator nakłada odpowiednie obostrzenia. Po pierwsze każe sobie za to słono płacić, a po drugie – nic nie trwa wiecznie.

obserwator w programowaniu

Obserwator składa się z dwóch podstawowych elementów. Mowa o podmiocie, czyli obiekcie obserwowanym oraz obserwatorach, zwanych obiektami obserwującymi. Zadaniem tego pierwszego jest:

• dodanie obiektu do listy obiektów obserwujących
• usunięcie obiektu z listy obiektów obserwujących
• informowanie obiektów obserwujących o konkretnym zdarzeniu (np. zmiana stanu obiektu – podmiotu)

Oczywiście obiekty obserwujące muszą posiadać odpowiedni interfejs za pośrednictwem którego, podmiot poinformuje ich o wszelakich zmianach.

Odnosząc się do przykładu opisanego przeze mnie wyżej, za podmiot w takim ujęciu można uznać operatora komórkowego (dodaje i usuwa nas z listy użytkowników danej usługi, oraz wysyła powiadomienia dotyczące konkretnej tematyki) a obiektami obserwującymi jesteśmy my sami – dane odbieramy za pośrednictwem naszych telefonów komórkowych.

obserwator w praktyce

Wzorzec ten zbudowany jest z dwóch interfejsów. Pierwszy dotyczy podmiotu i możemy go zdefiniować w następujący sposób:

interface Subject
{

    public function AddObserver(Observer $obj);
    public function DeleteObserver(Observer $obj);
    public function SendToObservers();

}

Drugi obiektów obserwujących:

interface Observer
{

    public function Update ();

}

Poniżej przykładowa implementacja klasy, korzystająca z interfejsu Subject:

class MySubject implements Subject
{
    private $_objectsList;

    public function AddObserver (Observer $obj) {

        $this->_objectsList[] = $obj;

    }

    public function DeleteObserver (Observer $obj) {

        $size = count($this->_objectsList);
        for ($i = 0;$i<$size;$i++)
            if ($this->_objectsList[$i] === $obj) {
                    unset($this->_objectsList[$i]);
                    break;
            }

    }

    public function SendToObservers () {

        foreach ($this->_objectsList as $obj)
            $obj->Update();

    }
}

Jak widać SendToObservers() dla wszystkich obiektów obserwujących wywołuje metodę interfejsu Observer – zatem nasuwa się prosty wniosek, nakazujący wszystkim zainteresowanym śledzeniem obiektów klasy MySubject, jego implementację.

class MyObserver implements Observer
{

    public function Update () {

        echo __CLASS__;

    }   

}

class MyObserver2 implements Observer
{

    public function Update () {

        echo __CLASS__;

    }   

}

I na koniec przykład użycia:

// tworzymy podmiot - obiekt obserwowany
$subject = new MySubject();

// tworzymy obiekty obserwujace
$observer1 = new MyObserver();
$observer2 = new MyObserver2();

// dodajemy obiekty obserwujace do podmiotu
$subject->AddObserver($observer1);
$subject->AddObserver($observer2);

// wyslanie powiadomien
$subject->SendToObservers();

// usuniecie z listy obserwujacych
$subject->DeleteObserver($observer1);

// ponowne wyslanie powiadomien
$subject->SendToObservers();

obserwator w standard php library – czyli najlepsze rozwiązanie

Zamiast tworzyć własne interfejsy, możemy skorzystać z tych zdefiniowanych w SPL (co jest wygodniejsze) i dostępnych od wersji PHP 5.1. Mam tu na myśli SplSubject i SplObserver:

class MySubject implements SplSubject
{
    private $_objectsList;

    public function attach (SplObserver $obj) {

        $this->_objectsList[] = $obj;

    }

    public function detach (SplObserver $obj) {

        $size = count($this->_objectsList);
        for ($i = 0;$i<$size;$i++)
            if ($this->_objectsList[$i] === $obj) {
                    unset($this->_objectsList[$i]);
                    break;
            }

    }

    public function notify () {

        foreach ($this->_objectsList as $obj)
            $obj->update($this);

    }
}

class MyObserver implements SplObserver
{

    public function update (SplSubject $subject) {

        echo __CLASS__;

    }  

}

class MyObserver2 implements SplObserver
{

    public function update (SplSubject $subject) {

        echo __CLASS__;

    }   

}
// tworzymy podmiot - obiekt obserwowany
$subject = new MySubject();

// tworzymy obiekty obserwujace
$observer1 = new MyObserver();
$observer2 = new MyObserver2();

// dodajemy obiekty obserwujace do podmiotu
$subject->attach($observer1);
$subject->attach($observer2);

// wyslanie powiadomien
$subject->notify();

// usuniecie z listy obserwujacych
$subject->detach($observer1);

// ponowne wyslanie powiadomien
$subject->notify();

Jak zwykle zachęcam do pogłębiania wiedzy na temat wzorców. Więcej informacji na ich temat znajdziecie w google, jak również w innych moich wpisach poruszających ich tematykę.

Countable składa się z prototypu tylko jednej metody – count(). Zatem stworzenie przykładowej klasy, korzystającej z dobrodziejstw tegoż interfejsu nie powinno przysporzyć większych problemów. Spójrzmy na poniższą definicję:

class Test implements Countable {

	private $_testArray = array ();

	public function __construct(array $newArray) {

		$this->_testArray = $newArray;

	}

	public function getArray () {

		return $this->_testArray;

	}

	public function setArray(array $newArray) {

		$this->_testArray = $newArray;

	}

	// implementacja interfejsu
	// zwracana wartosc wykorzystuje metoda count
	// wywolywana dla obiektow tej klasy
	public function count () {

		return count($this->_testArray);

	}

}

No i użycie:

$testObject = new Test(array(1,2,3,4,5,6));
echo count($testObject);

Na wyjściu otrzymujemy:

6

Osoby zainteresowane SPL zapraszam do zapoznania się z dokumentacją lub moimi poprzednimi wpisami o DirecotryIterator, Serializable, ArrayAccess i SPL Exceptions.

class Test {

	public function Exception () {

		throw new Exception (__METHOD__);

	}

}

try {
	$obj = new Test();
	$obj->Exception();
} catch (Exception $e) {
	echo $e->getMessage();
}

Oczywiście możemy tworzyć własne klasy, dziedziczące po Exception:

class MyFirstException extends Exception {}
class MySecondException extends Exception {}

class Test {

	public function Exception () {

		throw new MySecondException ('MYSECOND '.__METHOD__);

	}

}

try {
	$obj = new Test();
	$obj->Exception();
} catch (MyFirstException $e) {
	echo $e->getMessage();
} catch (MySecondException $e) {
	echo $e->getMessage();
}

PHP pozwala również napisać własną obsługę wyjątków, które nie zostaną przechwycone. Wystarczy zdefiniować swoją funkcję i zarejestrować ją z wykorzystaniem set_exception_handler($function_name):

function my_exception_handler ($exc) {

	echo 'MY HANDLER EXCEPTION MESSAGE: ',$exc->getMessage();

}

set_exception_handler('my_exception_handler');

class Test {

	public function Exception () {

		throw new Exception (__METHOD__);

	}

}

$obj = new Test();
$obj->Exception();
echo 'NIE WYKONA SIE';

Od wersji 5.3 udostępniono zagnieżdżanie wyjątków (nesting of exceptions). Wygląda to mniej więcej tak:

class Other_Exception extends Exception {}
class Test_Exception extends Exception {}

class Test {

	public function Exception () {

		throw new Test_Exception(__LINE__);

	}

}

try {

	try {

		$obj = new Test();
		$obj->Exception();

	} catch (Test_Exception $e) {

		// przekazujemy wyjatek Test_Exception "wyzej"
		throw new Other_Exception(__LINE__,-1,$e);

	}

} catch (Other_Exception $e) {

	// jestesmy w stanie odwolac sie do
	// wyjatku Test_Exception
	// metoda getPrevious
	echo $e->getPrevious()->getMessage(),' ',$e->getMessage();

}

SPL

Standard PHP Library czyli w skrócie SPL stanowi zbiór klas i interfejsów, które pozwalają na tworzenie zaawansowanych i ciekawych rozwiązań, w miarę prosty sposób. O elementach tej biblioteki, miałem okazję pisać już niejednokrotnie:

• klasa DirectoryIterator – TUTAJ
• interfejs Serializable – TUTAJ
• interfejs ArrayAccess – TUTAJ

Wracając do meritum sprawy, w SPL zdefiniowano trzynaście klas wyjątków. Najważniejsze dwa to: LogicException i RuntimeException. Oba dziedziczą z Exception i grupują pozostałe jedenaście klas. Cała struktura przedstawia się następująco:

• Exception
  • LogicException
    • BadFunctionCallException
      • BadMethodCallException
    • DomainException
    • InvalidArgumentException
    • LengthException
    • OutOfRangeException
  • RuntimeException
    • OutOfBoundsException
    • OverflowException
    • RangeException
    • UnderflowException
    • UnexpectedValueException

Wyjątki z grupy LogicalException powinny być zgłaszane w sytuacji zmiany stanu obiektu albo jako konsekwencja przekazania nieprawidłowych argumentów do metod lub funkcji. Odstępstwo od tej reguły stanowią: BadFunctionCallException i BadMethodCallException – ich użycie wskazane jest w przypadku braku danej funkcji lub metody. Wyjątki należące do RuntimeException wyrzucamy w czasie wykonywania się metod lub funkcji. Na koniec praktyczna prezentacja możliwości SPL exceptions:

class Test {

	private $intValue;

	public function __construct($intValue) {

		// bledny argument
		// to blad logiczny
		// zwiazany ze stanem obiektu
		if (!is_int($intValue))
			throw new InvalidArgumentException('NOT INTEGER');

		$this->intValue = $intValue;

	}

	public function __call($method,$args) {

		// taka metoda nie istnieje
		// lub nie jest dostepna
		// czyli blad logiczny
		throw new BadMethodCallException('BAD METHOD');

	}

	public function doSomething () {

		// zakladamy ze cos przebiega nieprawidlowo
		// i wtedy blad czasu wykonania - runtime
		// np niespodziewana wartosc:
		throw new UnexpectedValueException('BAD VALUE');

	}

}

try {

// 	poprawnie bez wyjatkow
	$obj = new Test(4);

//	generuje InvalidArgumentException
//	$obj = new Test('4');

//	generuje BadMethodCallException
//	$obj->Test();

//	generuje UnexpectedValueException
//	$obj->doSomething();

} catch (InvalidArgumentException $e) {

	echo $e->getMessage();

} catch (BadMethodCallException $e) {

	echo $e->getMessage();

} catch (UnexpectedValueException $e) {

	echo $e->getMessage();

}

Osoby zainteresowane poznaniem wszystkich możliwości jakie oferuje SPL, odsyłam do dokumentacji, którą znajdziecie TUTAJ.