CallBacks o Estensioni delle Classi?

[daniele_dll]

beh...

mettiamo che la mia classe ha questo metodo (ovviamente è ESTREMAMENTE striminzito)

function set_callback($callback_name, $callback_function) {
  $this->__callbacks[$callback_name] = $callback_function;
}

poi ho il metodo "privato" __call_callback

function __call_callback($callback_name, $callback_params=array()) {
  if (!isset($this->__callbacks[$callback_name])) return FALSE;
  $res = call_user_func_array($this->__callbacks[$callback_name], $callback_params);
  return $res;
}

function onLogin_event($login_id, $login_name) {
  .
  .
  .
}

$class = &new Class();
$class->set_callback('onLogin', 'events_onLogin');

e al momento del login all'interno del mio codice richiamo il metodo __call_callbacks passando come primo parametro onLogin e come secondo parametro un'array composto da due elementi nei quale nella prima posizione ci sta l'id utente nella seconda posizione il nome utente

un'esempio banalissimo, ma se ad es voglio far si che mi venga passato un parametro fisso aggiuntivo per una specifica callback basta che dentro l'array __callbacks invece di impostare il valore della funzione imposto un sotto array che comprende un'array con la lista dei parametri aggiuntivi e un valore che è quello della funzione

ed essendo che passando un'array, al posto del nome della funzione posso utilizzare una classe ho tutto estremamente flessibile

se ad es voglio fare una classe che si chiama SocketServer e far si che questa classe si occupi della creazione e della gestione di tutte le richieste fatte alla socke server e poi di richiamarmi anche le callbacks sue personali in questo modo posso impostare come parametro predefinito un indice che mi gestisce la classe SocketServer e quindi posso sapere quale socket è che mi richiama l'evento e posso anche far smistare l'evento fuori ))

ecco perché sono indirizzato su questa strada, cosa non molto fattibile usando l'estensione delle classi xche invece di far gestire tutto ad una classe ogni classe gestirebbe tutto per i fatti suoi...non so dal punto di vista teorico cosa sia meglio, ma dal punto di vista funzionalità e praticità so decisamente meglio le callbacks, almeno per questo tipo di applicazione. Anche xche è una cosa standard...se avete mai usato librerie esterne, anche in java, molte di queste utilizzano le callbacks per ritornare informazioni e valori e non l'estensione delle classi xche la gestione di array di queste diventerebbe troppo complesso da gestire ^^

[Fabio Heller]

Per essere sicuro di darti consiglio sensato dovrei capire bene cosa vuoi ottenere, però ho l'impressione che molto dipenda dal fatto che qui
http://forum.html.it/forum/showthrea...hreadid=733261

Hai creato una super mega classe monoblocco, invece di suddividerla in elementi più piccoli a seconda dei compiti che devono eseguire.

Il tuo uso delle callback mi fa venire in mente che con l'OOP puoi fare qualcosa del genere

Es. le classi A e B condividono la stessa interfaccia (metodi con lo stesso nome) ma consentono operazioni differenti

Se tu fai

$obj = new $classe() ;

$obj->metodoXY() ;

Passando di volta in volta la classe che ti interessa in $classe, puoi eseguire il metodo dell'una o dell'altra con risultati differenti.

Inoltre come di sicuro sai, puoi anche fare

$obj->{$methodo}() ;

o

call_user_func_array( array($obj, $metodo), $arr_parametri)

Non so se possa fare al caso tuo, però questo discorso delle callback e quell'enorme switch nell'altro thread mi sembra un po' troppo complicato

[daniele_dll]

beh

quell'enorme switch e tranquillamente smontabile in tanti sotto metodi

credo che li sia inutile fare una suddivisione estrema interna xche rischio di creare un pesante accrocchio non funzionante

or dunque ti spiego...a me la classe serve per il client irc fatto usando gtk-php per il phpday...e quindi mi serve creare un sistema che crei loop di attesa, ma venga tutto gestito a livello superiore...come dire...una struttura non-blocking, che non resta in attesa ^^
Per far questo, se dai uno sguardo al codice, utilizzo degli stati che vengono poi gestiti da quel mega switch dentro doEvents (che è effettivamente l'unico modo per fare il tutto, anche xche ho bisogno di qualcosa di centralizzato)

Ora vorrei evitare di andare troppo sul complesso per 3 motivi:
1° Non ho molto tempo libero
2° Rischio di perdermi anch'io
3° Vorrei evitare che chi ha bisogno di usare questa classe per cose sue fonda nel tentativo di capire come lavora

Appena finisco di scrivere lo switch per intero lo smonto riportandolo all'interno di specifici metodi privati per far gestire la cosa.
Qui, creare una classe che viene estesa è improponibile xche primo non credo che serva, secondo dovrei creare una classe che estende i vari possibili stati per far si che venga gestito il doEvents, cosa per l'appunto troppo incasinata per i miei gusti...xche non è che posso overloadare il tutto e via perché il metodo doEvents mi gestisce i 4 stadi...quindi dovrei creare 4 classi nelle quali faccio gestire gli stadi e queste 4 classi mi sono gestite da quella principale, ma conviene? a livello di praticità conviene? a livello di funzionalità conviene? e cosi via...non credo possa realmente convenire smembrare a pezzi la classe...xche tutti gli altri metodi devono per forza essere gestiti da quella principale...per dire connect, read, write e cosi via...devono essere gestiti dalla principale, quindi creare 4 classi per gestire i 4 stati (o quelli che sono) non so quanto possa convenire

sciauz