Newsgroup: it.comp.www.php
Titolo: Design patterns

Voi li usate? Ne abusate? Li evitate?
A parte questo ng, che purtroppo non � pi� attivo come un tempo, sapete
se esiste qualche forum/ng attivo in lingua italiana dove discutere di
programmazione in generale, magari con un occhio verso il PHP?
 
-- 
g4b0, linux user n. 369000
http://brosulo.net
 

 programmazione in generale, magari con un occhio verso il PHP?
 
 
li uso
 
 
-- 
Jeff


E ne discuti mai con qualcuno, oppure fai tutto da solo?


 E ne discuti mai con qualcuno, oppure fai tutto da solo?
 
si ne discutevo con i colleghi, ma ormai non piu' il framework che usiamo 
e' implementato, alcune cose le fa bene, altre le fa male, ma ci 
concentriamo ad usarequello che c'e' perche' riscrivere il kernel del 
framework sarebbe un bagno di sangue per tutti i moduli che abbiamo ormai 
gia' scritto
 
 
-- 
Jeff

Il che mi fa pensare che il kernel non sia stato scritto molto SOLIDo
Per mia esperienza serve essere SOLID e per farlo si finisce a scrivere secondo design pattern



 
 
Il framework è open-source? Io comunque cerco, ove necessario, di
implementare design pattern anche al di sopra di framework/cms, ed è per
questo che sto cercando un forum o newsgroup dove poterne discutere nel
dettaglio, magari portando esempi e cercando soluzioni alternative.


On Thu, 05 Jun 2014 14:31:21 +0200, g4b0 scrisse:

no, e' un framework che e' stato costruito nel tempo per il servizio che 
forniamo (piattaforma saas per la distrubuzione di contenuti)
 
L'idea di base e' quella di permettere al framework di funzionare con un 
modello MVC, ma al contempo di poter avere ogni file (interfaccia, 
modello, configurazione ecc) modificabile per le esigenze del singolo 
cliente [lavoriamo in un ambiente saas enterprise dove le esigenze sono 
simili ma non identiche]
 
 
-- 
Jeff

 secondo design pattern
 
il kernel e' stato costruito in diversi anni, da svariati programmatori di 
culture diverse, nope non e' SOLID.
L'unico refactoring che facciamo in via continua e' la pulizia del 
codice, tra l'altro la cosa piu' fastidiosa e' che alcune parti sembrano 
costruite per essere il piu' complesso e cervellotico possibile
 
 
 
-- 
Jeff

 dettaglio, magari portando esempi e cercando soluzioni alternative.
 
Faccio un discorso un po' largo, ma la premessa e la conclusione è che 
nessuno ti vieta di parlarne qui. A me interesserebbe parecchio, anche se 
ultimamente non ho tantissimo tempo per partecipare al ng (praticamente 
solo i weekend).
 
I design patterns sono un argomento abbastanza complesso. Non è che se usi 
tutti i design patterns il tuo software è fatto bene, e se ne salti 
qualcuno è fatto male. Sono dei "canovacci" di come molti prima di noi 
hanno risolto determinati problemi in modo abbastanza generico da poter 
essere applicato ad altri problemi simili.
 
Il problema ora diventa: come si capisce quando un problema è "abbastanza 
simile" da poter applicare lo stesso pattern?
In alcuni casi, addirittura, un design pattern è diventato un anti-
pattern (vedi il singleton, che comunque io in alcuni, rari, casi uso 
ancora).
 
Un altro punto è: hanno senso alcuni design pattern in tutti i linguaggi 
di programmazione o sono nati con determinate limitazioni (C, C++ e Java, 
tipicamente) come prerequisito? E, nel caso, si possono applicare allo 
stesso modo o è meglio fare una modifica al pattern per adeguarlo al 
linguaggio?
 
Poi ci sono quelli che applicano il pattern sbagliato a un problema, 
incasinando la soluzione. :)
 
E quelli che applicano troppi pattern, incasinando la soluzione.
 
Per finire: non sono d'accordo che SOLID e patterns siano in rapporto 1:1.
Si aiutano a vicenda, e rispettare SOLID è forse più semplice usando 
determinati pattern. Sempre ammesso che si possa definire "semplice" fare 
SOLID... :P
 
Bye.

 SOLID... :P
 
Be, se fosse semplice non saremmo qui a parlarne, no? Tra l'altro
cercando risorse su SOLID mi sono imbattuto in GRASP, che non conoscevo:
http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
 
 
Certo che come acronimo non è proprio il massimo :P


 Wordpress?
 
Purtroppo sì. Sia moduli che temi (che sono veramente il male).
 
Bye.

 gira intorno.
 
Non conoscevo i DIC, ed a prima vista non posso che essere d'accordo con
te. Ho visto pimple, scritto dall'autore di Symfony, ma non riesco ad
immaginarne un utilizzo al di fuori degli internals un framework.


 immaginarne un utilizzo al di fuori degli internals un framework.
 
Io lo sto usando con Silex. Di suo, in realtà, ha senso solo in 
un'applicazione più che in un framework.
E Pimple è tra i miglior, secondo me, pensa gli altri! :)
 
Per fare un esempio veloce, io nel bootstrap posso dichiarare
 
$app['pdo'] = $app->share(function() use ($app) {
 return new \Pdo('...');
});
 
$app['db.news'] = $app->share(function() use ($app) {
 return new \Model\News($app['pdo']);
});
 
E, nel controller,
 
public function indexAction(Application $app)
{
  $news = $app['db.news']->findAll();
  ...
}
 
Quello che fa è fare un lazyload del model News, che a sua volta fa un 
lazy load del Pdo.
 
Visto così non sembra niente male, ed è anche utile, ma:
 
- Devi sempre passare l'oggetto Application, che a questo punto tanto 
vale diventi un singleton. Non credo ci siano DIC che usano la stessa 
sintassi, quindi tanto vale usare il riferimento diretto.
 
- Devi ricordarti cosa hai definito nel DIC (era "db.news" o 
"db.newscollection", o "news", o qualcos'altro?), costringendoti ad avere 
una "visione" più vasta dell'applicazione, mandando a donnine il concetto 
di località.
 
- Perdi l'autocomplete dell'editor. Non ha idea di cosa ci sia nell'array 
a quella posizione, a meno di non "forzarlo" con un DocBlock.
 
Come ho detto, Pimple/Silex è uno dei migliori. Almeno scrivi il codice 
invece di compilare 3-4 file di configurazione sparsi in giro per il 
progetto, con sintassi per conto loro come fa ZF2.
 
Ma, visto che è comunque lazy load, cosa mi vieta di fare
 
class Appplication
{
  static public function getPdo() {
   static $pdo;
   if (is_null($pdo)) {
    $pdo = new Pdo(...);
   }
   return $pdo;
 }
}
 
class MioController {
 public function indexAction()
 {
   $news = (new Model\News(Application::getPdo()))->findAll();
   ...
 }
}
 
Ripeto: è un esempio stupido. :)
Lo svantaggio è che se voglio usare un model diverso devo andare a 
cercarmi in tutti i controller l'istanziazione.
Allora risolviamo con un Factory:
 
class Models
{
 static public function getNews()
 {
  return new Model\News(Application::getPdo());
 }
}
 
e nel controller
 
$news = Models::getNews()->findAll();
 
A questo punto molti IDE (PhpStorm lo fa, gli altri non so, ma penso di 
sì) si accordono del tuo "return oggetto" in getNews e ti fanno 
l'autocomplete di findAll().
In più hai l'autocomplete di getNews statico (per lo stesso motivo), e 
non devi ricordarti il nome dell'indice di un array.
 
Non è che sia importante per l'automplete in sè (anche se accelera molto 
lo sviluppo), ma soprattutto perché hai un check statico (prima 
dell'esecuzione), che in un linguaggio dinamico è più importante che non 
in uno compilato. E automatico, senza dover usare lint o simili (che 
comunque non credo riuscirebbero a risolverlo).
 
Altri vantaggi: "spalmi" le configurazioni, ma in modo logico. La 
configurazione dei model va nella directory coi model, e addirittura può 
essere suddivisa per moduli (Prodotti\Model\News gestito da Prodotti
\Models.php e Magazzino\Model\News gestito da Magazzino\Models.php invece 
che tutto centralizzato in un bootstrap chilometrico)
 
Puoi cambiare il Model\News in qualsiasi momento (rispettando 
l'interfaccia) semplicemente cambiando il factory.
 
Vantaggio del DIC: puoi cambiare totalmente il modulo con un altro, ma 
per esperienza mia non capita mai, perché non ci sono mai due moduli con 
esattamente la stessa interfaccia (parlo di API, non di UI), e in ogni 
caso ti servirebbe un "supermodulo" che definisca l'interfaccia, 
altrimenti ne duplichi la dichiarazione e a quel punto perdi tutti i 
vantaggi.
 
OK, praticamente ho scritto buona parte del post che volevo fare sul 
blog. :D
Spero di non essere stato troppo stringato o criptico.
 
Bye.