Newsgroup: it.comp.www.php
Titolo: raggruppamento delle variabili

function ex1() {
	// dati
	$a = 1;
	$b = 2;
	// risultato
	$x = $a + $b;
 
	// dati
	$c = 3;
	$d = 4;
	// risultato
	$y = $c * $d;
}
 
function ex2() {
	// dati
	$a = 1;
	$b = 2;
	$c = 3;
	$d = 4;
 
	// risultati
	$x = $a + $b;
	$y = $c * $d;
}
 
Quale tipo di raggruppamento scegliere?
Sembra una stupidaggine eppure ogni volta è un lavaggio mentale :D


Assumendo ovviamente sia un esempio di qualcosa di più generale, e che non
ti rifai ad un coding standard, che decidi di seguire o che t'impongono,
che altrimenti queste cose le dice:
 
Il secondo.
 
Anche nei linguaggi dove non c'è bisogno di dichiarare le varibili
all'inizio del blocco (invece e.g. del C, dove il compilatore è one-pass
e ha la necessità di sapere quanto stack allocare alla funzione spostando
lo stack pointer) il programmatore ha subito sott'occhio quanta memoria
necessita la funzione (statica, automatica o dinamica che sia), che torna
comodo quando fai debug di casi di out of memory, o comunque di casi di
troppa memoria allocata.
 
In PHP non succede mai, ma visto che anche nei linguaggi dove non serve
quasi tutti lo fanno per convenzione (e.g. C++, Java), non vedo perché
andare contro ad una prassi comune che fonda le sue regole sul buon senso.
 
Se vuoi, è lo stesso motivo del perché si usa il pre-incremento nei for
invece del post-incremento (for(; $i<$N; ++$i) invece di $i++ (che deriva,
a parte un bug di un famoso vecchio compilatore, dall'ordine in cui gli
operatori sono eseguiti in C++)) o quando si scrive la parentesi graffa
di aperta funzione sulla stessa riga della definizione (e.g. PHP, Java)
invece di andare a capo (e.g. C) (che deriva dal sottolineare che, essendo
le funzioni innestabili, si sta aprendo un blocco come un altro, con
l'unica differenza che ha un nome).
 
Quando si programma in team le convenzioni sono tanto importanti quanto
le regole del linguaggio, beh, quasi.
 
 
Ciao!

 
 
Quindi meglio tenere separati i dati (a, b, c, d...) dalle incognite (x, 
y, z...)?


No, i "dati" li metti come parametri se son parametri, come costanti se
son costanti. Io mi riferivo solo alle variabili locali.
 
 
Ciao!


Come ordineresti variabili, costanti, variabili statiche, ecc.?
Ad esempio:
 
class Test {
	const PIPPO = 123;
	static private $pluto = null;
	public $giggio = null;
 
	function test(){
		static $simona = null;
		$sara = null;
	}
}
 
Come vedi io di solito seguo il l'ordine
COSTANTI
VARIABILI STATICHE
VARIABILI
 
Oppure è meglio raggrupparle per visibiliità (public, protected, private)?


 
A me pure piace così, costanti, variabili, funzioni.
Per public/protected/private io personalmente non ci faccio molto caso a
patto che le funzioni stiano insieme per visibilità, perché se la classe
è lunga, e non hai un IDE di qualche tipo, comunque devi scorrerne gran
parte per leggerla. La più accreditata che ho visto, comunque, è mettere
prima gli overload, poi le funzioni private, e le public in fondo.
 
 
Ciao!

 poi le funzioni private, e le public in fondo.
 
Io metto:
 
getInstance() (se la classe è singleton)
costruttore
metodo principale della classe
eventuali altri metodi: i cosiddetti tools (metodi di supporto)
 
Anche se l'ideale sarebbe avere micro-classi (con non più di tre metodi):
 
getInstance() (se la classe è singleton)
costruttore
metodo principale della classe
 
e ogni tools in altrettante singole classi.

metodo principale della classe
 
Dipende da cosa stai facendo. Ho un oggetto Documento che deve implementare
read(), write(), validate() e submit(); cosa me ne farei io di dividerlo in
quattro o più classi? Tenendo conto che read() contiene appunto soltanto il
codice specifico di quel tipo di documento (il resto è nella classe padre),
e così le altre funzioni?
 
Se mai è getInstance() di cui si può fare a meno; sospetto tu la possa - in
quasi tutti i casi - estrarre in un trait.
 
Leonardo
-- 
 
"You all presumably know why" :-) :-(


 
Come ha detto Leonardo, questo non ha molto senso: ogni classe implementa
i metodi che le competono. Fare una classe solo per isolare due/tre funzioni
è il primo passo per diventare un javista ;)
 
 
Ciao!

 quasi tutti i casi - estrarre in un trait.
 
Estrarre in un trait?

 è il primo passo per diventare un javista ;)
 
Anche incorporare nella stessa classe un tool (sanitizer, converter, 
validator...) di 50 e più righe non lo trovo conveniente.
Semmai ti crei una classe specializzata che potrebbe anche essere 
riutilizzabile.
 
Una libreria in genere è formata da un unica classe?
Cioè da un bel monoblocco monolitico?
 
O da più classi che consentono di organizzare meglio il codice, dando 
anche maggiore flessibilità?

 Estrarre in un trait?
 
Forse voleva dire "estrarre da un trait" (ma non ne sono sicuro)

 è il primo passo per diventare un javista ;)
 
Neanche una classe con 20 metodi però è il massimo.

Estrarre in un trait?
 
Una cosa del genere - buttata lì:
 
trait SimpleSingleton
{
    private function __construct() { }
 
    public static function getInstance() {
        static $instance;
        if (null === $instance) {
            $instance = new self();
        }
        return $instance;
    }
}
 
e nella classe potresti avere:
 
class Qualsiasi
{
    use \Traits\SimpleSingleton;
 
    ...
}
 
Potrebbe volerci un PHP recentino.


 <snip>
 
Hai preso un fattoide famoso, l'hai messo in un altro contesto, e l'hai
interpreato a cacchio, per cui faccio una parentesi noiosa io :)
 
Quel famoso "sette", è il numero massimo di varibili indipendenti di cui
un uomo può tener traccia in una funzione. Hai presente una funzione
matematica in una variabile (una curva) o in due (una superfice)? Beh,
viene fuori che quando sali di dimensioni la mente umana si perde
miseramente, fino a raggiungere l'impossibile a quel punto. Ovviamente
nessuno visualizza una funzione in cinque dimensioni (in quattro, a quanto
pare, con un po' d'allenamento, sì), ma si possono gestire le variabili
a mente, con la pratica.
Una funzione in un qualsiasi linguaggio di programmazione, piaccia o no,
è sempre una funzione matematica in un certo spazio (nei linguaggi tipo
PHP, visto che i hanno side-effects, nello spazio degli stati). La regola
di buon senso quindi vuole che avere una funzione con più di quattro,
massimo cinque, parametri è una ricetta per il disastro.
 
Prendi una classe con un solo metodo che fa quello che serve, quattro
membri privati, mettici costruttore, getters/setters, overloads e operatori,
e hai una classe semplicissima con una ventina di funzioni. Nessuno direbbe
mai che è troppo complessa.
Prendi cinquanta funzioni che operano sullo stesso concetto (e.g. funzioni
su immagini, tipo GD), e le wrappi statiche in una classe. Nessuno direbbe
mai che la classe è troppo complessa, visto che è solo un wrapper.
 
Sinceramente, secondo me, quando ti viene il prurito di spezzare qualcosa
che nello UML di progetto è in un oggetto solo, converrebbe pensarci
due/tre volte prima.
 
 
Ciao!

      use \Traits\SimpleSingleton;
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
E questo si chiama "estrarre il codice in una trait" o "estrarre il 
codice da una trait"?

due/tre volte prima.
 
Questa è pure la mia opinione :-)


 E questo si chiama "estrarre il codice in una trait"
 
Io uso 'trait' al maschile, comunque sì. Prendi un certo tipo di codice
che si riferisce a un "comportamento" della classe, lo tiri fuori dalle
classi di quel tipo e lo metti in un trait.
 
Poi le varie classi reimportano quel trait. Uno "use", e hai fatto.
 
Questo, per il codice per cui fare così ha senso, beninteso. Almeno per
l'esempio che ho usato, mi pare che possa aver senso... se hai però dei
singleton di tipo molto complesso, *non* è detto che continui ad essere
una buona idea. Idem, penso, dove il trait serve a una classe sola.


 Questa è pure la mia opinione
 
https://ibb.co/cKVUgL
 
vedere le parte iniziale (post di un certo Alessandro Pellizzari)

 Poi le varie classi reimportano quel trait. Uno "use", e hai fatto.
 
Quindi estraggono (attingono) il codice *dal* trait...
 


Stiamo dicendo tutti la stessa cosa: una classe non dovrebbe essere così
grossa, da superare la capacità del programmatore di orientarcisi.
 
Ora, per alcuni questa dimensione critica è tre metodi, o dieci.
 
Per altri è trenta.
 
Per altri è cento o trecento.
 
La "capacità" è costruita da una base di capacità personali, più metodo,
più strumenti. Un astronomo miope, ai comandi del telescopio Keck, vedrà
sempre più lontano di un astronomo con trenta decimi a occhio nudo.
 
Del resto è il motivo per cui è NATA la programmazione a oggetti e prima
ancora la notazione ungherese, o per cui si parla di "pattern".
 
Io sono pigro, sedentario, e mi stanco facilmente: mi rifiuto, seduto al
volante della mia Panda, di andar piano come quel fermone di Usain Bolt!
Se non riesce a tenere i sessanta all'ora per tre orette, stia a casa, e
lasci correre quelli che sanno.
 
(Sì sì, lo so - il guru del jogging, Nonsokì, raccomanda 10 km/h come la
velocità ideale per ossa e giunture... io raccomando la verde super, poi
vedete se non mi rammentate!)


Lo ripropongo: 
https://ibb.co/cKVUgL
 
 
(So ^Ke molti mi aspettavano al varco da mesi)


 Per altri è cento o trecento.
 
E se dei 300 metodi ne verranno usati solo 3, è cosa buona caricare in 
memoria queste mega classi?
Usare una struttura più modulare non avrebbe anche un miglior impatto 
sulle prestazioni?

sulle prestazioni?
 
Sì, però per capire esattamente quanto, e se convenga, andrebbe visto caso per
caso.


 impostazione un pochino).
 
Quindi non sono completamente pazzo quando dico certe cose :D

 Quindi estraggono (attingono) il codice *dal* trait...
 
Tu, programmatore, estrai il codice IN (moto a luogo) un trait.
 
La classe importa codice DAL (moto da luogo) trait.
 
Bye.

 La classe importa codice DAL (moto da luogo) trait.
 
Ancora c'è qualcuno che usa la lingua italiana correttamente :D

 macchina, all'interprete php, e non alla persona umana (programmatore).
 
Uhm... no. :)
 
Leonardo ha detto a te, programmatore, di prendere il codice da una 
classe e di muoverlo dentro un trait.
 
Scrivere codice è il lavoro del programmatore, non della macchina o 
dell'interprete, quindi "estrai il codice (e mettilo) in un trait" è 
riferito al programmatore, quindi è corretto "in" e non "da".
 
Giusto per fare il grammar nazi. :)
 
Bye.
 

 classe e di muoverlo dentro un trait.
 
Diciamo che non ha usato la dicitura più comune(software side): la 
classe deve estrarre il codice, di cui ha bisogno, dall'apposito trait.
E sono rimasto un po' spiazzato :D

 classe deve estrarre il codice, di cui ha bisogno, dall'apposito trait.
 
Onestamente non l'ho mai sentita, messa così.
 
Al massimo la classe importa (da cui le keyword "import" e "include" 
comuni a molti linguaggi) il codice da un trait, ma "estrarre" ha sempre 
significato "togliere", non "mettere".
 
Bye.


Cmq il verbo esatto (da attribuire al programmatore) sarebbe stato 
*spostare* (non *estrarre*).
"Prendi il codice dalla classe, e lo *sposti* in un trait"