Giù al RomeCamp ci siamo ingarellati io, Kia, Giovanni e Bard a
discutere se i pattern fossero na roba seria o solo una soluzione a
problemi espressivi del linguaggio su cui si usano…
Ovviamente si parlava di Java e affini. Ho scoperto solo ora questo
link:
dove spiegano i GOF in Ruby. Mò me lo leggo… voi che ne pensate?
Quante volte avete effettivamente utilizzato dei pattern in ruby?
quali?
La situazione peggiora in Rails visto che l’80% delle applicazioni è
leggi/scrivi… Ma magari c’è qualche contesto dove sono +
interessanti/utili.
Lancio il sasso giusto per aprire un confronto… in che casi
utilizzate gli observer di ActiveRecord? Avete mai avuto bisogno di
utilizzare Observer cross-model tipo gli sweeper della cache?
Personalmente ritengo che la conoscenza di cosa sia un pattern, di come
si applica e del concetto di “refactoring to pattern” sia essenziale per
ogni programmatore e ingegnere del software.
Giovanni
penso che molti bravi sviulppatori abbiano comunque un pattern instinct,
pur
non conoscendo i patterns, e credo anche che i patterns emergano dal
refactoring in modo naturale.
io li trovo impagabili per comunicare delle scelte di design ad altri
sviluppatori. I patterns sul sito indicato da Paolo non sono molto
utili in
ruby, ma di certo anche in ruby di patterns e idiomi originali ne avete
visti.
Il giorno gio, 01/02/2007 alle 23.10 +0100, Paolo Donà ha scritto:
Giù al RomeCamp ci siamo ingarellati io, Kia, Giovanni e Bard a
discutere se i pattern fossero na roba seria o solo una soluzione a
problemi espressivi del linguaggio su cui si usano…
Ovviamente si parlava di Java e affini. Ho scoperto solo ora questo link:
dove spiegano i GOF in Ruby. Mò me lo leggo… voi che ne pensate?
Quante volte avete effettivamente utilizzato dei pattern in ruby?
quali?
La libreria standard di Ruby implementa molti pattern:
#each è un esempio dell’Iterator e del Template Method
TestCase e TestSuite sono un esempio di Decorator
In generale, può essere utile vedere un pattern come un template per una
(possibile) soluzione ad un certo problema. Template nel senso che ogni
pattern dovrà essere adattato allo specifico problema che si vuole
risolvere.
Il pattern può essere integrato nella libreria standard, oppure deve
essere lo sviluppatore ad implementarlo, a seconda dell’espressività del
linguaggio.
Personalmente ritengo che la conoscenza di cosa sia un pattern, di come
si applica e del concetto di “refactoring to pattern” sia essenziale per
ogni programmatore e ingegnere del software.
penso che molti bravi sviulppatori abbiano comunque un pattern instinct, pur
non conoscendo i patterns, e credo anche che i patterns emergano dal
refactoring in modo naturale.
+1
Quando ho visto per la prima volta il libro sul “refactoring”, mi sono
detto “ah… fossi stato cosi` sveglio io a tirare fuori un libro
delle conoscenze che dovrebbero avere tutti gli sviluppatori”.
Il giorno ven, 02/02/2007 alle 00.09 +0100, chiaro scuro ha scritto:
Personalmente ritengo che la conoscenza di cosa sia un pattern, di come
si applica e del concetto di “refactoring to pattern” sia essenziale per
ogni programmatore e ingegnere del software.
Giovanni
penso che molti bravi sviulppatori abbiano comunque un pattern instinct, pur
non conoscendo i patterns, e credo anche che i patterns emergano dal
refactoring in modo naturale.
Sono d’accordo. Però saper fare queste cose in maniera esplicita
piuttosto che instintiva spesso ti dà una marcia in più.
io li trovo impagabili per comunicare delle scelte di design ad altri
sviluppatori. I patterns sul sito indicato da Paolo non sono molto utili in
ruby, ma di certo anche in ruby di patterns e idiomi originali ne avete
visti.
Non penso che non siano molto utili. Tempo fa mi sono dedicato alla
scrittura di un piccolo text editor, come esercizio per imparare le
librerie Ruby-Gnome2, ed ho usato vari pattern presenti in quella lista.
penso che molti bravi sviulppatori abbiano comunque un pattern instinct,
pur
Sono d’accordo. Però saper fare queste cose in maniera esplicita
piuttosto che instintiva spesso ti dà una marcia in più.
si, vero. aggiungo però che la grande sfida poi però è dimenticarseli e
riaffidarsi all’istinto. in questo aiuta tantissimo il refactoring, per
riacquistare una certa naturalezza di movimento.
quando impari i pattern ti viene spesso da implementarli in modo
completo,
canonico… e spesso non è necessario. se li evolvi via refactoring questo
non succede ed i tuoi gesti risultano molto più fluidi e puliti.
io li trovo impagabili per comunicare delle scelte di design ad altri
sviluppatori. I patterns sul sito indicato da Paolo non sono molto
utili in
ruby, ma di certo anche in ruby di patterns e idiomi originali ne avete
visti.
Non penso che non siano molto utili. Tempo fa mi sono dedicato alla
scrittura di un piccolo text editor, come esercizio per imparare le
librerie Ruby-Gnome2, ed ho usato vari pattern presenti in quella lista.
ma non trovi che molti pattern ‘classici’ evaporino in ruby? tanti di
quei
pattern ad esempio servono per aggirare i limiti di un linguaggio
statically
typed.
penso che molti bravi sviulppatori abbiano comunque un pattern instinct, pur
non conoscendo i patterns, e credo anche che i patterns emergano dal
refactoring in modo naturale.
Sono d’accordo. Però saper fare queste cose in maniera esplicita
piuttosto che instintiva spesso ti dà una marcia in più.
Qualche eresia da tarda ora (Paolo, tieni pronte le magiche parole
pacificatrici):
Queste cose le facciamo in maniera esplicita al posto di, non oltre a,
farle in maniera istintiva.
Il rapporto tra materiale letto e materiale scritto è, per un
programmatore, imbarazzante, al confronto del rapporto tra materiale
letto e materiale scritto, per uno scrittore.
Leggendo poco codice, ci sono poche occasioni di “assorbire”, e si
cerca di compensare con l’“imparare”, e con la pratica che, qualche
volta, riesce a diventare seconda natura.
Se si vuole scrivere un buon romanzo, un testo di grammatica e un
manuale di stile potrebbero non essere sufficiente.
ma non trovi che molti pattern ‘classici’ evaporino in ruby? tanti di quei
pattern ad esempio servono per aggirare i limiti di un linguaggio statically
typed.
In realtà non direi. Quello che capita è che alcuni pattern siano
talmente ubiqui nella libreria standard che se non ci si fa attenzione
non si pensa ad essi come pattern. #each implementa il pattern Iterator,
ad esempio. #new implementa il Factory Method. #initialize è un Template
Method.
Verissimo. Non ci avevo mai pensato, ma è proprio così. Leggo molto
meno codice di romanzi e il mio lavoro è scrivere codice tutto il
giorno…
Massimiliano => EyeOpeningPost™
Massimiliano M. wrote:
On 2/2/07, Giovanni C. [1]<[email protected]> wrote:
> penso che molti bravi sviulppatori abbiano comunque un pattern
instinct, pur
> non conoscendo i patterns, e credo anche che i patterns emergano
dal
> refactoring in modo naturale.
Sono d'accordo. Però saper fare queste cose in maniera esplicita
piuttosto che instintiva spesso ti dà una marcia in
più.
Qualche eresia da tarda ora (Paolo, tieni pronte le magiche parole
pacificatrici):
Queste cose le facciamo in maniera esplicita al posto di, non oltre
a,
farle in maniera istintiva.
Il rapporto tra materiale letto e materiale scritto è, per un
programmatore, imbarazzante, al confronto del rapporto tra
materiale
letto e materiale scritto, per uno scrittore.
Leggendo poco codice, ci sono poche occasioni di “assorbire”, e si
cerca di compensare con l’“imparare”, e con la pratica che, qualche
volta, riesce a diventare seconda natura.
Se si vuole scrivere un buon romanzo, un testo di grammatica e un
manuale di stile potrebbero non essere sufficiente.
–
“Remember, always be yourself. Unless you suck.” - Joss Whedon
ma dai che l’ho pure letto ed è leggibilissimo. è un codice onesto.
mi ricordo che mi aveva colpito il codice di ROXI di Lana, perchè essendo
scritto in C ed essendo leggibile, mi aveva fatto capire che non avevo
capito nulla di C. io potrei riprendere e commentare parti di quello. ( http://ruby-it.org/pages/Roxi )
non riesco però più a rintracciare il codice… gabriele, se sei in ascolto
Con il mio post non sono però riuscito ad imprimere al thread il taglio che
desideravo, ovvero la pragmaticità… con questo che voglio dire? Siamo
tutti appassionati di software e molti di leggono/hanno letto libri a
riguardo, se ci mettiamo a discutere su quanto siano
belli/brutti/importanti/inutili i pattern in questo/quel linguaggio
potremmo
andare avanti per anni, senza però condensare in codice e conoscenza. Prova
ne è il fatto che in 11 risposte al mio post non è presente una linea di
codice.
Riusciamo a portare qualche esempio pratico di utilizzo dei pattern?
Ovvero
riusciamo a dimostrare quando il pattern ha risolto un problema in un
dominio specifico?
Parto io per dare uno spunto anche se è banale:
A me il singleton ha reso possibile la definizione statica dei tabnav.
Quando fate un Tabnav fate:
class MyTabnav < Tabnav::Base
add_tab do
named ‘something’
links_to :controller => ‘fake’
end
end
add_tab è un metodo di classe definito Tabnav::Base ma quando lo chiamo
deve
aggiungere un tab in MyTabnav non in Tabnav::Base, quindi la list dei
tab
non deve essere un attributo di classe in Tabnav::Base altrimenti
verrebbe
condiviso tra tutti i tabnav dell’applicazione.
Io ho risolto con il singleton in questo modo:
require ‘singleton’
module Tabnav
class Base
include Singleton
attr_accessor :tabs
def self.add_tab &block
raise "you should provide a block" if !block_given?
instance.tabs ||= []
instance.tabs << Tabnav::Tab.new(&block)
end
private
def initialize
@tabs = []
end
end
end
In questo modo ogni classe che estende Tabnav::Base ha il suo singleton
e i
suoi tab. Chennesò, magari c’è un modo migliore di farlo… ma quello che
volevo ottenere è una discussione su roba ‘vera’.
Attendo ansiosamente riscontri (con codice, ovvio :-))
Spiacente deluderti, ma continuo con la filosofia!
Una cosa che mi sembra importante da rimarcare e’ che in genere i
pattern non sono il modo piu’ semplice per fare una cosa, a volte puo’
essere cosi’, ma non e’ quello il punto, non nascono per quello. I
pattern servono a rendere il codice piu’ flessibile, quindi non ha tanto
senso dire “io ho risolto questo problema cosi’, con questo pattern”,
quanto “usando questo pattern ho risolto questo problema, e se cambia x,
y o z non devo riscrivere tutto”
ma non trovi che molti pattern ‘classici’ evaporino in ruby? tanti di
quei
pattern ad esempio servono per aggirare i limiti di un linguaggio
statically
typed.
Beh, alcuni pattern potrebbero pure essere obsoleti, ma non certo
pensati per linguaggi statically typed: il libro contiene sia
implementazioni C++ che Smalltalk!
Beh, alcuni pattern potrebbero pure essere obsoleti,
ma non certo
pensati per linguaggi statically typed: il libro
contiene sia
implementazioni C++ che Smalltalk!
-1, anche se lo dico dopo 5 bottiglie di vodka a
cracovia e giusto per spirito polemico…
I pattern imo non sono mai obsoleti, imho. ma va detto
che non sonoi sempre necessari.
Invito i lettori a cercare su internet “design pattern
in dynamic languages” di peter norvig (o qualcosa del
genere, google aiutera’).
In praTICA IL succo e’ che alcuni pattern sono
non-pattern in linguaggi di “livello superiore”,
qualsiasi cosa esso significhi. if-then-else in
assembly e’ un pattern, perche’ non e’ esprimibile con
le istruzioni della maggior parte delle cpu, ma e’
comunque uno schema che viene ripetuto spessissimo.
Ma in C o in qualsiasi linguaggio di alto livello,
non ha alcun senso parlare di “pattern per le
condizioni ternarie”, perchE’ esiste gia’ come parte
del linguaggio.
Ruby fino ad un certo punto permette di raggiungere
livelli di astrazione che trasformano un pattern in
una libreria (i.e. forwardable o singleton), e quindi
permettono di fattorizzare anche un qualcosa di
ripetitivo in una libreria, fatto che probabilmente
dice qualcosa a proposito dell’espressivita’ del
linguaggio.
Ovviamente lisp ed altri linguaggi permettono di
raggiungere livelli di astrazione anche piu’ alti
(giovanni, lo so che Smalltalk permette di raggiungere
questi livelli ma non lo dico perchE’ la mia
impressione e’ che generalmente non si faccia).
Ad ogni modo, la mia opionione e’ che i pattern non
siano mai inutili in assoluto, per la semplice ragione
che rappresentano stili di codice che sono stati visti
molte volte in azione (a differenza ad esempio del
“borg nonpattern” di alex martelli in python che
risolve gli stessi problemi del singleton ma e’ stato
creato a tavolino, e non estratto da ambienti di
produzione).
Al massimo alcuni pattern sono impliciti nel
linguaggio o nella libreria.
Riusciamo a portare qualche esempio pratico di utilizzo dei pattern? Ovvero
riusciamo a dimostrare quando il pattern ha risolto un problema in un
dominio specifico?
Mi sono trovato a mettere codice che gestisce comunicazioni di rete (o
altre comunicazioni asincrone) in una certa forma ricorrente. Una
forma ricorrente è un pattern, ma non so se questa abbia un nome…
Esempio: invio un comando all’altro lato della connessione, e quando
arriva la risposta reagisco in qualche modo (es. mostro un requester).
Il programma nel frattempo non deve congelarsi. Di solito si
avrebbero tutti i gestori di input remoto in un unico luogo, attivati
da un evento basato sulla categoria dell’input. A me servivano
gestori one-shot e serviva vederli in modo lineare. Pseudocodice:
Il giorno ven, 02/02/2007 alle 20.51 +0000, gabriele renzi ha scritto:
typed.
che non sonoi sempre necessari.
Ma in C o in qualsiasi linguaggio di alto livello,
linguaggio.
Ovviamente lisp ed altri linguaggi permettono di
raggiungere livelli di astrazione anche piu’ alti
(giovanni, lo so che Smalltalk permette di raggiungere
questi livelli ma non lo dico perchE’ la mia
impressione e’ che generalmente non si faccia).
Ad ogni modo, la mia opionione e’ che i pattern non
siano mai inutili in assoluto, per la semplice ragione
che rappresentano stili di codice che sono stati visti
molte volte in azione (a differenza ad esempio del
“borg nonpattern” di alex martelli in python che
risolve gli stessi problemi del singleton ma e’ stato
creato a tavolino, e non estratto da ambienti di
produzione).
Al massimo alcuni pattern sono impliciti nel
linguaggio o nella libreria.
Più che altro certi pattern diventano talmente integrati nel linguaggio
o nella libreria che diventano degli standard: non più una soluzione tra
tante possibili, ma la soluzione.
Il giorno dom, 04/02/2007 alle 21.26 +0100, Antonio T. ha scritto:
Domanda: come fai il refactoring con ruby?
Si parlava in lista di komodo, ha un menù per il refactoring stile
eclipse?
L’argomento mi interessa molto. Diverse persone mi hanno sempre detto
a proposito dei dynamic language, ok son carini ma il refactoring?
In generale, la tipizzazione dinamica non è un problema (I tool
automatici per il refactoring sono apparsi prima in ambito Smalltalk -
con il refactoring browser - che in Java). Ci sono però altri problemi,
relativi al modo in cui il linguaggio è organizzato che rendono più
complicata la creazione di un tool automatico.
Questo non è comunque un problema così grosso come possa sembrare a
prima vista: la maggiore espressività di Ruby rispetto ad altri
linguaggi in genere rende gestibile applicare i refactoring a mano.
