PDO sta per PHP Data Objects ed è un nuovo sistema per interfacciarsi a database con PHP 5. Grazie a driver specifici per ogni tipo di database, PDO è in grado di offrire funzionalità ed interfacce standard a prescindere dal tipo del database con cui si interagisce.

Il sistema PHP Data Objects si compone di due classi, una per interfacciarsi al database e per interrogarlo (PDO), un’altra per accedere al record set restituito dalla query (PDOStatement).

L’utilità della programmazione ad oggetti è che è possibile estendere una classe in qualsiasi momento, rendendola più adatta alle nostre esigenze.

Continua a leggere “Estendere PDO e PDOStatement di PHP 5″

Tempo fa iniziavo il discorso Design Pattern e lo facevo con una implementazione del Singleton. Con questo articolo voglio riprendere il discorso sul Design Pattern parlando del Factory.

Il Factory fornisce un’interfaccia per creare famiglie di oggetti connessi o dipendenti tra loro, in modo che non ci sia necessità da parte dei client di specificare i nomi delle classi concrete all’interno del proprio codice.

In questo modo si permette che un sistema sia indipendente dall’implementazione degli oggetti concreti.

Continua a leggere “Il Design Pattern Factory”

La sostanziale differenza tra PHP 5 e la versione 4 è il massiccio utilizzo della programmazione ad oggetti. Grazie ad essa numerose operazioni sono state raggruppate in unici oggetti.

Tali oggetti possono anche essere estesi a nostro piacimento, così da creare strumenti sempre più potenti per lo sviluppo.

Con questo articolo voglio fare focus sull’oggetto DateTime. Tale oggetto si occupa di gestire le date. Grazie ai suoi metodi, è in grado si eseguire operazioni che prima richiedevano numerose conversioni e righe di codice.

Farò due esempio per dimostrarlo.

Continua a leggere “Differenza tra due date con gli oggetti DateTime”

Molto spesso è possibile arrivare ad una soluzione intraprendendo diverse strade.

Ad esempio, potremmo avere la necessità di salvare delle informazioni per poi recuperarle in seguito. La soluzione a questo problema può essere individuata nell’utilizzo di un database; ma potremmo anche decidere di salvare tali informazioni in un file di testo, piuttosto che in un tracciato CSV o XML.

Anche la stessa scelta di utilizzare un database per immagazzinare i dati può portare ad ulteriore decisioni da prendere: ad esempio decidere se utilizzare MySQL, SQ Server o Oracle.

Avvolte accade anche che, fatta una scelta iniziale, col passare del tempo occorra passare ad un’altra soluzione.

Un approccio OOP per l’implementazione di una soluzione è propedeutica per rendere la stessa soluzione flessibile e facilmente modificabile. Tuttavia, occorre tenere presente che col tempo potremmo dimenticare esattamente cosa abbiamo implementato come soluzione.

Non possiamo correre il rischio di implementare una nuova soluzione (ad esempio, passare da un database MySQL a SQL Server o Oracle) che risulti essere incompleta, cioè con metodi incompatibili, di diverso nome o addirittura mancanti.

Le interfacce hanno lo scopo di definire una API che una classe deve implementare. Continua a leggere “L’utilità delle interfacce nella programmazione ad oggetti”

Quando si parla di Design Pattern non si parla altro che di una serie di soluzioni le quali vengono definite eccellenti, testate e vere. Queste soluzioni rispondono a problemi comuni con i quali gli sviluppatori, nel nostro caso i web developer, si ritrovano a dover fronteggiare ogni giorno.

I design patterns non sono regole, ma linee guida che ogni sviluppatore può adottare per risolvere, in maniera sicura e testata, dei problemi.

Sebbene i design patterns possano tradursi anche in codice procedurale, la sua massima espressione la si ha con la programmazione ad oggetti.

Oggi prenderemo in esame il Singleton, un design pattern semplice da implementare. Continua a leggere “Il Design Pattern Singleton”