Newsgroup: it.comp.www.php
Titolo: Domanda intrigante

Partendo dal presupposto che non mi piace e che mi sembra una cosa inutile, 
chi mi spiega briefly i principi della programmazione ad oggetti in PHP?
Partite dal presupposto che l'unica programmazione ad oggetti che conosco (e 
che mi sembra sensata) è quella Event-Driven.
A) come si definisce un oggetto?
B) come si interagisce con l'oggetto?
C) come si definiscono i metodi dell'oggetto?
D) come si definiscono le proprietà dell'oggetto
E) che cazz'è la freccia :-)))
F) chi cazz'è $this
Grazie.

 F) chi cazz'è $this
all'interno della definizione della classe, le proprietà della classe 
stessa vanno riferite con $this.
è come dire:
"vai a prendere le chiavi della macchina."
"di chi?"
"la mia!!"
(è una str*nzata di esempio...)
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/no-word-attachments.it.html

 Una cosa di questo genere? O non c'ho capito nulla? :)
c'hai preso!
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/press/2002-04-11-ms-patent.html

 wrote:
Quindi ricapitoliamo. Supponiamo io voglio fare una classe contatore (boh, 
tanto per dirne una). Una cazzata che ogni volta che lo lancio mi torna un 
numero più grosso di uno rispetto al run precedente.
Allora... la cosa dovrebbe essere così, vediamo se ho capito:
class Contatore
{
var $pointer;
function Contatore()
  $this->pointer=0;
function Increase()
 {
 $this->pointer++;
 return $this->pointer;
 }
}
e poi nel sorgente faccio questo..
<?
 include('lamiaclasse.php');
 Pippo = new Contatore();
 echo Pippo->Increase()." dovrebbe tornare 1";
 echo Pippo->Increase()." dovrebbe tornare 2";
 echo Pippo->Increase()." dovrebbe tornare 3";
?>


 quasi: $Pippo (è comunque una var per la sintassi di PHP!)
Si, si, mi sono sbagliato scrivendolo.
Ma adesso dimmi: perché una persona dotata di raziocinio e con un po' di 
capacità di pianificare preventivamente variabili e tutto dovrebbe fare una 
cosa così complicata, illogica e soprattutto illegibile? :)

 una cosa così complicata, illogica e soprattutto illegibile? :)
le classi sono nate taaaanto tempo fa e non ho idea di quale sia il 
linguaggio pioniere (il primo che ho consciuto è il c++).
la loro funzione principale era definire determinate 'scatole chiuse', il 
cui contenuto è irrilevante.
secondo me, se l'oop viene usato nel modo giusto, è una figata.
ti permette di risparmiare e riciclare un sacco di codice.
es:
se hai l'oggetto porta e quello bottiglia puoi creare una super-classe di 
base:
class oggetto {
        var $stato; //aperta|chiusa
        function oggetto() {
                $this->chiudi();
        }
        function apri(){
                $this->stato='aperta';
        }
        function chiudi() {
                $this->stato='chiusa';
        }
}
poi puoi creare le due sottoclassi:
class porta extends oggetto {
        var $lato; //dentro|fuori
        function porta() {
                parent::oggetto();
                $this->lato='dentro';
        }
        function attraversa() {
                if($this->lato=='dentro') {
                        $this->lato='fuori';
                } else {
                        $this->lato='dentro';
                }
        }
}
class bottiglia extends oggetto {
        var $quanto; //vino che rimane
        function bottiglia() {
                parent::oggetto();
                $this->quanto='0.75';
        }
        function bevi($quanto) { //ritorna quanto bevuta
                if($this->quanto<=$quanto) {
                        $ret=$this->quanto;
                        $this->quanto=0;
                        return $ret;
                } else {
                        $this->quanto-=$quanto;
                        return $quanto;
                }
        }
        function quanto() {
                return $this->quanto;
        }
}
a questo punto puoi fare:
$port=new porta();
print $port->stato."\n";
print $port->lato."\n\n";
$barolo=new bottiglia();
print $barolo->stato."\n";
print $barolo->quanto."\n";
$porta->apri();
$barolo->apri();
il codice dei due apri è lo stesso, ma riferiti a due oggetti diversi.
ho appena INCAPSULATO delle funzioni in modo da essere DI PROPRIETA' 
dell'oggetto corrispondente!
i vantaggi immediati sono molteplici. i principali:
1 - la gestione di apri e chiudi è stata scritta una volta sola
2 - se dò in mano a terzi queste classi già funzionanti, gli basta sapere 
quali sono i metodi degli oggetti, senza preoccuparsi di "quale funzione fa 
cosa e su che entità"
3 - si possono facilmente riutilizzare senza cambiare una virgola di codice 
della classe. o reimplementare senza cambiare il codice dell'applicazione.
pensala dal punto di vista della connessione di un db con una classe ben 
fatta:
una classe 'db' con metodi query, fetch e output può essere usata così:
$db=new db($host,$pwd,$user);
$db->query("select");
while($db->fetch()) {
        $db->output();
}
puoi estendere una classe così per usarla con mysql, postgres, oracle ecc.
senza cambiare una linea di codice (tranne l'inizializzazione)!
il PHP poi non è che sia particolarmente portato per questo tipo di 
programmazione, ma con java o c (o, meglio di tutti, *Ruby* ) le cose 
cambiano!
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://groups.google.com

cosa così complicata, illogica e soprattutto illegibile? :)
E' un'ottima domanda che mi sono posto diverse volte anche io: qual e'
il vantaggio concettuale di usare oggetti e metodi invece di variabili e
funzioni? Tanto vantaggioso da controbilanciare la scomodita' e la
bruttezza, perdipiu'.
Bel thread :)

 class porta extends oggetto {
Ricomincia da qui.
Accanna le porte e soprattutto _lascia_ _stare_ _il_ _barolo_, e rispiegati 
con esempi più terraterra di codice pratico anche inutile, tipo il contatore 
di prima. :)))))))
Graaaazie ;)

 bruttezza, perdipiu'.
per quanto riguarda la scomodita, scompare con l'abitudine.
(il passaggio inverso è altrettanto duro, immagino!).
anche per la bruttezza non sono d'accordo.
il fatto di vedere immediatamente l'associazione oggetto->metodo IMO 
aumenta la leggibilità e la comprensione delle funzioni.
tant'è che moltissimi progetti opensource (KDE in primis) hanno migrato da 
C a C++ proprio per aumentare la facilità di stesura del codice, la sua 
leggibilità e per abbassare la complessità delle note per gli sviluppatori.
(ogni tanto nelle todo-list di alcuni progetti vedi annunciato il passaggio 
ad OOP)
saluts
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.php.net

 Bel thread :)
Beh, lo dice anche il titolo. :)

 il contatore di prima. :)))))))
avevo cercato un esempio terraterra, ma forse ho tralasciato il concetto di 
ereditarietà e di 'scatola'...
immagina una televisione o meglio ancora, un MONITOR (vecchio stile):
un monitor è un oggetto (classe) che ha al suo interno pezzi (codice) molto 
complessi e all'esterno invece ha tasti di base (metodi) molto semplici:
il tasto per accendere/spegnere
la rotellina del contrasto
la rotellina della luminosità
le rotelline per gli spostamenti.
una fabbrica di monitor mi può fare 20 monitor diversi, ma per l'utente, al 
di fuori delle prestazioni (risoluzione, ad esempio), l'interfaccia non 
cambia, e all'utente non interessa sapere cosa c'è dentro di diverso!
questo è il concetto di 'scatola'. né più né meno del concetto di shared 
library del C.
il concetto di ereditarietà è un'estensione, nell'esempio del monitor:
io (costruttore) posso decidere di aggiungere il bottone DEGAUSS in un 
nuovo modello. cosa faccio? prendo il progetto del monitor vecchio e gli 
aggiungo il degauss. non ho riprogettato tutto il monitor!
(non calza benissimissimo)
riprendiamo dalla classe Contatore:
class Contatore
{
var $pointer;
function Contatore()
  {
  $this->pointer=0;
  }
function Increase()
 {
 $this->pointer++;
 return $this->pointer;
 }
}
metti (a fantasia) che questa classe abbia un codice molto complesso.
se volessi creare una classe Contatore_Bidirezionale per un'altra 
applicazione, basta fare:
class Contatore_Bidirezionale extends Contatore
{
function Decrease()
 {
  if($this->pointer>0)
        {
        $this->pointer--;
        return $this->pointer;
        }
   else
        return "error!";
 }
}
senza preoccuparmi di reimplementare tutto in modo che funzioni con la 
nuova caratteristica.
dopo che ho creato il contatore bidirezionale, potrei creare un oggetto 
'termostato'
che può estendere contatore bidirezionale perché puoi incrementare o 
diminuire la temperatora che segna. ricicli codice!
right??
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.nist.gov/dads/

 right??
Si, ma se io cambio la definizione di Contatore() ti inculo.
A me 'ste classi me paiono 'na strunzata.

ad OOP)
Infatti, mi sembra molto sensato che i grossi progetti sviluppati da
team distribuiti possano trarre vantaggio dall'approccio object
oriented.
Il fatto e' che nel mio piccolo, quando mi sono dovuto confrontare con
l'OOP, ha quasi sempre vinto l'OOP :)
Cioe', quello che dovevo fare l'ho fatto, ma ho sempre fatto molta
fatica a entrare nell'ottica (e nella notazione) degli oggetti.
E' evidente che devo sfoltire un po' di pigrizia mentale, non puo'
essere cosi' male, no? :)

Beh, lo dice anche il titolo. :)
Si, gia' il fatto che non sia "Aiuto per PHPNuke!" invoglia molto a
parteciapare :)

 e' soprattutto la freccia che non sopporti :)
Lo dico e lo urlo.
Se fosse il . come in smalltalk, java, delphi o (scusate se lo cito in visual 
basic) sarebbe meglio. Purtroppo c'è la freccia alla C++ che nun me piace.

 $__dbms["type"] = "mysql"; // oppure pgsql, eccetera
...il tuo codice è meno riutilizzaibile che avere una clesse per il db.
l'array $__dbms["type"] ...ha "effetti colleterali" ...può essere
sovrascritto da qualcuno che include le tua funzioni.
ESEMPIO:
----
include('config.inc.php');
include('/includes/db.inc.php');
$__dbms["type"] = "il mio db";
// per caso ridefinisco la tua
// variabile usando lo stesso nome
$link1 = SK_db_connect(); // non piglia più i valori giusti....
----
Un oggetto permette di nascondere lo "stato" di un entità al suo interno se
la sua classe è ben progettata.
Permette di nascondere una parte dello stato e di rendere accessibili altre
parti tramite i metodi della classe.
Finchè sei solo tu ad usare il tuo codice magari non commetterai mai
l'errore ...ma uno che si prende la tua libreria potrebbe farlo.
Alcuni vantaggi della programmazione ad oggetti:
- riutilizzo più semplice ed efficace del codice della classe (soprattutto
se il linguaggio supporta meccanismi di ereditarietà e polimorfismo...
arriveranno in PHP5)
- permette di nascondere l'implementazione  (...arriverà con PHP5)
- più semplice organizzazione del lavoro di implementazione
- progettazione concettuale più semplice di un'applicazione complessa
- se l'oggetto è ben costuito permette un'astrazione completa senza effetti
collaterali
- in alcuni linguaggi ci sono strumenti che autocostruiscono la
documentazione dell'applicazione a partire dal codice delle classi e dai
commenti
( ...approposito... non esite un sistema come Javadoc per PHP? )
- se si organizza bene il lavoro dopo aver definito le interfacce si possono
svolgere in parallelo l'implementazione di un oggetto e il suo testing
La programmazione ad oggetti in PHP è ancora molto debole...
bye Ilias
--
Reply to: brain79(at)
inwind.it
www.brainetwork.net
ICQ# 42797710 - FeSToso n°143

 bye Ilias
Ma pure qui sei!? ;)))  E bastaaa!! :-)))

 Ma pure qui sei!? ;)))  E bastaaa!! :-)))
...ho risposto solo perchè eri tu... ;-P


 Prova a fare qualcosa di analogo con la tua libreria...
Che ci vuole
<?
 include('./config1.inc.php');
 $link1 = SK_db_connect();
 include('./config2.inc.php');
 $link2 = SK_db_connect();
?>
è pure molto più corto del tuo. 

--
--
Reply to: brain79(at)
inwind.it
www.brainetwork.net
ICQ# 42797710 - FeSToso n°143
[aforisma del giorno]
"skeyby" <skeyby...@NOSPAMporno-muzik.org> ha scritto nel messaggio
news:CFN3756...@news.virgilio.it...


...quando dopo lavori usi le funzioni della tua libreria... non riesci più a
distinguere di che tipo era il database $link1


 distinguere di che tipo era il database $link1
Eddai Ilias, non fare il cazzone ;)
<?
include('./config1.inc.php');
$mylink = SK_db_connect();
include('./config2.inc.php');
$pglink = SK_db_connect();
?>
Inoltre la stessa osservazione la potrei riferire al tuo uso con le classi, 
chi mi dice qual'è l'oggetto istanziato in un modo e quale l'altro?

 chi mi dice qual'è l'oggetto istanziato in un modo e quale l'altro?
L'osservazione era un'altra comunque un oggetto ben fatto ha dei "selettori"
per accedere ad ogni sua parte che vogliamo rendere visibile all'esterno.
...per esempio un metodo
db->getType();
che restituisce il tipo di database... sempre se vogliamo che sia leggibile
(operazione alquanto inutile)
bye Ilias


Eddai Ilias, non fare il cazzone ;)
No, ha ragione lui. Dovresti modificare tutte le tue funzioni per far
loro accettare (e ritornare) un array:
	$mylink = array(
		'DB'	=> 	'MySQL',
		'link'	=>	$quello_che_prima_era_mylink,
	);
...e naturalmente anche la db_query deve ritornare almeno un array in
cui ci sia 'MySQL'.
Leonardo

 loro accettare (e ritornare) un array:
Giusto, perché uso la stessa variabile per sindere quale funzione usare... 
Beh, in effetti è vero, comunque detto fra noi mi sembra difficile usare due 
DBMS insieme. Può senza dubbio succedere, ma è difficile. Ad esempio se invece 
di usare due DBMS insieme si usassero due DB diversi, oppure due utenze 
diverse già il problema non si porrebbe in quanto quei dati vengono utilizzati 
solo in fase di istanziamento della connessione al DB.

 funzioni MySQL e nell'altro le funzioni PgSQL?
Yes.

DBMS insieme.
Non completamente. MySQL per esempio e' ottimo per query veloci e senza
pretese, e io stesso sto meditando se non mi convenga tenermi MySQL per
le cose piccole in modo da alleggerire PostgreSQL 8-D
Leonardo

 le cose piccole in modo da alleggerire PostgreSQL 8-D
pgsql succhia. Funziona male, non chiude le connessioni, crasha, fra bloccare 
il server, implementa metà comandi sql, insomma: succhia...
comunque aldilà di questo sei pervertito se usi due dbms diversi nell'ambito 
di un solo progetto... :)))

fra bloccare il server, implementa metà comandi sql, insomma: succhia...
Come osi!! ...vuoi scatenare un flame!?!?
:-P
Comuque... personalmente... finora non ho mai avuto problemi con PgSQL
nessun crash, nessun genere di problema...


 nessun crash, nessun genere di problema...
Qualsiasi versione ne abbia installato su qualsiasi computer ne ha abbasto 
l'uptime a non più di 30 ore.
Succhia bigtime.
Funziona (per quel poco che fa) solo sotto Linux.

di un solo progetto... :)))
Prima di tutto, io sono pervertito a prescindere :-).
Secondariamente, cosa fa, uno che usa file di sessione e DBMS per uno
stesso progetto, se non usare due diversi sistemi di DB? Uno rozzo ed
uno no? Ciascuno dei due serve per l'aspetto che sa fare meglio.
Leonardo

 uno no? Ciascuno dei due serve per l'aspetto che sa fare meglio.
e intanto raddoppi le possibilità di crash.

Funziona (per quel poco che fa) solo sotto Linux.
Ahhhhhhhhh. Allora e' ovvio: PostgreSQL non e' garantito per Windows,
anzi confermo che da piu' parti se ne sente parlare male.
Ma, del resto, anche Exchange sotto BSD fa dimorto caà :-)
Leonardo

beato te :)


No, raddoppio le FONTI di possibili crash. E' diverso. La probabilita'
che ciascuna fonte mi produca un crash potrebbe addirittura scendere -
per esempio perche' PostgreSQL non e' piu' oberato di lavoro, ecc.
Se al posto di un 50% metto 12% + 13%, ho raddoppiato le fonti - ma ho
dimezzato la probabilita' complessiva di crash.
Leonardo


beh prima lo fai girare su winzozz e poi ti lamenti che succhia le 
risorse ?? :D
ciao
Alesi_27

quoto quello che dice Leonardo Serni, perché quotare è divertente!!

il mio ultimo progetto usava 2 db insieme e a volte 3, con combinazioni di 
mysql, oracle, sybase e mssql.
avere astrazione (semplice) su oracle, sybase e mssql mi sarebbe servito 
molto.
sfortunatamente il tempo era poco e ho dovuto buttare giù il codice a muzzo!
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.efluxa.it/netiquette/

 piace.
ROTFL
anche il C standard usa in certe occasioni la freccina (a dire il vero in 
quasi tutti i programmini che scrivevo o di cui ho visto il codice).
il seguente esempio toglie i dubbi:
#include <stdio.h>
struct prova {
int numero;
} *pippo, pluto;
int main (int argc, char **argv) {
        pippo=(struct prova *)malloc(sizeof(pluto));
        pluto.numero=12; //notazione struttura statica
        pippo->numero=15; //notazione struttura dinamica
        printf("%d\n%d\n",pluto.numero, pippo->numero);
        free(pippo);
        return(0);
}
le stesse freccine sono largamente utilizzate nel codice del PHP:
grep "\->" * in una subdir a caso con del codice C per credere.
non dirmi che il C è brutto perché m'arabalto sulla sedia e stramazzo al 
suolo con le convulzioni!!!
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.collinelli.net/antispam/

 A me 'ste classi me paiono 'na strunzata.
beh, se la tua posizione finale è questa, tientela pure!
in fondo hai ragione nel dire che se usi un po' di cervello anche con il 
metodo di programmazione normale ci arrivi.
si tratta di due TIPI di programmazione diversa, e la produttività di un 
metodo o dell'altro dipende da chi lo usa. poi, a pari di conoscenza dei 
due metodi, uno risulta migliore dell'altro a seconda del contesto.
non sono certo io a dire che il metodo OOP è migliore dell'altro, solo in 
certi casi ci sono dei vantaggi ad adoperarlo.
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/gnu/manifesto.it.html

 per esempio perche' PostgreSQL non e' piu' oberato di lavoro, ecc.
No, perché a me postgre fa crashare il server senza che NESSUNO lo usi, dato 
che, appunto, nessuno dei miei clienti lo usa.
Infatti l'ho deinstallato e ora la macchina a 90+ giorni di uptime.

 risorse ?? :D
Chi ha parlato di Windows?
Io non uso Windows per i server, così come non uso Linux per i server.
Windows si usa per i client "multimedia", Linux si usa per i client 
Internet/Office Automation, e per i server si usano i sistemi server, tipo 
OS/2, AIX, OpenBSD, FreeBSD, eccetera.

 anzi confermo che da piu' parti se ne sente parlare male.
Ancora? 
Non uso Windows.

 suolo con le convulzioni!!!
A parte che si dice convulsioni, comunque di tutti i linguaggi esistenti credo 
che più brutto del C ci siano solo il Cobol ed il Fortran.

 due metodi, uno risulta migliore dell'altro a seconda del contesto.
Il problema è che nel mondo OpenSource se trovi un sorgente OOP t'ammazzi a 
capirlo. Anzi, a tal proposito questanotte ho tentato di installare PEAR con 
go-pear, ma l'installer è simpaticamente tappezzato di incompatibilità con i 
sistemi non linuxe per debuggare il codice sto impazzendo... ma il punto più 
bello è questo... Fai conto il seguente pezzo di codice:
==========>>>>>
[...]
$tmp = "/tmp"
$tmpdir = tempnam($tmp, "pippo");
echo $tmpdir;
[...]
==========>>>>>
Da in output:
/tmp/tmp1234567
./tmp1234567
(nulla)
Ahahah.
Ci ho litigato per più di tre ore e non ne sono venuto a capo.
Ora faccio Pineapple, l'opposto a Pear senza classi :)

 Ora faccio Pineapple, l'opposto a Pear senza classi :)
Magari puoi dare un'occhiata ai sorgenti di PhpNuke, dove
non hanno usato sicuramente un approccio OOP per capire
come si può degradare il codice tale da portarlo
al livello di ingestibilità.
Non che l'OOP sia il rimedio ad ogni male cmq.
-- 
SpeedTech
http://www.speedtech.it

Ancora? Non uso Windows.
Spiacente per l'equivoco. Ma Windows e Linux sono le alternative piu'
gettonate in questo NG (altro sarebbe it.comp.database, per dire), di
conseguenza penso di poter essere scusato per esservi caduto :-)
A me risulta che giri felicemente non solo sotto Linux ma anche sotto
HP/UX (nonostante il PHP 4.2.1 (IIRC) con Netscape Enterprise dia una
serie di problemi mistici non ancora ben analizzati).
Esistono comunque certamente un sacco di sistemi operativi dove o non
ci sono porting, o i porting fanno pieta'... come penso per qualsiasi
altro programma, con la possibile eccezione di "Hello World".
Va da se' che sotto (poniamo) AIX 4.2.5, se PostgreSQL funziona male,
non usero' PostgreSQL. Mi pare un po' strano perche' il codice... per
quel che ho visto... mi pareva pulito e non una gran fonte di guai.
Leonardo e la sua esperienza




Boh. Non so cosa dirti. Segnala il bug. Se nessuno lo usa, ho
controllato ora e PostgreSQL si limita a fare una wait(), poi
si mette in paziente attesa. Che il crash sia provocato dalla
gestione periodica dei WAL sul backend, mi pare strano.
Che crashi il *server* al punto da richiedere il riavvio, con
applicazioni non root (e PostgreSQL non gira come root) su un
sistema operativo serio, mi sembra ancor piu' strano.
E ancor piu' strano che non si trovi traccia di una enormita'
del genere su Google o sul sito di PostgreSQL
 
http://archives.postgresql.org/search.php
Nella versione 7.1 sono state effettuate fix per AIX, pero' a
quanto mi consta era tutta roba che andava usata, non roba in
grado di crashare stando ferma.
Non potrebbe essere un problema di configurazione?
Leonardo

La programmazione ad oggetti in PHP è ancora molto debole...
Moltissimo...
ciao
--
"Un pessimista e' uno che, quando sente profumo di fiori, si guarda in
giro per vedere dov'e' la bara".
--
Michel <ZioBudda> Morelli               
mic...@ziobudda.net
ICQ UIN: 58351764                       PR of Linux in Italy
http://www.ziobudda.net
 
http://www.phpdev.it