Techniki obiektowe są znane od wielu lat, a mimo to nie są powszechnie stosowane.

Techniki obiektowe pojawiły się w informatyce już w końcu lat 70., ale nie upowszechniły się szerzej w codziennej praktyce profesjonalnego informatyka. W Polsce jedynie nieliczni używają narzędzi obiektowych, a i to na ogół podają, że używają języka C/C++, nie wiadomo więc dokładnie czy istotnie korzystają z właściwości obiektowych kompilatora C++. Podobnie jest na świecie.

Jakie są przyczyny niechęci do technik obiektowych? Wydaje się, że nie jest to jedynie brak zrozumienia korzyści, które można osiągnąć, stosując techniki obiektowe. A są one niebagatelne:

Łatwiej definiuje się wymagania na aplikacje, gdyż dobrze zdefiniowane obiekty programistyczne nie są jedynie abstrakcjami software'owymi, ale odzwierciedlają obiekty świata rzeczywistego.

Procedury przetwarzania, zwane tu metodami, definiuje się i koduje tylko raz.

Zwiększa się wydajność programisty, ponieważ umiejętne korzystanie z dziedziczenia pozwala na wielokrotne używanie tego samego, dobrze przetestowanego kodu, a wykrywalność błędów jest również większa, gdyż do tego samego kodu odwołuje się wiele części aplikacji.

Kod pisze się łatwiej, ponieważ programista zajmuje się jedynie niewielką częścią kodu, łatwą do precyzyjnego określenia, dobrego zaplanowania i bezbłędnego wykonania.

Łatwiej jest utrzymywać aplikacje, gdyż w razie potrzeby zmiany metody, jej efekty uboczne dają się kontrolować i ograniczać.

Wielu znanych programistów zajmuje się technikami obiektowymi w wolnym czasie, po części dla podwyższenia swoich kwalifikacji informatycznych i nadążania za postępem, trochę z konieczności stosowania dostępnych na rynku narzędzi (na ogół obiektowych, innych prawie nie ma), wielu zaś traktuje to jako hobby i ćwiczenie umysłowe (jak inni krzyżówki).

Natomiast akceptacja technik obiektowych w projektach informatycznych, zwła- szcza dużych, jest niewielka. Pierwsze wytłumaczenie to cynizm szefów informatyki, przekonanych, że techniki obiektowe to jeszcze jedna nowość, którą wystarczy przeczekać; "Przeżyliśmy aplikacje klient/serwer, języki 4GL, metody top-down, strukturalną analizę i projektowanie aplikacji, przeżyjemy i techniki obiektowe. Wszystkie te metody zapowiadały rewolucje w budowaniu aplikacji i nie sprawdziły się". Wydaje się to jednak zbytnim uproszczeniem sprawy.

Istotnie akurat w tej sprawie winą trzeba obarczyć heroldów i ewangelistów (ostatnio modny tytuł promotorów nowych technik), którzy twierdzą, że "12 linii kodu wytworzonych za pomocą ich narzędzia daje to samo, co 1000 linii kodu w C, Pascalu lub Cobolu" lub z niezmąconą powagą przekonujących, iż "to co robiłeś dawniej w ciągu 6 miesięcy, teraz zrobisz w 2 tygodnie". Żaden programista nie uwierzy w takie stwierdzenia, będzie więc z równą podejrzliwością podchodził do innych korzyści z narzędzi i technik obiektowych.

Inny powód małej akceptacji technik obiektowych to ich różnorodność. Burzliwy rozwój techniki i narzędzi spowodował takie urozmaicenie na rynku, że trudno jest podjąć decyzję, w jakim kierunku podążać. A tymczasem decyzja ta to nie tylko poważne nakłady finansowe na szkolenia i narzędzia dla programistów. To również strata czasu. Powszechnie uważa się, że można zacząć myśleć o pisaniu aplikacji za pomocą narzędzi obiektowych, jeśli korzysta się z nich co najmniej przez 6 miesięcy!

Pojawiają się tu również problemy moralne. "Zaczynaliśmy programować w Pascalu, znamy go nieźle, ale czy będzie on nadal rozwijany, jeśli tylko jedna firma dostarcza narzędzia w Object Pascalu? Jakie mam prawo wymagać od moich ludzi uczenia się języka, który może zniknąć za 2 lub 3 lata? Niech lepiej korzystają z C/C++, to się zawsze przydaje". Skutki nie dają na siebie długo czekać - piszemy programy kilka razy wolniej niż konkurenci posługujący się nowoczesnymi narzędziami obiektowymi.

Tu zresztą pojawia się chyba najważniejszy powód niechęci w przechodzeniu na techniki obiektowe. Ile osób programujących całe lata w Cobolu, PL1, Pascalu czy innym języku proceduralnym ma szansę przekwalifikować się na używanie czystych technik obiektowych? Ile to będzie kosztować? Ile czasu zajmie? Jak spadnie wydajność działu informatyki, gdy większość ludzi pójdzie na szkolenie? Żaden szef informatyki nie zaryzykuje własnej kariery tylko po to, aby podnieść kwalifikacje swoich ludzi.

Ze szkoleniem programistów też są poważne trudności. Wprawdzie wiele szkół informatycznych ogłasza szkolenia w najnowszych technikach obiektowych i narzędziach programistycznych, ale czy nauczający naprawdę je znają? Mam wątpliwości. Nie da się biegle opanować narzędzia programistycznego, nie posługując się nim w szkole pisania prawdziwej aplikacji dla konkretnego użytkownika. Zapytajcie instruktora w swojej szkole informatycznej, ile aplikacji napisał za pomocą podobno ulubionego narzędzia?

Kolejny powód to brak dobrych wzorców i udanych wdrożeń aplikacji, opracowanych za pomocą techniki obiektowej. Nawet jeśli są takie u nas, mało kto chce je upowszechniać. Powody mogą być różne. Zleceniodawca może natychmiast zakwestionować wysokie koszty opracowania i wdrożenia nowej aplikacji, gdy tylko się dowie, jacy to wydajni są nasi programiści. Na pewno nie zechce uwzględnić ukrytych kosztów ich szkolenia, narzędzi programistycznych i sprzętu do jego uruchamiania.

Góra do pokonania

Sądząc po szybkości wykonywania dużych projektów informatycznych i ich stanie, mamy jeszcze wiele do nadrobienia. Stara gwardia informatyczna, której kwalifikacje niesłusznie kojarzy się wyłącznie z komputerami mainframe, nie wierzy w szybkie wyniki uzyskiwane tylko dzięki zastosowaniu najmodniejszego narzędzia o supernowych właściwościach. Oni wiedzą, że dobre wyniki wymagają solidnej pracy, właściwej metodyki, sprawnego zarządzania projektem i przychylnego kierownictwa firmy. Ponadto tradycyjne metody i narzędzia dają wyniki - wprawdzie powoli, ale za to pewne - bo dopracowana metodyka pozwala unikać pułapek, w które wpadają młodzi entuzjaści techniki.

Młodzi entuzjaści nowych technik i narzędzi chętnie pokazaliby co potrafią, ale niestabilne narzędzia, nie dopracowana metodyka, brak dostępnych systemów do analizy, modelowania, projektowania i tworzenia aplikacji powodują, że wyniki ich pracy rzadko zadowalają zleceniodawcę.

Czy mamy szansę pokonać te przeszkody i wprowadzić na większą skalę techniki obiektowe? Wydaje się, że jest to nieunikniony kierunek rozwoju. Zostanie to wymu- szone zwłaszcza w wyniku rozwoju aplikacji dla sieci Web, w których posługiwanie się obiektami jest na tyle powszechne, że nie da się tworzyć aplikacji metodami tradycyjnymi, nawet tych najlepszych i sprawdzonych od lat.