Niektórzy wiedzą, że jestem już w zaawansowanym stadium osobistego projektu żartobliwie nazwanego "JAVATAR", który polega na poznaniu JAVA w stopniu pozwalającym, na napisanie przeciętnej aplikacji. Co prawda mam już niewielkie opóźnienie, ale nie i tym będzie dzisiejszy wpis.
W czasie nauki C++ często zauważałem jak wychwalano obiekty. Rzeczywiście, często ułatwiają prace, ponieważ operowanie na nich jest "wygodniejsze i bardziej intuicyjne". Podejrzewam, że ten pogląd bierze się stąd, że programista pod jedną nazwą ma dostęp do funkcji, zwanych metodami i danych. Mi, osobiście, się to jednak nie podoba, ponieważ daje złudny obraz obiektu, jako danych i kodu w jednym miejscu. W rzeczywistości jednak są to stare, dobre funkcje z wskaźnikiem na stukture w pierwszym, niewidocznym dla programisry argumencie. Myśle, że fakt, iż kod nie jest bezpośrednio połączony z danymi, jest istotny, jednak często nasi nauczyciele, nie ważne czy to są ludzie, czy kursy lub książki, "zapominają" nas o tym poinformować. Może przyczyną takiego stanu rzeczy jest to, że cała magia OOP nagle znika? Doświadczony programista zaraz by zwrócił uwagę na "przewspaniałą" możliwość dziedziczenia. Niestety, to tylko doklejanie kolejnych pòl do struktury i wywołanie metody o innej nazwie. Przeciążone funkcje też nie są magiczne, suma(int, double) to sumaid, a suma(int, int) to sumaii. Nie, nie twierdze, że obiektowość jest zła czy nie potrzeba, ponieważ z pewnością ułatwia zarządzanie zasobami ludzkimi i kodem projektu. Na kilku spotkaniach ustalane są podstawowe obiekty, ich interfejsy, oraz zależności, a później można przejść do tego, do czego programiści są stworzeni, czyli do klepania kodu w własnym zakresie. Do tego system szablonów skutecznie ułatwia pisanie uniwersalnych i łatwiejszych w zarządzaniu, więc też utrzymaniu, projektów.
Kazdy się z pewnością domyśla, że im mniejszy jest kod (mniej ma linijek), tym łatwiej nim zarządzać, jednak twórcy JAVA chyba o tym zapomnieli. Samo OOP wymaga napisania dodatkowego kodu dla każdej z klas i zachowując "dobre maniery" programowania obiektowego (np. dodawanie set i get dla zmiennych do których użytkownik ma określony dostęp) okazuje się, że kod, który powinien zajmować 2kB, nagle zajmuje 6 kB. W przypadku większych projektów pewnie tak tego nie widać, ale nawet przy założeniu, że kod urośnie o 30% mnie przeraża. Nie chodzi mi tutaj o to, że kod musi być przeciskany przez wolne łącza lub zajmuje dużo miejsca na dysku, zawsze może być skompresowany, ale o to, że programista, który dołącza się do projektu musi przeczytać prawie o 1/3 kodu więcej, by ogarnąć całość programu i systemy nim rządzące. W rzeczywistości jest to duża strata czasu, na którą pewnie niektórzy się nie godzą i nie czytają całego kodu, więc z pod ich palców wychodzą znaczki, które robią to, co już ktoś inny napisał. Kod jeszcze bardziej puchnie, a gdy taka sytuacja się zdarza to już po krótkim czasie dochodzi się do tego, że trzeba przepisać kod. Jednak komu chce się przepisać aplikacje, która ma miliard linii kodu? Dla firmy jest to nie do pomyślenia, ponieważ zatrzymuje rozwój całej aplikacji, stwarza nowe miejsce dla błędów i nie gwarantuje, że stare się nie powtórzą.
Całkiem inną rzeczą, która mnie w JAVA irytuje jest to, że nie ma szablonów funkcji, ani, sądząc po podstawowym api JAVA, żadnych mechanizmów pozwalających na wykorzystanie tego samego kodu w nieco innej sytuacji. Powstae niezdrowa sytuacja, w której trzeba przeciążyć funkcje dla każdego typu podstawowego osobno. Jest to szczególnie denerwujące gdy w naszej obsłudze któregoś z typów wkradnie się malutki błąd, którego zauważenie często zajmuje sporo czasu. Jeszcze musi być odzielna wersja dla obiektów... Nagle oskazuje się, że niepotrzebnie trzeba napisać o połowę więcej kodu.
W JAVA nie da się też przeciążać operatorów, co w przypadku np. BigDecimals. Nie dość że jest bardzo nieintuicyjne, to jeszcze sprawia, że kod jest mniej przejrzysty i bardziej zagmatwany. Człowiek widząc "a > b" szybciej zorientuje się o co chodzi niż składnia wywołująca "compareTo", której szczerze jeszcze nie rozumiem...
Brak komentarzy:
Prześlij komentarz