Oczywiście, pewność tę można uzyskać stosunkowo szybko. Niestety, nasza linia programu może nadal nie spełniać swojej funkcji i nie wyłowić Chęcin. Tak się bowiem składa, że nazwa ta zawiera polski znak. Czy możemy mieć pewność, że zmienna miasto na pewno została napełniona tekstem, do którego stosowany był ten sam zestaw znaków? Czy może raczej jest tak, że w zmiennej litera "ę" jest przechowywana w standardzie Unicode, podczas gdy w programie jest stosowane CP1250?

Zestaw znaków to nie wszystko. Zastąpmy teraz znak równości znakiem mniejszości. W alfabetyczne porównanie dwóch tekstów angażowane są informacje o kraju i języku (locale). Informacje te pozwalają właściwie "rozumieć" tekst, na przykład sortować go według reguł danego języka, dokonywać poprawnej konwersji do wielkich i małych liter itp. Mogłoby się wydawać, że na liście uszeregowanej alfabetycznie miejscowość Chęciny powinna się znaleźć przed nazwą Grodzisk. Tymczasem w języku czeskim "ch" stanowi osobną literę występującą w alfabecie za literą "h". Gdyby więc porównanie działało według reguł obowiązujących u naszych południowych sąsiadów, byłoby na odwrót.

W nowocześnie skonstruowanej aplikacji występują co najmniej trzy warstwy - bazy danych: biznesowa i prezentacji. Zwykle na każdej z nich zachodzi część przetwarzania. Zanim więc uznalibyśmy przytoczoną linię programu za poprawną, musielibyśmy się upewnić, na której z warstw będzie ona wykonywana. Może w bazie danych, jako tzw. procedura wbudowana (stored procedure)? Może w obiektach określających logikę aplikacji, działających na warstwie biznesowej? A może w przeglądarce internetowej na stacji roboczej klienta, który potencjalnie znajduje się w innym kraju (także w Czechach)? To samo porównanie może dać inny wynik na każdej z tych warstw i autor programu musi o tym myśleć w trakcie jego pisania.

Jak widać, nazwa malowniczego miasteczka w Górach Świętokrzyskich przysporzyła nam wiele wątpliwości. Zostawmy ją więc na chwilę i zajmijmy się zmienną miasto. Rzecz wydaje się prosta, ale czy jest taka rzeczywiście? Na przykład zmienna ta może wskazywać miejsce w bazie danych. W chwili gdy nasz klient chce odczytać zawartość bazy, inny klient może tam zapisywać. System zarządzania bazą danych wstrzyma żądanie odczytu do momentu, gdy tamten zapis się zakończy. Nastąpi więc istotne opóźnienie w działaniu programu. A co stanie się, jeżeli my jednocześnie zapisujemy do miejsca, które tamten program czyta? Nastąpi zakleszczenie, czyli deadlock, i wtedy nasza aplikacja znajdzie się w prawdziwych opałach.

Nie zawsze uświadomiona różnica

Nie miejsce tutaj na dalsze wymienianie problemów technicznych, jakie tworzy jedna, na pozór bardzo prosta, linia programu. Wystarczy powiedzieć, że jak dotąd do ich zarysowania musieliśmy sięgnąć do wiedzy z dziedziny systemów operacyjnych, architektury systemów, teorii baz danych i programowania współbieżnego.

Powróćmy teraz do naszego ambitnego samouka, którego postać (niestety, nie hipotetyczną) naszkicowaliśmy na początku. Wszystkie wymienione rozważania są mu całkowicie obce, bo w trzystustronicowych kursach "dla opornych" nie ma na nie miejsca. Gdyby nawet jednak się pojawiły, to i tak zostałyby przeoczone, bo ich zrozumienie wymaga jeszcze solidniejszego fundamentu: topologii, algebry, logiki formalnej itd.



<<< 1 2 3 >>>