String, stringa, stringiem pogania

Jakie jest PHP każdy widzi. Plusem jest to, że wystarczy przeczytać kurs na onecie, znać choć trochę HTMLa i JSa i da się coś stworzyć. W Javie… cóż już tak łatwo nie jest. Pomijając zupełnie inne pole zastosowań oraz użyty model języka to problemem, z którym na początku sobie trudno poradzić jest przejście z myślenia prostego, na cokolwiek bardziej ‘porozbijane’.

O co mi konkretnie chodzi? Ano choćby o to, że mamy taką tablicę. W PHP tablica to tablica, ma dynamicznie przydzielany/budowany rozmiar, można zrobić na niej cuda niewidy. W Javie mamy kolekcje, kolejki, stosy, interfejsy implementowane w klasach i potem dziedziczące po tym kolejne klasy. Dużo, skomplikowanie i na pierwszy rzut oka wydaje się, że niepotrzebnie. Oczywiście życie pokazuje, iż wszystko zostało przez ludzi z Suna dobrze przemyślane i należy się nowego nauczyć, a nie wzdychać ze smutkiem.
Podobnie jest z tak fajnie prostą rzeczą jaką są ciągi znaków, czyli popularne stringi.  W Javie owszem string istnieje, ale ma jeszcze kilku kolegów. Oto oni:

- String to typ podstawowy. I cechą charakterystyczną tej klasy jest to, iż wszystkie jej metody zwracają nowy obiekt String!!! Czyli nie ma modyfikacji obiektu, na rzecz którego wywołaliśmy którąkolwiek z metod, ale stworzenie nowego.

- StringBuilder to właśnie sposób na to, by poprzez szereg metod (append czy insert) modyfikować swój egzemplarz.

- Istnieje też coś tak fajnego jak StringBuffer, który posiada dokładnie te same metody co StringBuilder, jednakże klasa ta jest przeznaczona dla programowania współbieżnego. Przy każdej operacji dokonuje sprawdzania czy na obiekcie StringBuffer działa tylko jeden wątek.

- na sam koniec zostawiłem StringTokenizer. W PHP jedną z moich ulubionych funkcji jest explode oraz implode. Działanie klasy StringTokenizer jest zasadniczo dość podobne, ale jednakże różni się w działaniu. Jej działanie polega na wyciąganiu z podanego łańcucha poszczególnych jego fragmentów. Świetnie przydaje się to przy wyświetlaniu danych tabelarycznych, czy listowaniu wyniku zapytania na bazie.

To taka lista na szybko. Nie zamierzam wklejać przykładów kodu, gdyż byłoby to kopiowaniem dokumentacji. Pragnąłem tylko pokazać gdzie w Javie należy szukać rozwiązania jakiegokolwiek problemu związanego z łancuchami tekstowymi.

Asercje i testowanie kodu

Wiadomym jest, że codzienna praktyka kodera PHP polega bardzo często na napisaniu w ciągu dnia kilkanaście  (jeśli nie kilkadziesąt) razy kombinacji różnych alertów, die’ów czy inszych echo celem podejrzenia działania programu w konkretnym momencie, lub też zwracanej wartości. Praktyka codziennego stosowania w pracy testów jednostkowych jakoś się w webdeveloperskim świecie nie do końca przyjęła, a jeśli już, to w formie ostatecznych testów przed wypuszczeniem aplikacji do poważnego użycia (trochę upraszczam, wiem).

W Javie mamy osławiony JUnit, framework do tworzenia testów jednostkowych, o których nota bene książka czeka w kolejce na przeczytanie. Jednakże na szybko należy wspomnieć o innym ciekawym rozwiązaniu, które w praktyce jest dla programistów całkiem miłym ułatwieniem. Konkretnie chodzi o asercje. Mówiąc krótko jest to taki warunek logiczny, którego niespełnienie (fałsz) powoduje przerwanie wykonywania programu. Jest to element języka, zatem nie trzeba od razu zatrudniać całej machiny testów jednostkowych, wystarczy wklepać w kod raptem jedną linijkę. Oto przykład:


public static void main(String[] args) { int licznik = 2;
int dzielnik = 0; // To jest zabronione
int wynik;
assert dzielnik != 0 : "Ty no nie dzieli się przez zero";
wynik = licznik/dzielnik; }


Oczywiście przykład jest bardzo prosty i ostry, w normalnych warunkach bez składni assert wyrzucony zostałby  ArithmeticException. Jednakże w tym przypadku zostanie uprzednio zgłoszony wyjątek AssertionError wraz z komunikatem, który podaliśmy zaraz po warunku. Niby nic, a jednak wiele – jakie są zyski z używania asercji?

Zasadniczo to dwa. Pierwszy jest taki, że wyrzucanie wyjątków asercji jest domyślnie wyłaczone!!! By uruchomić tę opcję należy wywoływać kompilator z parametrem -ea. W NetBeans wystarczy kliknąć prawym przyciskiem myszy na projekcie i Set Configuration->customize. I w okienku uruchomieniowym w rubryce VMOptions wpisać owo -ea.  Od tej pory przy kompilacji asercje będą brane pod uwagę. Jest to o tyle dobre, że dzięki jednej opcji, można bez problemu w ciągu jednej chwili przestawić aplikację ze stanu docelowego na developerski. Nie trzeba zakomentowywać masy kodu, wystarczy zmienić argument wywołania VM.

Drugim plusem jest informacja dla innych (poważne projekty to raczej nie domena 1 osoby) o założeniach dotyczących danego fragmentu kodu. Oczywiście na podanym przeze mnie przykładzie tego może i nie widać, za to przy dużych projektach, kiedy zależności między klasami zaczynają przypominać labirynt asercje pokazują swoją przydatność. O wiele łatwiej jest przeczytać w kodzie (lub wyniku kompilacji) “Kierowniku tutaj nie powinno być NULL”, niż przedzierać się przez gąszcz plików w poszukiwaniu klasy, z której pochodzi feralna metoda powodująca wyrzucenie wyjątku. Mała rzecz, a cieszy.