Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #22291 > unrolled thread

raggruppamento delle variabili

Back to article view | Back to it.comp.www.php

Contents

  raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-13 12:42 +0200
    Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-13 13:42 -0700
      Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-14 13:08 +0200
        Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-14 04:16 -0700
          Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-14 15:48 +0200
            Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-14 12:13 -0700
              Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-14 22:24 +0200
                Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-15 00:20 +0200
                  Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-15 18:26 +0200
                    Re: raggruppamento delle variabili Flavix <imeil@a.a> - 2018-10-17 17:45 +0200
                    Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-18 22:45 +0200
                      Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-18 15:45 -0700
                        Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-20 16:16 +0200
                          Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-21 11:46 +0200
                            Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-21 13:12 +0200
                              Re: raggruppamento delle variabili Flavix <imeil@a.a> - 2018-10-21 14:26 +0200
                                Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-21 15:07 +0200
                                  Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-21 15:11 +0200
                      Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-19 22:35 +0200
                        Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-20 22:36 +0200
                          Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-21 11:56 +0200
                            Re: raggruppamento delle variabili Leonardo Serni <lserni@gmail.com> - 2018-10-21 13:13 +0200
                            Re: raggruppamento delle variabili Alessandro Pellizzari <shuriken@amiran.it> - 2018-10-22 10:11 +0100
                              Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-22 13:35 +0200
                                Re: raggruppamento delle variabili Alessandro Pellizzari <shuriken@amiran.it> - 2018-10-22 12:55 +0100
                                  Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-22 17:19 +0200
                                    Re: raggruppamento delle variabili Alessandro Pellizzari <shuriken@amiran.it> - 2018-10-22 16:31 +0100
                                      Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-22 17:56 +0200
                Re: raggruppamento delle variabili fmassei@gmail.com - 2018-10-14 21:38 -0700
                  Re: raggruppamento delle variabili alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-10-15 19:09 +0200
                  Re: raggruppamento delle variabili Flavix <imeil@a.a> - 2018-10-17 17:52 +0200

Page 1 of 2  [1] 2  Next page →

#22291 — 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

[toc] | [next] | [standalone]

#22294

On Saturday, October 13, 2018 at 6:42:10 AM UTC-4, alex wrote:
> 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!

[toc] | [prev] | [next] | [standalone]

#22295

Il 13/10/2018 22:42, fmassei@gmail.com ha scritto:
> Quando si programma in team le convenzioni sono tanto importanti quanto
> le regole del linguaggio, beh, quasi.
> 

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

[toc] | [prev] | [next] | [standalone]

#22296

On Sunday, October 14, 2018 at 7:12:34 AM UTC-4, alex wrote:
> Il 13/10/2018 22:42, fmassei@gmail.com ha scritto:
> > Quando si programma in team le convenzioni sono tanto importanti quanto
> > le regole del linguaggio, beh, quasi.
> > 
> 
> 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!

[toc] | [prev] | [next] | [standalone]

#22297

Il 14/10/2018 13:16, fmassei@gmail.com ha scritto:
> On Sunday, October 14, 2018 at 7:12:34 AM UTC-4, alex wrote:
>> Il 13/10/2018 22:42, fmassei@gmail.com ha scritto:
>>> Quando si programma in team le convenzioni sono tanto importanti quanto
>>> le regole del linguaggio, beh, quasi.
>>>
>>
>> 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)?

[toc] | [prev] | [next] | [standalone]

#22298

On Sunday, October 14, 2018 at 9:52:34 AM UTC-4, alex wrote:
> <snip>
> 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!

[toc] | [prev] | [next] | [standalone]

#22299

Il 14/10/2018 21:13, fmassei@gmail.com ha scritto:
> On Sunday, October 14, 2018 at 9:52:34 AM UTC-4, alex wrote:
>> <snip>
>> 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,

Cioè le funzioni ereditate?

> 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.

[toc] | [prev] | [next] | [standalone]

#22300

On Sun, 14 Oct 2018 22:24:45 +0200, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>Anche se l'ideale sarebbe avere micro-classi (con non più di tre metodi):

>getInstance() (se la classe è singleton)
>costruttore
>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" :-) :-(

[toc] | [prev] | [next] | [standalone]

#22302

Il 15/10/2018 00:20, Leonardo Serni ha scritto:
> On Sun, 14 Oct 2018 22:24:45 +0200, alex
> <1j9448a02@lnx159sneakemail.com.invalid> wrote:
> 
>> Anche se l'ideale sarebbe avere micro-classi (con non più di tre metodi):
> 
>> getInstance() (se la classe è singleton)
>> costruttore
>> metodo principale della classe
> 
> Dipende da cosa stai facendo. Ho un oggetto Documento che deve implementare
> read(), write(), validate() e submit(); 

- se i metodi sono molto corposi
- se quindi alcuni di loro è meglio che vengano spezzettati in metodi 
più piccoli e più leggibili
- se comincio ad avere una classe con quasi 10 metodi...

...mi è già venuto il panico :D

> 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.

Estrarre in un trait?

[toc] | [prev] | [next] | [standalone]

#22310

Il 15/10/2018 18:26, alex ha scritto:
> 
> - se i metodi sono molto corposi
> - se quindi alcuni di loro è meglio che vengano spezzettati in metodi 
> più piccoli e più leggibili
> - se comincio ad avere una classe con quasi 10 metodi...
 >
> ...mi è già venuto il panico :D

Io non lo trovo così sbagliato il tuo ragionamento :D

>> 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.
> 
> Estrarre in un trait?

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

[toc] | [prev] | [next] | [standalone]

#22312

On Mon, 15 Oct 2018 18:26:51 +0200, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>> Dipende da cosa stai facendo. Ho un oggetto Documento che deve implementare
>> read(), write(), validate() e submit(); 

>- se i metodi sono molto corposi
>- se quindi alcuni di loro è meglio che vengano spezzettati in metodi 
>più piccoli e più leggibili
>- se comincio ad avere una classe con quasi 10 metodi...

>...mi è già venuto il panico :D

Apro una parentesi noiosa.

Posso elencare una quantità di azioni che nessun essere umano può fare, o è
mai stato in grado di fare. Sopportare fiamme a 1500 °C, sollevare masse di
tonnellate, respirare sott'acqua, volare, entrare in orbita, riprodurre una
immagine in modo visualmente perfetto, ricordare un miliardo di volumi dopo
dieci anni di tempo e ripeterli al contrario, sommare mille numeri di mille
cifre in un millesimo di secondo.

Tutte queste cose però diventano possibili e molte addirittura facilissime,
con l'equipaggiamento giusto e un minimo di tempo per imparare a usarlo.

Ora, tu mi vieni a dire che ti viene il panico a coordinare dieci metodi in
una classe. Ti credo senz'altro, e ti dico infatti la stessa cosa che direi
a un tizio che mi dicesse che non è in grado di sollevare un macigno di due
tonnellate: "amico, tu sbagli candeggio".

Chiusa parentesi.

In un progetto a cui sto lavorando la media è 23.7 metodi per classe - se si
contano le classi un minimo complesse, con costruttori:

	$ for f in $( grep -lr "function __construct" \
	 leonardo/htdocs/{base,local} --include="*.php" ); do \
	 grep -n "^[a-z ]*function" $f | wc -l; done | wc -l
	99
	$ ( for f in $( grep -lr "function __construct" \
         leonardo/htdocs/{base,local} --include="*.php" ); do \
	 grep -n "^[a-z ]*function" $f | wc -l; done | sort -n \
	| tr "\n" "+" ; echo "0" ) | bc
	2346

I file di cui ricordo a memoria cosa c'è dentro sono SETTE. In tre casi, non
escludo di ricordarmi giusto; ma non ci conterei molto. Negli altri quattro,
è pressoché sicuro che mi ricordi male.

Calcola che ci ho lavorato l'ultima volta oggi pomeriggio :-)

Come si fa? Con lo strumento. Eclipse, PHPStorm, Netbeans, VisualCode, forse
SubLime.

>> 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.

>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.

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#22313

On Thursday, October 18, 2018 at 4:45:06 PM UTC-4, Leonardo Serni wrote:
> On Mon, 15 Oct 2018 18:26:51 +0200, alex
> >...mi è già venuto il panico :D
> 
> Apro una parentesi noiosa.
> 
> <snip>
> I file di cui ricordo a memoria cosa c'è dentro sono SETTE.
> <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!

[toc] | [prev] | [next] | [standalone]

#22315

On Thu, 18 Oct 2018 15:45:43 -0700 (PDT), fmassei@gmail.com wrote:

>> Apro una parentesi noiosa.

>> <snip>
>> I file di cui ricordo a memoria cosa c'è dentro sono SETTE.
>> <snip>

>Hai preso un fattoide famoso, l'hai messo in un altro contesto

Coincidenza. Sono realmente sette perché erano i file che avevo esaminato
negli ultimi due giorni. Altri giorni potrebbero essere dieci, o uno.

> e l'hai interpreato a cacchio

Uh, no. Non l'ho interpretato proprio... "sette" era una coincidenza. Non
ho mai fatto il conto del numero di parametri di cui tenere traccia.

Come regola, le mie funzioni hanno al massimo tre parametri. Magari uno o
due (o tutti e tre) sono oggetti complessi, questo sì.

>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.

Questa è pure la mia opinione :-)

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#22317

Il 20/10/18 16:16, Leonardo Serni ha scritto:
>> 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.
> Questa è pure la mia opinione

https://ibb.co/cKVUgL
vedere le parte iniziale (post di un certo Alessandro Pellizzari)

[toc] | [prev] | [next] | [standalone]

#22319

On Sun, 21 Oct 2018 11:46:44 +0200, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>Il 20/10/18 16:16, Leonardo Serni ha scritto:
>>> 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.
>> Questa è pure la mia opinione

>https://ibb.co/cKVUgL
>vedere le parte iniziale (post di un certo Alessandro Pellizzari)

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!)

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#22321

Il 21/10/2018 13:12, Leonardo Serni ha scritto:
> On Sun, 21 Oct 2018 11:46:44 +0200, alex
> <1j9448a02@lnx159sneakemail.com.invalid> wrote:
> 
>> Il 20/10/18 16:16, Leonardo Serni ha scritto:
>>>> 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.
>>> Questa è pure la mia opinione
> 
>> https://ibb.co/cKVUgL
>> vedere le parte iniziale (post di un certo Alessandro Pellizzari)
> 
> 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.

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?

[toc] | [prev] | [next] | [standalone]

#22322

On Sun, 21 Oct 2018 14:26:47 +0200, Flavix <imeil@a.a> wrote:

>E se dei 300 metodi ne verranno usati solo 3, è cosa buona caricare in 
>memoria queste mega classi?

Se ne verranno usati solo tre, è autoevidente che la classe può funzionare
anche solo con quei tre. A quel punto avrebbe senso estrarli e fare:

	class PiccolaClasse {
		...3 metodi...
	}	

	class GrossaClasse extends PiccolaClasse {
		...297 metodi...
	}

e magari pure mettere classi intermedie senza invocare ogni volta l'intero
Leviatano. Per esempio (me lo sono tolto di testa ora e potrebbe contenere
errori):

	class FileSuDatabase
		protected $filedata;
		init(DatabaseConnection $conn)
		scrivi(nomefile)
		leggi(nomefile)
		stato(nomefile)
		elenca(pattern)
		elimina(nomefile)

	class Immagine {
		trait FileSuDisco
		resize()
		recolor()
		palette()
		rotate()
		floodfill()
		rectangle()
		ellipse()
		...
	}

	class ImmagineSuDatabase extends Immagine {
		trait FileSuDatabase
		public function construct(DatabaseConnection $conn) {
			if (!$conn->isOpen()) {
				throw new \Exception('need live conn');
			}
			$this->init($conn);
			parent::__construct();
		}
		// dovrebbe funzionare già così.
	}

	class FatturaSuDatabase extends Fattura }
		trait FileSuDatabase
		// Stesso costruttore. Chissà se posso fare un override di un
		// costruttore definito in un trait? Bisogna che controlli.
	}

A quel punto se mi serve una fattura con persistenza su disco, mi importo solo
lo stretto indispensabile; non creerò certo mai "ImmagineSalvaOvunque" che può
lavorare su Dropbox, Google Drive, NFS, FTP, SFTP, Samba, disco e database (ed
anzi, per supportare dei database diversi mi converrebbe cambiare anche questa
impostazione un pochino).
		
>Usare una struttura più modulare non avrebbe anche un miglior impatto 
>sulle prestazioni?

Sì, però per capire esattamente quanto, e se convenga, andrebbe visto caso per
caso.

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#22323

Il 21/10/2018 15:07, Leonardo Serni ha scritto:
> A quel punto se mi serve una fattura con persistenza su disco, mi importo solo
> lo stretto indispensabile; non creerò certo mai "ImmagineSalvaOvunque" che può
> lavorare su Dropbox, Google Drive, NFS, FTP, SFTP, Samba, disco e database (ed
> anzi, per supportare dei database diversi mi converrebbe cambiare anche questa
> impostazione un pochino).

Quindi non sono completamente pazzo quando dico certe cose :D

[toc] | [prev] | [next] | [standalone]

#22314

Il 18/10/2018 22:45, Leonardo Serni ha scritto:
> Apro una parentesi noiosa.
> 
> Posso elencare una quantità di azioni che nessun essere umano può fare, o è
> mai stato in grado di fare. Sopportare fiamme a 1500 °C, sollevare masse di
> tonnellate, respirare sott'acqua, volare, entrare in orbita, riprodurre una
> immagine in modo visualmente perfetto, ricordare un miliardo di volumi dopo
> dieci anni di tempo e ripeterli al contrario, sommare mille numeri di mille
> cifre in un millesimo di secondo.
> 
> Tutte queste cose però diventano possibili e molte addirittura facilissime,
> con l'equipaggiamento giusto e un minimo di tempo per imparare a usarlo.

Quindi è sbagliato ad esempio mettere tutte le funzioni di formattazione 
in una classe (tool) a parte, che mi permette di concentrarmi solo su 
quell'aspetto?

> I file di cui ricordo a memoria cosa c'è dentro sono SETTE.

Fin qui ti seguo, poi insomma...

> In tre casi, non
> escludo di ricordarmi giusto; ma non ci conterei molto.

ricorarmi giusto (o sbagliato)????
???? :D

> Negli altri quattro,
> è pressoché sicuro che mi ricordi male.

???? :D
E gli altri cinque chi sono? E i ricordi come sono a colori o in bianco 
e nero? :D
Neanch'io ci conterei molto, anzi preferisco non fidarmi :D

>> 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;
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

E questo si chiama "estrarre il codice in una trait" o "estrarre il 
codice da una trait"?

[toc] | [prev] | [next] | [standalone]

#22316

On Fri, 19 Oct 2018 22:35:43 +0200, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>> Tutte queste cose però diventano possibili e molte addirittura facilissime,
>> con l'equipaggiamento giusto e un minimo di tempo per imparare a usarlo.

>Quindi è sbagliato ad esempio mettere tutte le funzioni di formattazione 
>in una classe (tool) a parte, che mi permette di concentrarmi solo su 
>quell'aspetto?

In generale credo non ci sia niente di sbagliato... e niente di giusto;
bisogna capire come vanno le cose nell'economia di quel progetto.

>>> Estrarre in un trait?

>> class Qualsiasi
>> {
>>      use \Traits\SimpleSingleton;
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> 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.

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | it.comp.www.php

csiph-web