Nel dettaglio: ho uno script che prende in automatico dei dati da risorse su web, e poi fa un grafico con i cambiamenti, insomma una scopiazzatura di EhList, fatta per giocare con le api di Yahoo! SiteExplorer in ruby

Poiché i servizi sono tutti differenti esiste un metodo specifico per accedere ad ognuno di essi, catturato nell’esistenza di una classe Provider e di varie sottoclassi, ognuna con una descrizione, un metodo specifico per recuperare le informazioni remote ed eventuali altre cose.

Un esempio di provider è:

class YahooProvider < Provider
  DESC=\"Yahoo SE inbound links\"
  APPID=\"myAppId\"
  URL=\"url yahoo SE?query=%s&appid=%s\"
  def initialize(name)
    text=open(URL%[name,APPID]).read
    @result=Mapping.xml2obj(text)
  end
  def results_size
    @result.xmlattr_totalResultsAvailable
  end
end

se state imprecando contro di me perché non chiudo la connessione aperta con open() potete calmarvi, lo script completa le operazioni in meno di un minuto e si chiude, il che fa si che le risorse vengano comunque recuperate.

Ora: come testare questo provider? In particolare, come testare l’operazione di parsing dell’xml?
La cosa più ovvia è passargli dei dati preconfezionati, magari presi da un’esecuzione precedente dello script, e verificare che li interpreti correttamente.
Solo che è il metodo initialize ad eseguire sia la letttura dei dati che il parsing.
La soluzione che permette di testare meglio tutto ciò è di spostare queste funzionalità in un altro posto per poterle testare in isolamento, con una cosa come questa:

  def read_data()
    open(URL%[name,APPID]).read
  end
  def parse(xml)
    Mapping.xml2obj(xml)
  end
  def initialize(name)
    testo=read_data()
    @result= parse(testo)
  end

Se è vero che questo approccio introduce una certa flessibilità è anche vero che si tratta di una flessibilità non necessaria, o meglio di una fattorizzazione del codice in più parti che però non è utile in quanto non userò mai una delle funzionalità separatamente dall’altra.
Insomma, sto facendo una cosa di cui non ho bisogno solo per far felici i test, che non è una cosa terribile, ma la eviterei.

Ma, se siete arrivati a leggere fin qui probabilmente sapete già cosa possiamo fare in questo caso:

require 'stringio'
special Kernel, \"open\" do
  StringIO.new(\"xml di prova\")
end
	
assert_equal valore_atteso, YahooProvider.new(url).results_size

è un hack, e non è molto nella filosofia di come dovrebbero essere i test probabilmente..
ma funziona e non aggiunge complicazioni al codice originale.
La domanda è: cosa è giusto fare? E’ giusto perseguire un approccio alla scrittura di test che è tipico in altri ambienti anche se in questo caso ne posso fare a meno sfruttando le potenzialità di ruby?

Infine, se vi state chiedendo che cosa significhi la frase relativa ad open() nel titolo, sappiate che stavo pensando che sarebbe molto carino poter usare qualcosa come
open(”mock://foo”), ed in realtà è possibile farlo con open-uri.rb, magari in futuro ne parlerò. Però non è builtin, uffa

Contiene anche vari link interessanti, anche se mi pare di averli già visti quasi tutti.
Il che non significa che li abbia guardati con attenzione ed assolutamente è lontano dall’idea che io possa averli capiti, so solo che esistono.

Consiglio in particolare di vedersi i video sul Self System, che tra l’altra fa venire da chidersi come mai Sun abbia deciso di abbandonare una tecnologia rivoluzionaria per spingere java.

Ora guardiamoci in faccia, la classe Array in ruby ha un po’ troppi metodi, e lo dico sinceramente:

>> [].methods.size
=> 118
>>

Ma parecchi di questi metodi sono ereditati dai suoi antenati: 42 sono presi dalla classe Object e dal modulo Kernel, si tratta di cose come print.
22 vengono “gratis” dal modulo Enumerable.

Ne rimangono 56, non perdetevi ancora: 9 sono le versioni con side effect di metodi presenti in Enumerable. Quindi ad Enumerable#map, che trasforma una collezione in un array attraverso una funzione, corrisponde Array#map! che trasforma un array in place attraverso una funzione.

Rimangono 47 metodi. Cavolo è una bella interfaccia pesante.
Voglio dire, 47 metodi.
Cioè ok, la classe Vector in java ne ha 49 ma sono tanti.

Certo, io so benissimo che le interfacce devono essere piccole. So che fare interfacce molto grosse è un problema. Lo so me lo hanno detto moltissime volte. Però in effetti la mia esperienza personale dice che la classe Array in ruby è utile e non mi ha mai dato problemi.
Come direbbero i 99 posse: quello che penso è in cortocircuito con quello che sento.

Cerco di andare al cuore della questione, scavo nella mia mente di designer OO. Perché un’interfaccia con molti metodi è negativa?

Forse limita la modularità ed il refactoring. Penso di no, se avessi bisogno potrei spezzarla. Ah no aspetta: non potrei farlo, perché ovunque ho dichiarato che uso una IFoo e non delle IBar ed IBaz. Cioè in pratica un type system in stile java romperebbe le scatole. Tutto ok per ruby, python e smalltalk, ma anche per haskell ed ML.
Arriviamo dunque alla questione fondante: le classi con un’interfaccia ricca non sono un problema per se. Esse sono un problema quando diventano un blocco per la modularità e l’estensibilità.
La classe Array non ha questo problema, o almeno io non l’ho mai trovato. Quindi il problema (per la mia esperienza) non esiste, ma è solo un sottoprodotto mentale di una cultura rigida dei tipi. Insomma Java gli ha rovinato la testa.

Ma quello che è esilarante è quando questo tizio (che ha fatto atnte cose buone) cerca di spiegare come siano malvagi i 47 metodi di Array
Il primo punto:

Array.new(size=0, obj=nil)

This method creates an array that has size copies of the object.
Why? Have you ever needed to create an array/list that begins
its life containing more than one copy of the same object? I don’t
think I have.

Pensateci un attimo. Accarezzate l’idea che effettivamente non avete mai creato un Array con delle copie di un oggetto. Lasciatevi trasportare dal sentimento che, cavolo, ha detto che è stupido sarà stupido.
Poi pensate che lo zero è un oggetto. Mai usato un array inizializzato a zero. Deve essere dura, specialmente in java dove è l’init di default.

E poi questa, stupenda:

array < => other_array -1, 0, +1

A comparison between arrays. However, without me stating it
here, can you understand how to tell whether two arrays are
greater than, equal to, or less than each other?[..]
Plus how often do you need to compare lists for anything but
equality anyway?

Creiamo un altra interfaccia! Cerco di capirlo ma non ci riesco.
Nel frattempo continuo a poter fare

>> puts [p1,p2,p3].sort_by {|p| [p.cognome, p.nome]}
renzi gabriele
renzi nicola
rossi mario

E questa, meravigliosa:

abbrev(pattern = nil)

“Calculates the set of unambiguous abbreviations for the strings in self.”
Excuse me. What?! This one’s totally out of left field.

Ha ragione! è totalmente fuori dal mondo! Ed in effetti non esiste.
E’ in un modulo a se stante, il modulo Abbrev che quando viene caricato aggiunge la funzionalità dove deve stare, cioè nella classe Array. Avere le classi aperte ti permette di mettere le funzionalità dove hanno senso, sembra strano ma è utile.

array.at(index) -> obj or nil

As near as I can figure, this is exactly the same as using array
brackets except it uses a method call. If there is a difference, it’s
pretty subtle.

No, è abbastanza macroscopica e consiste nel fatto che [] può accettare Range, interi, coppia inizio/intervallo ed altro ancora, mentre at prende solo un indice.

array.nitems -> int

“Returns the number of non-nil elements in self. May be zero.”
Another one it never even occurred to me I might need.
I suspect this one’s beyond the 90/10 point. heck. It’s beyond the 99/1 point.

come disse uno su #ruby-lang:

>> answers=[true,nil,true,nil, nil]
=> [true, nil, true, nil, nil]
>> \"You answered #{answers.nitems} questions\"
=> \"You answered 2 questions\"

Quest’uomo è stato talmente rovinato da Java, forse. Non capisce che lo zero possa essere una cosa come le altre. Che anche se ti capita di scrivere una cosa una sola volta alla settimana devi fattorizzarla e non riscriverla ogni volta. E che il posto dove fattorizzare le operazioni sugli array è la classe Array e non org.me.ArrayUtils.
Che la piccolezza di un’interfaccia è un mezzo per raggiungere modularità ed estensibilità e non un fine in se.

Vabè, auguri.

Io sono un sostenitore dell’ipotesi che i DP servano solo se il linguaggio è tonto ,per qualche valore di tonto, ed in questo singolo caso in esame sembrerebbe che l’Abstract Factory sia necessario effettivamente solo per valori abbastanza grandi di tontezza.

Però ho in mente qualche altro pattern che invece forse sarebbe necessario comunque anche in python e ruby, come il visitor (che però è ancora inutile in CL). Insomma in realtà è unindagine interessante.
Specie se riesco ad infilarci dentro anche Haskell

Comunque, l’articolo non è venuto bene quanto volevo per mancanza di tempo, ma se non mi sbrigavo a passarlo a lm non l’avrei finito mai.
Ora devo mettermi a scrivere il secondo, (e scrivere la tesi e finire il sito del gruppo utenti ruby italia, e finire quell’applicazione in j2me per imparare i kanji, e sistemare il look di questo blog e …)

Come mettere un array di tipi base in una lista
Sostanzialmente, l’unico modo (che io conosca) è farlo a mano.
Riscriversi un bel ciclo ogni volta, error prone come piace a noi.
Si noti che esiste un Arrays.asList(Object[]) ma visto che i tipi base in java non sono oggetti, non funziona.
Non solo, per quel che ne so non è neppure possibile scrivere un metodo generico che trasformi un array in una List, in quanto a livello di linguaggio non c’è un’associazione tra i tipi primitivi e le rispettive classi Boxed.
Ovviamente si può risolvere con una sfilza di if/else ma non è che sia un granché come soluzione.

null non è un oggetto
Il che significa che non posso scrivere null.equals(foo).
Il che a sua volta significa, ad esempio, che un metodo per verificare l’uguaglianza tra due oggetti Pair, cioè dei contenitori di coppie di numeri, in ruby sarebbe:

 class Pair
  def == (other)
   first == other.first  and  second == other.second
  end
 end

mentre in java viene una cosa come questa (scrollare fino alla riga 43, poi sono 42 righe di codice, java5, la versione che dovrebbe semplificare tutto) [link alternativo senza note/sintassi colorata].
E c’è chi dice che non avere distinzioni tra tipi primitivi e non sia una cosa buona