Rozdział
7. "Working with Collections" w
"Programming Groovy: Dynamic Productivity for the Java Developer" Venkata Subramaniama omawia korzystanie z tych cech Groovy, które powodują, że praca z
kolekcjami (w rozdziale nacisk kładzie się na
java.util.List i
java.util.Map) staje się jeszcze bardziej przyjemna niż to ma miejsce w Javie.
W Groovy nie ma typów prostych, a ich użycie jest automatycznie zamieniane na ich odpowiednie typy opakowujące, np. char staje się java.lang.Character a int java.lang.Integer. W przypadku kolekcji możemy pokusić się o podobną analogię - użycie czegoś, co może przypominać konstrukcję tablicy sprowadza się do użycia...(jakieś pomysły?)...
java.util.ArrayList.
$ groovysh
Groovy Shell (1.6.3, JVM: 1.6.0_14)
Type 'help' or '\h' for help.
----------------------------------------------
groovy:000> lista = [ 1, 1, 2, 3, 5, 8, 13 ]
===> [1, 1, 2, 3, 5, 8, 13]
groovy:000> lista.class.name
===> java.util.ArrayList
Warto podkreślić deklarację typu tablicowego, który jest de facto listą. Nie korzystamy z konstrukcji przez new z podaniem rozmiaru lub bez, ale z elementami, jak przywyczailiśmy się w Javie. Jakkolwiek pierwsza jest dostępna w Groovy (wciąż przecież możemy pisać w Javie zanim poczujemy klimaty Groovy), to co istotne, konstrukcja z podaniem elementów jest niedozwolona w Groovy ze względu na...istnienie domknięć.
groovy:000> l2 = new int[5]
===> [I@1270107
groovy:000> l2.class.name
===> [I
groovy:000> l2.size()
===> 5
groovy:000> l2.each { println "$it" }
0
0
0
0
0
===> [I@1270107
groovy:000> l3 = new int[] {1,1,2,3,5}
ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed, groovysh_parse: 1: unexpected token: 1 @ line 1, column 17.
l3 = new int[] {1,1,2,3,5}
^
1 error
at java_lang_Runnable$run.call (Unknown Source)
Właśnie mnie natchnęło na poszukiwanie analogi i tak sobie myślę, że nigdy nie przyszło mi pomyśleć o tablicy jako byciu typem prostym dla listy. W końcu większość list jest właśnie obsługiwana wewnętrznie przez tablice, a cała pozorna (!) prostota z listami wynika z faktu, że chcemy mieć dynamiczną strukturę, która rozszerza się dynamicznie nie dbając o ilość zajmowanej pamięci. Czy ma uzasadnienie stwierdzenie, że robimy to z czystego lenistwa? Komu chciałoby się dbać o rozmiar tablicy (niezwykle efektywne pamięciowo programowanie), kiedy można machnąć ręką na nadmiar miejsca w pamięci zajmowanej przez listę i właśnie ją stosować? Ja robię to z wygody i mam w wielkim poważaniu, że zazwyczaj moja aplikacja zajmuje więcej miejsca w pamięci niż faktycznie potrzebuje. Teraz stałem się bardziej świadomy i będę jeszcze bardziej zestresowany pisząc aplikacje - poza dobrym stylem programowania, o którym trąbi się wokoło, stosowaniu wzorców projektowych, testowaniu, doszła fobia strat pamięci :) Mogłoby się wydawać, że mistrzowie programowania to najbardziej zestresowani ludzie.
"Chodzenie" po liście jest prawie identyczne z przemieszczaniem się po tablicy w Javie. Parafrazując reklamę - owe
"prawie" robi różnicę. W Groovy mamy możliwość chodzenia wstecz z indeksami ujemnymi (minus jest wskazaniem, że idziemy od prawej do lewej). Możemy również wypisać elementy z zadanego zakresu (również z minusami). Uwaga na kolejność indeksów!
groovy:000> lista
===> [1, 1, 2, 3, 5, 8, 13]
groovy:000> lista[-1] == 13
===> true
groovy:000> lista[-3..-1]
===> [5, 8, 13]
groovy:000> lista[-1..-3]
===> [13, 8, 5]
groovy:000> lista[1..3]
===> [1, 2, 3]
groovy:000> lista[3..1]
===> [3, 2, 1]
Kolejnym udogodnieniem w pracy z listami w Groovy jest pobranie podlisty. Należy jednak pamiętać, że zmiana elementu w podliście zmienia listę macierzystą (!) Typem podlisty jest
java.util.RandomAccessSubList. Nawet nie wiedziałem, że taka klasa w ogóle istnieje! I kto powiedział, że Groovy to
ZUO?! :)
groovy:000> lista
===> [1, 1, 2, 3, 5, 8, 13]
groovy:000> podlista = lista[0..3]
===> [1, 1, 2, 3]
groovy:000> podlista.class.name
===> java.util.RandomAccessSubList
groovy:000> podlista[0]
===> 1
groovy:000> lista[0]
===> 1
groovy:000> podlista[0] = 5
===> 5
groovy:000> lista[0]
===> 5
Groovy udostępnia metodę
each(), która przyjmuje domknięcie, do którego z kolei przekazywany jest element z listy. Jeśli metoda akceptuje pojedynczy parametr wejściowy, to można opuścić nawiasy i wygląda to bardziej groovy. Pamiętamy o tym, co? Domyślnym parametrem wejściowym jest
it, ale możemy go nazwać dowolnie. To też pamiętamy, nie?
groovy:000> lista
===> [5, 1, 2, 3, 5, 8, 13]
groovy:000> lista.each { println "$it" }
5
1
2
3
5
8
13
===> [5, 1, 2, 3, 5, 8, 13]
groovy:000> lista.each { element -> println "$element" }
5
1
2
3
5
8
13
===> [5, 1, 2, 3, 5, 8, 13]
Autor opisuje różnicę między iteratorem wewnętrznym (m.in. w Groovy) a zewnętrznym (m.in. w Javie). Różnica polega na możliwości kontrolowania iteracji i przy zewnętrznym konieczna jest kontrola końca iteracji. W przypadku Groovy mamy do dyspozycji iterator wewnętrzny i nie musimy o nic dbać - po prostu nasze domknięcie zostanie wykonane z każdym elementem spełniającym warunek funkcji wspierającej iterator, np. wspomniana each(). Poza nią mamy
reverseEach() (iterowanie wstecz) oraz
eachWithIndex() (iterowanie z dodatkowymi licznikami).
groovy:000> lista
===> [5, 1, 2, 3, 5, 8, 13]
groovy:000> lista.eachWithIndex { element, index -> println " $index: $element" }
0: 5
1: 1
2: 2
3: 3
4: 5
5: 8
6: 13
===> [5, 1, 2, 3, 5, 8, 13]
W ogóle całe iterowanie w Groovy zdaje się być aż nazbyt wyrafinowane (w pozytywnym tego słowa znaczeniu), bo czy kiedykolwiek przyszło nam do głowy, aby iterować po prostu po literach w napisie?
groovy:000> napis = "Jacek"
===> Jacek
groovy:000> pojedynczeLitery = []
===> []
groovy:000> for (c in napis) {
groovy:001> pojedynczeLitery += c
groovy:002> }
===> null
groovy:000> pojedynczeLitery
===> [J, a, c, e, k]
groovy:000> pojedynczeLitery[1]
===> a
groovy:000> pojedynczeLitery[1].class.name
===> java.lang.String
Więcej w podręczniku użytkownika Groovy w rozdziale
Looping. Aż trudno uwierzyć, że w samej dokumentacji Groovy nie korzysta się z operatora dodawania jako "ekscytującej" alternatywy dla metody List.add(). A można przecież i z wykorzystaniem operatora przesunięcia
<<.
groovy:000> napis = "Jacek"
===> Jacek
groovy:000> pojedynczeLitery = []
===> []
groovy:000> for (c in napis) {
groovy:001> pojedynczeLitery << c
groovy:002> }
===> null
groovy:000> pojedynczeLitery
===> [J, a, c, e, k]
Jeśli chcielibyśmy wykonać domknięcie na każdym elemencie kolekcji i otrzymać ponownie kolekcję ze zmodyfikowanymi elementami korzystamy z metody
collect().
groovy:000> napis
===> Jacek
groovy:000> napis.collect { it }
===> [J, a, c, e, k]
groovy:000> napis.collect { it += 1 }
===> [J1, a1, c1, e1, k1]
Możemy zwrócić jedynie elementy z kolekcji, które spełniają zadany warunek z metodą
find(). Warunek opisujemy w domknięciu.
groovy:000> jacek = "Jacek"
===> Jacek
groovy:000> jacek.find { it == 'a' || it == 'e' }
===> a
Zdziwiony/-a wynikiem find()? Jako możliwa odpowiedź niech posłuży kolejny przykład, tyle że teraz na scenę wchodzi
findAll().
groovy:000> jacek = "Jacek"
===> Jacek
groovy:000> jacek.findAll { it == 'a' || it == 'e' }
===> [a, e]
Teraz jasne? find sprawdza kolejne elementy do pierwszego trafienia i kończy działanie, a findAll przechodzi całą kolekcję.
Nic nie stoi na przeszkodzie, aby wykonać kolejną metodę na zwracanej kolekcji. Poprzedni przykład z findAll() połączymy z size(), albo collect() z sum() (przykład z książki).
groovy:000> jacek.findAll { it == 'a' || it == 'e' }.size()
===> 2
groovy:000> napis = ['Programming', 'In', 'Groovy']
===> [Programming, In, Groovy]
groovy:000> napis.collect { it.size() }.sum()
===> 19Wyobraźmy sobie takie konstrukcje w Javie. Pewnie nie byłyby bardzo skomplikowane, ale musielibyśmy pisać je sami. Warto? Nie, jeśli mamy je bezpośrednio wspierane przez język. A teraz wydają mi się po prostu niezbędne.
Kolejna niezwykłość w Groovy to metoda
inject(). Pierwszym parametrem wejściowym jest wartość początkowa, która będzie przekazywana domknięciu z samym elementem kolekcji. Owa wartość początkowa może być zmieniana, np. zwiększana/zmniejszana i każdorazowo zostanie przekazana domknięciu. Przykład pożądany, nieprawdaż?
groovy:000> napis = ['Programming', 'In', 'Groovy']
===> [Programming, In, Groovy]
groovy:000> napis.inject(0) { poprzedniaWartosc, element -> poprzedniaWartosc + element }
===> 0ProgrammingInGroovy
groovy:000> napis.inject(0) { poprzedniaWartosc, element -> poprzedniaWartosc + element.size() }
===> 19
Łączenie elementów kolekcji to robota dla
join() z pojedynczym parametrem - separatorem (łącznikiem).
groovy:000> napis
===> [Programming, In, Groovy]
groovy:000> napis.join(' ')
===> Programming In Groovy
groovy:000> napis.join('+')
===> Programming+In+Groovy
Jako przykład wprost stworzonego dla join przykładu jest dynamiczne tworzenie ścieżek na systemie plików lub klas.
Metoda
reverse() odwraca kolejność elementów, a odejmowanie jest usuwaniem elementów z kolekcji, ale nie, nie tylko pojedynczego, ale również każdego z elementów listy-odjemnika.
groovy:000> napis
===> [Programming, In, Groovy]
groovy:000> napis - ['In', 'Element, ktory nie istnieje', 'Groovy']
===> [Programming]
Możemy wykonać wiele operacji z iteratorem (metoda z domknięciem), albo skorzystać z operatorem
spread - * (gwiazdka), który wykonuje metodę, na każdym elemencie kolekcji. Przypomina to w działaniu collect i okazuje się, że są rzeczywiście synonimami (patrz
Spread Operator (*.)).
groovy:000> napis.size()
===> 3
groovy:000> napis*.size()
===> [11, 2, 6]
groovy:000> napis.collect { it.size() }
===> [11, 2, 6]
Na zakończenie przykład zastosowania operatora spread do rozszczepiania listy na pojedyncze parametry wejściowe.
groovy:000> def funkcja(a, b, c, d) {
groovy:001> println "$a $b $c $d"
groovy:002> }
===> true
groovy:000> napis
===> [Programming, In, Groovy]
groovy:000> funkcja(*napis)
ERROR groovy.lang.MissingMethodException: No signature of method: groovysh_evaluate.funkcja() is applicable for
argument types: (java.lang.String, java.lang.String, java.lang.String) values: [Programming, In, Groovy]
at groovysh_evaluate.run (groovysh_evaluate:2)
...
groovy:000> napis = ['Czyz', 'Groovy', 'Nie', 'Zachwyca?']
===> [Czyz, Groovy, Nie, Zachwyca?]
groovy:000> funkcja(*napis)
Czyz Groovy Nie Zachwyca?
===> nullLiczba elementów w liście musi być zgodna z liczbą parametrów wejściowych metody. Czyż Groovy nie zachwyca? A podobno są to funkcjonalności języków funkcyjnych, więc...pora na naukę języka funkcyjnego na JVM. Propozycje? I tylko proszę nie wyjeżdżać ze
Scala :) Jakoś bliżej mi do
Clojure. Ktoś się już z clojure zaprzyjaźnił?. Można o nim poczytać w
Learning Clojure na WikiBooks, a nawet po polsku na
clojure.pl. Pewnie niedługo i tu. Chętni wesprzeć mnie literacko? Przykłady użycia clojure (czy innych języków funkcyjnych) w projektach mile widziane.
Dostałem zadanie rozpracowania dostępnych obiektów Java Management Extension (JMX) - MBeans - w serwerze aplikacyjnym Apache Geronimo. Osoba zlecająca potrzebowała monitorować Geronimo i kiedy dowiedziałem się o tym, od razu zaproponowałem wykorzystanie JMX. W końcu, po to ta technologia została stworzona.
