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
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.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.
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.
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
Kanał ATOM
<?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.
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:
Wady:
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.).
Today I want to share with you another great plugin that is perfect for Symfony2 developers or anyone who wants to have Doctrine, Twig or Yaml support using Eclipse IDE.
From symfony.dubture.com:
What’s this?
An Eclipse plugin for Symfony and the Symfony components . Features include:
– Codeassist for Symfony specific elements, like services, routes, template paths, entities, translations and twig blocks. – Navigation: Hyperlinking of routes, templates, twig blocks/functions/filters and services – Annotation support – Twig support Twig
Twig is a templating language for PHP. Symfony has built in support for Twig, and so does the Symfony Eclipse Plugin. Doctrine
Doctrine is a
viagra onlineset of PHP libraries primarily focused on providing persistence services and related functionality. It comes bundled with the Symfony Standard-Edition as the default ORM. The Symfony Eclipse Plugin also provides Doctrine support.
Yaml
Yaml is a data serialization standard which is supported by Symfony. If you’re using yaml, you can use the optional Yedit feature. The plugin is maintained by oyse. Too keep things simple, the Symfony Plugin updatesite makes the Yedit feature available too.
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.
<?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"
?>
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:
Wady:
Property można wykorzystać do przechowywania konfiguracji aplikacji.