Nella blogosfera di recente c’è stata una specie di flamefest riguardo l’interfaccia fornita dalla classe Array in ruby.
In pratica Martin Fowler è contento perché questa classe fornisce un’interfaccia molto ricca in ruby, mentre qualche hard core javanese ritiene che sia una follia mettere più di dodici metodi in una classe.

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.