Newsgroup: it.comp.www.php
Titolo: meglio una proprieta' o una funzione astratta

// esempio 1
 
abstract class a {
     private $prop;
 
     function __construct($prop) {
          $this->prop = $prop;
     }
 
     function show() {
         echo $this->prop;
     }
}
 
class b extends a {
     function __construct() {
         parent::__construct(1);
     }
}
 
// esempio 2
 
abstract class a2 {
     abstract protected function fun();
 
     function show() {
         echo $this->fun();
     }
}
 
class b2 extends a2 {
     protected function fun() {
         return 2;
     }
}
 
 
Quale dei due approcci ï¿œ meglio usare?
Io preferisco il secondo esempio: mi sembra piï¿œ snello...

 Quale dei due approcci è meglio usare?
 
Sono dettagli implementativi interni, quindi in realtà, mantenendo le API 
pubbliche stabili, puoi scegliere quello che ti piace di più.
 
Poi dipende sempre da cosa stai sviluppando quale sia il metodo migliore. 
Non c'è un migliore in assoluto. In alcuni casi (prestazioni massime) 
conviene andare con l'esempio 1. In altri casi (obbligo di 
implementazione particolare da parte dei figli) meglio l'esempio 2.
 
Bye.

 implementazione particolare da parte dei figli) meglio l'esempio 2.
 
Comunque nel secondo esempio, oltre alla proprietà si evita anche il 
costruttore che la deve inizializzare (assegnare il valore).
Di contro le funzioni astratte devono per forza essere public, o 
protected, quindi accessibili dai figli: il che può essere anche uno 
svantaggio (riservatezza, accessi inutili...).

 svantaggio (riservatezza, accessi inutili...).
 
Eh, per forza, altrimenti non le implementi più. ;) (lo so che lo sai! :D)
 
Ma, come dicevo sopra, se un "utente" (un altro sviluppatore) sta 
sovrascrivendo un tuo metodo, si presuppone che sappia quello che fa.
Se non lo sa, sono affari suoi, e seguirà il backtrace dell'errore per 
accorgersi che sta sovrascrivendo un metodo.
 
D'altro canto si spinge sempre di più verso la composizione piuttosto che 
vero l'eredità, il che rende sempre più pressante rendere public i metodi 
(o almeno documentare bene e rendere public e stabili le API pubbliche) 
piuttosto che cercare di "proteggere" quello che non è proprio tuo (sono 
dati dell'utente di cui sopra).
 
Io tendo sempre più spesso, a livello infrastrutturale (framework quindi, 
non applicazione) a fare classi abstract e usarle come interface (e 
quindi a NON usare interface, che trovo abbastanza inutile in PHP). Nella 
classe abstract metto dei metodi che potrebbero tornare utili a chi usa 
il framework, ma che possono anche essere sovrascritti alla bisogna.
 
Bye.

 il framework, ma che possono anche essere sovrascritti alla bisogna.
 
Dipende, se si tratta di parti strettamente meccaniche, io preferisco 
tenerle nascoste.
 

 tenerle nascoste.
 
Questione di gusti, e giustamente dipende.
 
Ma mi sono scottato da solo troppe volte per avere ancora voglia di 
mettere private. :)
 
Bye.

 mettere private.:)
 
Una funzione di servizio che deve gestire aspetti strettamente tecnici, 
di controllo, di validazione, che deve essere richiamata sollo dalla 
stessa classe, non ha senso che sia public.
Tramite public, protected e private l'utilizzatore può sapere 
esattamente cosa può richiamare, e cosa non deve richiamare IHMO.
E cmq una funzione non publica si può facilmente farla diventare 
publica, ma io personalmente prima preferisco rileggermela, vedere se ci 
possono essere effetti collaterari, e nel 80% dei casi vado a scoprire 
che la funzione che mi serve è un'altra :-b
Se quel 'private' quindi è stato messo a caso!

 stato messo a caso!
 
Questo funziona se hai una codebase limitata e ci lavori solo tu. Se sei 
in team, ogni volta che trovi una private nel framework devi fare una 
riunione per vedere se si può trasformare in protected. A quel punto un 
programmatore pragmatico fa copia-incolla della tua classe e buonanotte 
al DRY. :D
 
Bye.
 

 al DRY. :D
 
Cmq ripeto quando una funzione è privata, in genere significa che non la 
devi toccare.
Se poi sei contrario (la vuoi public) riunisci chi ne è responsabile, e 
ne discuti.
Ma devi essere proprio convinto delle tue motivazioni, altrimenti sono 
torte in faccia :-b