CodeIgniter este un framework open-source scris in PHP care se bazeaza pe principiul RAD. Popularitatea acestui framework este in continua crestere, probabil in special de cand lumea a descoperit ca e mult mai usor sa folosesti un framework open-source decat sa dezolti unul intern, dar asta este alta discutie. Cartea CodeIgniter 1.7 de la PacktPublishing, scrisa de Jose Argudo Blanco si David Upton urmareste formarea unei imagini de ansamblu asupra framework-ului CodeIgniter, venind in completarea manualului.

Pana la urma orice framework care se respecta are o referinta detaliata a acestuia, cu eventuale exemple, mai mult sau mai putin cuprinzatoare. Atunci cand vine vorba de invatarea unui framework (si nu numai), o referinta de cele mai multe ori nu este un punct bun de plecare, pentru ca nu poti cauta in aceasta solutii de ansamblu cand primesti explicatii atomice. De asta ajungem sa cumparam carti, pentru a avea o prezentare generala cu probleme si solutii. Si asa am ajuns la cartea CodeIgniter 1.7.

Initial cand am vazut ca titlul cuprinde numarul versiunii framework-ului pe care il analizeaza am fost putin pesimist, pentru ca atunci cand cumperi o carte nu o vrei neaparat legata de o versiune, nu? Nuprea… eu am avut problema asta cu Zend Framework de exemplu, majoritatea cartilor prezinta versiuni “mai vechi” (ex: 1.5-1.6) iar eu vroiam sa vad o abordare cu noile facilitati din versiunea 1.8 sau mai mare. Pana la urma atunci cand inveti vrei de obicei o versiune mai noua a framework-ului, iar cand vor aparea facilitati noi probabil va fi mai simplu sa le citesti doar in referinta.

artea se pare ca porneste de la nivelul de incepator si ataca progresiv atat elementele de baza cat si cele mai frecvente probleme cu care utilizatorul se poare intalni in dezoltarea de aplicatii folosind framework-ului CodeIgniter. Capitolul mostra, pare destul de bine structurat si usor de inteles, iar din cuprins pare sa atace toate subiectele importante, asa ca in speranta ca si restul cartii va fi la fel si ca va mai urma si o parte a doua la acest “review” astept cu nerabdare cartea.

Va urma…

Probabil cel mai cunoscut pattern de PHP si nu numai.

Motivatie:

Restrictionarea la o singura instanta a unei resurse in toata aplicatia, accesibila de oriunde.

Diagrama:

Implementare:

Exemplul clasic pentru PHP este resursa de conectare la baze de date. Conexiunea la baza de date trebuie sa fie unica in toata aplicatia pentru a nu stabili conexiuni multiple la baza de date si in consecinta sa fie consumate resurse inutil.

Pentru ca sa existe o singura instanta constructorul nu trebuie sa fie accesibil decat printr-o metoda statica, iar obiectul rezultatul nu trebuie sa aiba posibilitatea de clonare. De asemenea clasa nu trebuie sa aiba posibilitatea de a fi extinsa.

Exemplu:

  1// date conectare db
  2define ( 'DB_HOST', 'localhost' );
  3define ( 'DB_USER', 'user' );
  4define ( 'DB_PASS', 'pass' );
  5define ( 'DB_DATABASE', 'db' );
  6
  7/**
  8 * Clasa singleton pentru managementul conexiunii la baza de date folosind mysqli
  9 */
 10final class SingletonDB {
 11
 12     /**
 13      * Instanta singleton
 14      *
 15      * @var SingletonDB
 16      */
 17     protected static $_instance = null;
 18
 19     /**
 20      * Connection resource
 21      *
 22      * @var resource
 23      */
 24     protected $_connection = null;
 25
 26     /**
 27      * Constructor care realizeaza si conexiunea la baza de date
 28      *
 29      */
 30     protected function __construct() {
 31          // conectare server baze de date
 32          $this->_connection = new mysqli ( DB_HOST, DB_USER, DB_PASS );
 33
 34          // in cazul in care conexiunea este nereusita se trimite o exceptie
 35          if ($this->_connection->connect_error) {
 36               throw new Exception ( 'Error connection to mysql server' );
 37          }
 38
 39          // selectare baza de date
 40          $this->_connection->select_db ( DB_DATABASE );
 41
 42          // in cazul in care selectarea este nereusita se trimite o exceptie
 43          if ($this->_connection->error) {
 44               throw new Exception ( 'Error selecting database' );
 45          }
 46
 47     }
 48
 49     /**
 50      * Rulare interogare SQL
 51      *
 52      * @param string $query Interogare SQL
 53      * @return mysqli_result
 54      */
 55     public function query($query) {
 56          return $this->_connection->query ( $query );
 57     }
 58
 59     /**
 60      * Acces mesaj eroare
 61      *
 62      * @return string
 63      */
 64     public function error() {
 65          return $this->_connection->error;
 66     }
 67
 68     /**
 69      * Metoda care se apeleaza la clonare
 70      * Este protected pentru ca obiectul nu trebuie clonat
 71      *
 72      */
 73     protected function __clone() {
 74     }
 75
 76     /**
 77      * Intrerupe conexiunea
 78      *
 79      */
 80     public function __destruct() {
 81          $this->_connection->close ();
 82     }
 83
 84     /**
 85      * Metoda care va intoarce instanta singleton
 86      *
 87      * @return SingletonDB
 88      */
 89     public static function getInstance() {
 90          if (self::$_instance == null) {
 91               self::$_instance = new SingletonDB ( );
 92          }
 93
 94          return self::$_instance;
 95     }
 96}
 97
 98try {
 99     // Instanta SingletonDB
100     $db = SingletonDB::getInstance ();
101
102     // Interogare de executat
103     $q = 'SELECT * FROM test';
104
105     // interogarea va returna un obiectu mysqli_result
106     $result = $db->query ( $q );
107
108     // Se verifica daca exista erori si se afisaza
109     if ($db->error ()) {
110
111          echo $db->error ();
112
113     } else {
114          // se extrag rezultatele si se afisaza pe ecran
115          while ( $row = $result->fetch_assoc () ) {
116               var_dump ( $row );
117          }
118          // se inchide obiectul de mysqli_result
119          $result->close ();
120     }
121// in cazul in care apar exceptii acestea se afisaza
122} catch ( Exception $e ) {
123     echo $e->getMessage ();
124}

Iterator pattern este probabil cel mai popular pattern din SPL. Este un exemplu foarte simplu de a demonstra avantajele unei interfete si SPL.

Motivatie:
Posibilitatea de a itera structuri de tip obiect folosind functii precum foreach(), var_dump(), print_r() etc.

Diagrama:

Structura Iterator:

In SPL se gasesc mai multe interfete si clase pentru iterator.

Structura de baza pentru interfata Iterator:

 1/**
 2 * Interfata Iterator din SPL
 3 */
 4Iterator extends Traversable {
 5      /**
 6       * Intoarce elementul curent
 7       */
 8      abstract public mixed current ( void )
 9
10      /**
11       * Cheia pentru elementul curent
12       */
13      abstract public scalar key ( void )
14
15      /**
16       * Trece la urmatorul element
17       */
18      abstract public void next ( void )
19
20      /**
21       * Reseteaza iterarea la pozitia initiala
22       */
23      abstract public void rewind ( void )
24
25      /**
26       * Verifica daca pozitia curenta este valida
27       */
28      abstract public boolean valid ( void )
29}

Exemplu 1:

Un obiect iterabil simplu.

 1/**
 2 * Clasa care va genera un obiect interabil
 3 */
 4class Iterabil implements Iterator {
 5
 6	/**
 7	 * Index pentru elementul iterabil
 8	 */
 9	private $_current = 0;
10
11	/**
12	 * Array cu elementele de iterat
13	 */
14	private $_elements = array();
15
16	/**
17	 * Constructor
18	 *
19	 * @param array $elements Elementele de iterat
20	 */
21	public function __construct($elements) {
22		$this->_elements = $elements;
23	}
24
25	/**
26	 * Elementul curent
27	 *
28	 * @return mixed Elementul curent
29	 */
30	public function current() {
31		return $this->_elements[$this->_current];
32	}
33
34	/**
35	 * Index curent
36	 *
37	 * @return integer Index curent
38	 */
39	public function key() {
40		return $this->_current;
41	}
42
43	/**
44	 * Trecerea la index-ul urmator
45	 */
46	public function next() {
47		$this->_current++;
48	}
49
50	/**
51	 * Resetare index
52	 */
53	public function rewind() {
54		$this->_current = 0;
55	}
56
57	/**
58	 * Verifica daca elementul curent este setat
59	 *
60	 * @return boolean Daca elementu curent este setat
61	 */
62	public function valid() {
63          return isset($this->_elements[$this->_current]);
64     }
65}
66
67// instantiere clasa
68$obj = new Iterabil(array(1, 2, 3, 4, 5));
69
70// iterare obiect
71foreach ($obj as $value) {
72     echo $value.PHP_EOL;
73}
74
75// output:
76// 1
77// 2
78// 3
79// 4
80// 5

Exemplu 2:

Un exemplu putin mai complex, o clasa care permite iterarea prin proprietatile publice ale clasei care o extinde. Se folosesc Iterator si Reflection.

 1/**
 2 * Clasa care va genera un obiect cu proprietatile publice iterabile
 3 */
 4class Iterabil implements Iterator {
 5
 6     /**
 7      * Index pentru elementul iterabil
 8      */
 9     private $_current = 0;
10
11     /**
12      * Array cu elementele de iterat
13      */
14     private $_elements = array();
15
16     /**
17      * Elementul curent
18      *
19      * @return mixed Proprietatea curenta in iteratie
20      */
21     public function current() {
22          return $this->_elements[$this->_current]->name;
23     }
24
25     /**
26      * Index curent
27      *
28      * @return integer Index curent
29      */
30     public function key() {
31          return $this->_current;
32     }
33
34     /**
35      * Trecerea la index-ul urmator
36      */
37     public function next() {
38          $this->_current++;
39     }
40
41     /**
42      * Resetare index si preluare prorietari
43      */
44     public function rewind() {
45          // rewind se apeleaza prima,
46          // deci aici ar trebui preluate prorprietatile obiectului
47          // se initializeaza obiectul de tip ReflectionClass
48          // cu parametru numele clasei curente
49          $reflection = new ReflectionClass(get_class($this));
50
51          // se extrag metodele publice
52          $this->_elements = $reflection->getProperties(ReflectionMethod::IS_PUBLIC);
53
54          // se seteaza indexul curent
55          $this->_current = 0;
56     }
57
58     /**
59      * Verifica daca elementul curent este setat
60      *
61      * @return boolean Daca elementu curent este setat
62      */
63     public function valid() {
64         return isset($this->_elements[$this->_current]);
65    }
66}
67
68/**
69 * O noua clasa care va avea proprietati publice
70 *
71 */
72class Testing extends Iterabil {
73     public $proprietate1;
74     public $proprietate2;
75}
76
77// instantiere clasa
78$obj = new Testing();
79
80// iterare obiect
81foreach ($obj as $value) {
82     echo $value.PHP_EOL;
83}
84
85// output:
86// proprietate1
87// proprietate2

Iar daca vrem ca exemplu de mai sus sa fie si accesibil ca un array, nu trebuie decat sa mai implementam din SPL ArrayAccess.

Structura ArrayAccess:

 1ArrayAccess   {
 2    /**
 3     * Verifica daca un offset exista
 4     */
 5    abstract public boolean offsetExists ( string $offset );
 6
 7    /**
 8     * Intoarce elementul unui offset sau NULL daca nu exista
 9     */
10    abstract public mixed offsetGet ( string $offset );
11
12    /**
13     * Seteaza o valoare pentru un offset
14     */
15    abstract public void offsetSet ( string $offset , string $value );
16
17    /**
18     * Dezaloca o valoare pentru un offset
19     */
20    abstract public void offsetUnset ( string $offset )
21}

Exemplu 3:

Un exemplu destul de dificil care are rolul de a evidentia puterea interfetelor din SPL. Obiect iterabil si accesibil ca un array.

Pentru a simplifica logica de acces am folosit chiar functiile pentru parcurgerea unui array (next(), reset()).

  1/**
  2 * Clasa care va genera un obiect interabil
  3 */
  4class Iterabil implements Iterator, ArrayAccess, Countable {
  5
  6     /**
  7      * Array cu elementele de iterat
  8      */
  9     private $_elements = array();
 10
 11     /**
 12      * Constructor
 13      *
 14      * @param array $elements Elementele de iterat
 15      */
 16     public function __construct($elements) {
 17          $this->_elements = $elements;
 18     }
 19
 20     /**
 21      * Elementul curent
 22      *
 23      * @return mixed Elementul curent
 24      */
 25     public function current() {
 26          return current($this->_elements);
 27     }
 28
 29     /**
 30      * Index curent
 31      *
 32      * @return integer Index curent
 33      */
 34     public function key() {
 35          return key($this->_elements);
 36     }
 37
 38     /**
 39      * Trecerea la index-ul urmator
 40      */
 41     public function next() {
 42          next($this->_elements);
 43     }
 44
 45     /**
 46      * Resetare index
 47      */
 48     public function rewind() {
 49          reset($this->_elements);
 50     }
 51
 52     /**
 53      * Verifica daca elementul curent este setat
 54      *
 55      * @return boolean Daca elementu curent este setat
 56      */
 57     public function valid() {
 58          return current($this->_elements)?true:false;
 59    }
 60    /**
 61     * Verifica daca un offset exista
 62     *
 63     * @param string $offset Element cautat
 64     * @return boolean Daca elementul de la offset exista
 65     */
 66    public function offsetExists($offset) {
 67         return isset($this->_elements[$offset]);
 68    }
 69
 70    /**
 71     * Elementul de la un offset
 72     *
 73     * @param string $offset Offset array
 74     * @return mixed
 75     */
 76    public function offsetGet($offset) {
 77         return $this->_elements[$offset];
 78    }
 79
 80    /**
 81     * Setare element in array
 82     *
 83     * @param string $offset Offset element
 84     * @param mixed $value Valoarea pentru elementul din array
 85     */
 86    public function offsetSet($offset, $value) {
 87         $this->_elements[$offset] = $value;
 88    }
 89
 90    /**
 91     * Dezalocare element in array
 92     *
 93     * @param string $offset Offset element
 94     */
 95    public function offsetUnset($offset) {
 96         unset($this->_elements[$offset]);
 97    }
 98
 99    /**
100     * Numarul de elemente din array-ul curent
101     *
102     * @return integer Nr elemente array
103     */
104    public function count() {
105         return count($this->_elements);
106    }
107}
108
109// instantiere clasa
110$obj = new Iterabil(array(1, 2, 3, 4, 5));
111
112echo 'Iterare folosind "for":'.PHP_EOL;
113
114// iterare ca printr-un array simplu
115for($i = 0; $i < count($obj); $i++) {
116     echo $obj[$i].PHP_EOL;
117}
118
119echo 'Element de sters: '.$obj[1].PHP_EOL;
120
121unset($obj[1]);
122
123echo 'Iterare folosind "foreach":'.PHP_EOL;
124
125// iterare array folosind foreach
126foreach ($obj as $element) {
127     echo $element.PHP_EOL;
128}
129
130// Output:
131//Iterare folosind "for":
132//1
133//2
134//3
135//4
136//5
137//Element de sters: 2
138//Iterare folosind "foreach":
139//1
140//3
141//4
142//5

De ce se vorbeste atat de “bad code” sau “bad practices”? Pentru ca sunt importante!!!

In ultima vreme am avut parte de o experienta care eu o consider neplacuta, cod necomentat, design slab, oop prost implementat, baze de date neoptimizate si prost proiectate.

Comentarile

Este un mare mister pentru mine cum se poate ca in fiecare carte si tutorial disponibil (nu doar de PHP) scrie ca acestea nu sunt optionale ci NECESARE si totusi acestea de cele mai multe ori lipsesc cu desavarsire. Zend Studio are un auto-complete forte simplu si eficient, nu trebuie sa scrieti decat “/**” si sa apasati enter, apoi textul care apare trebuie completat. Netbeans la fel, acelasi sistem, la fel de simplu.

Cu toate astea in ultima perioada m-am lovit de mii de linii de cod aproape fara nici un comentariu, rezultatul? Ore intregi pierdute incercad sa urmaresc logica!

De ce se intampla asta? Primul motiv: este plictisitor, un programator vrea sa scrie cod nu povesti, de multe ori pare un timp irosit. Al doilea motiv: totul pare foarte logic in momentul in care este scris, daca este atat de logic si cursiv de ce sa mai pierzi timpul cu povesti? Pentru ca timpul trece, proiectele se schimba, in timp inevitabil, toata logica este data uitarii. Sau un alt motiv, pentru ca vin persoane noi, in firme programatorii vin si pleaca, iar cel care vine nu mai poate urmarii logica cu aceeasi usurinta, de fapt de multe ori este aproape imposibil de urmarit. Am patit chiar si ca autorul codului sa nu o mai poata urmarii dupa o anumita perioada de timp, uneori autorul eram chiar eu.

Dupa parerea mea asta ar trebui sa fie o regula de baza pentru orice firma care se respecta, nici o clasa/metoda/proprietate nu trebuie sa fie necomentata. Timpul priedut acum pentru comentarii este timp castigat mai tarziu cand se face debugging, oprimizare etc.

Design slab

Am vazut la un “mini interviu” on-line o intrebare care suna: “vedeti importanta arhitecturii inainte de a scrie cod?”, imi cer scuze daca nu mai suna la fel ca in anunt. Prima data cand am vazut intrebarea am avut un moment de deja-vu, de multe ori m-am lovit de problema de a scrie cod ca mai apoi sa realizez ca am o abordare gresita.

De multe ori problema asta se rezolva (cel putin aparent) in timp cu experienta. Practic, daca iei un incepator si il pui sa scrie cod, cel mai probabil va avea cateva abordari slabe pana sa aiba una reusita, iar asta nu este de loc anormal, de asta cred ca un incepator ar trebui ghidat inainte de a incepe sa scrie cod, iar codul care urmeaza sa-l scrie sa aiba o logica clara sugerata de un “mentor”.

In cealalta extrema exista “software architects” care folosind UML schematizeaza logica si structurile in diagrame. Cand exista diagrame atunci este mult mai ushor de urmarit intregul proces si intreaga structura a aplicatiei. Un arhitect priceput va putea sa vada problemele posibile care pot aparea inainte de a incepe sa scrie cod, iar cand se incepe implementarea fiecare stie ce are de facut.

OOP-ul se loveste probabil cel mai mult de design-ul slab, in ultima vreme am vazut o multime de clase care nu aveau nici un fel de organizare, erau doar simple invelitori (wrappers) pentru interogari SQL. Asta nu inseamna OOP!

OOP presupune abstractizarea elementelor in clase si obiecte. De exemplu tastatura, aceasta este o clasa care are niste taste (o clasa copil) cu diverse proprietati(litere, cod de tasta, pozitie), niste leduri (alta clasa copil) etc. Repezentarea acestora in baza de date nu are neaparat o legatura atat de stransa cu obiectele cum pare la prima vedere.

Daca folosesti OOP iar ce citesti acum suna bizar, incearca sa faci pe o foaie de hartie o diagram a aplicatiei tale cu obiectele si a legaturilor dintre ele. Daca nu poti, inseamna ca abordarea ta fata de OOP este gresita(sau nu sti sa faci o diagrama 🙂 )!

Toti facem greseli cand vine vorba de OOP, dar asta nu este o scuza sa nu le corectam si sa nu incercam sa facem arhitectura inainte de a scrie cod.

Un design prost de aplicatie poate avea repercusiuni foarte importante financiare. Timpul inseamna bani, iar daca o aplicatie este slaba, nu este bine structurata, timpul pentru debug-ing este mare, schimbarile necesita timp indelungat, redundanta codului este mare, etc., atunci poti fi sigur ca pierzi bani.

O unealta pe care o folosesc uneori este Violet UML Editor, nu este un editor adevarat de UML cum este Rational Rose de exemplu, ci mai degraba o jucarie open source. Cu Violet se pot realiza doar diagrame vizuale, dar ele pot fi utile pentru a structura o aplicatie.

Baze de date

Oare de ce se feresc multi programatori PHP sa invete cu adevarat MySQL? Suna bizar? Este foarte adevarat totusi. Modificarea codului PHP este de multe ori o operatie nu foarte dificil de realizat (ma refer la rescrierea practica a codului), dar un design prost al bazelor de date este de cele mai multe ori mult mai dificil de modificat pentru ca exista riscul sa piezi informatii.

Acum cateva saptamani am facut o diagrama a unei baze de date folosind MySQL Dump si MySQL Workbench. Nu mica mi-a fost surprinderea sa vad tabele care nu aveau chei de legatura cu alte tabele din care proveneau date (nu ma refer la tabele de setari care din punct de vedere logic nu se leaga), apoi sursa datelor era complet pierduta.

O alta problema clasica de incepatori este cand ai o tabela de legatura intre doua tabele cum ar fi categorii si produse, iar cheia este pusa pe un camp cum ar fi “id” care nu are nici o relevanta. O cheie primara se poate pune pe mai multe campuri, de exemplu cheia ar trebui sa fie “id_categorie, id_produs” nu “id”, iar in felul asta se asigura si unicitatea unui produs intr-o categorie folosind restrictia de primary key.

Un alt lucru care nu il inteleg este de ce lumea evita indecsii. Intr-un blog anterior vorbeam pe scurt despre ei, complet insuficient dar totusi sunt foarte importanti. Un index poate micsora semnificativ timpul de cautare intr-o tabela, de la zeci de secunde uneori la sutimi de secunda. O aplicatie prost optimizata din punctul asta de vedere poate avea un timp de raspuns semnificativ mai mare decat este normal.

Framework-uri

Ca sa citez o fraza deja clasica in comunitatea PHP:

All frameworks suck.

iar Laura Thomson are niste motive destul de bune cu care sa sustina asta.

Cineva spunea saptamana trecuta ca motivul pentru codul prost este chiar PHP si modul lui permisiv. Sa fim seriosi, daca luam un limbaj ca C++ are mult mai multe probleme care pot aparea. Imi aduc aminte in facultate cat de slab era codul care il scriam, iar problema nu era limbajul ci nivelul meu de pregatire de atunci. PHP permite abordari de la OPP pana la spaghetti code (OOP, proceduri, closures, label-uri). Faptul ca multi programatori aleg abordarea proasta nu este o problema de limbaj, la fel exita o problema de abordare si in limbaje cum ar fi C++, sau mai bine zis in orice limbaj exista.

De ce sunt mai putine probleme de design in Ruby on Rails de exemplu? Pentru ca este un framework! Eu nu am auzit pe nimeni pana acum sa faca programare web doar in Ruby (exista programatori Ruby, in special pentru aplicatii desktop, dar asta este alta discutie), evident ca apar mai putine probleme cand folosesti un framework. La fel se pot reduce si probleme din PHP folosind un framework consacrat.

Exista zeci sau chiar sute de framework-uri open source pentru PHP. Din acesta exista cateva cu adevarat consacrate, cum ar fi Zend Framework, CakePHP, Symfony, Solar, CodeIgniter etc. Un avantaj major atunci cand se foloseste un framework este ca poti gasi mult mai usor persoane specializate. Un alt avantaj major este ca ai parte de un cod testat si documentat, lucru care este deosebit de dificil de realizat intr-o firma de dimensiuni reduse.

Sau chiar daca se foloseste un framework intern cred ca este utila abordarea unei structuri similare cu un framework consacrat pentru a reduce curba de invatare pentru programatorii noi.

Folosind un framework consacrat de multe ori se reduce timpuri de lucru si timpul de dezvoltare de noi faciltati pentru ca de multe ori acesta sunt incluse, deci pot aparea avantaje economice indirecte (bani), o stucturate mai buna si nu in ultimul rand programatori mai fericiti (cea ce nu sunt eu acum).

Concluzionand:

• stabileste niste reguli interioare pentru cod, nu uita sa pui comentarile pe lista,
• asigura-te ca designul aplicatiei este facut conform unui plan care sa permita scalabilitate si o redundanta minima a codului,
• asigura-te ca baza de date este bine structuata si optimizata,
• ia in calcul folosirea unui framework consacrat fata de un framework intern sau de unul nou conceput.

Folosind aceste reguli simple se vor salva resurse, timp, bani iar programatorii vor fi probabil mai multumiti de rezultate.

Azi am facut update la clasa de romanian stemmer la versiunea 0.6.

Aceasta genera notice-uri, dar acum le-am corectat.

Enjoy!