Czy programowanie obiektowe nadaje się do budowania aplikacji biznesowych?

Niektórzy sądzą, że kluczem do rozwiązania problemów trapiących systemy informatyczne eksploatowane przez przedsiębiorstwa może być programowanie obiektowe. PO (programowanie obiektowe) oszczędza czas, zasoby, pieniądze i pozwala w szybki sposób budować dopracowane aplikacje na bazie wcześniej zdefiniowanych, autonomicznych obiektów. Jednak sceptycy wskazują na słabe punkty tej technologii: jest to metoda trudna do opanowania, pełno w niej problemów związanych z kompatybilnością obiektów i użytkownicy wiążą z nią chyba zbyt duże nadzieje. Kto ma zatem rację?

Niektórzy sądzą, że kluczem do rozwiązania problemów trapiących systemy informatyczne eksploatowane przez przedsiębiorstwa może być programowanie obiektowe. PO (programowanie obiektowe) oszczędza czas, zasoby, pieniądze i pozwala w szybki sposób budować dopracowane aplikacje na bazie wcześniej zdefiniowanych, autonomicznych obiektów. Jednak sceptycy wskazują na słabe punkty tej technologii: jest to metoda trudna do opanowania, pełno w niej problemów związanych z kompatybilnością obiektów i użytkownicy wiążą z nią chyba zbyt duże nadzieje. Kto ma zatem rację?

Zdecydowanie tak - John A. Strand

Programowanie obiektowe nie tylko że nadaje się do budowania aplikacji eksploatowanych przez przedsiębiorstwa, ale jest wręcz technologią zalecaną do stosowania w tym środowisku pracy. Trzeba powiedzieć, że firma Sprint Corp. przebudowuje aplikacje właśnie w oparciu o tę technologię.

Jeśli ktoś w dzieciństwie miał do czynienia z zabawkami typu klocki Lego, to nie powinien mieć większych kłopotów ze zrozumieniem podstaw pracy programowania obiektowego. Za pomocą tego samego zestawu klocków Lego można budować różne konstrukcje, np. dom, wieżę i fort. Tak jak gotowe od razu do użycia, prefabrykowane elementy są wizytówką rewolucji przemysłowej, tak prefabrykowane wcześniej obiekty i elementy, integrowane następnie za pomocą specjalnego oprogramowania mogą być synonimem rewolucji informatycznej. Bez nich proces budowania aplikacji byłby bardzo utrudniony i nie przebiegałby płynnie. Jest zadziwiające, że te proste zasady nie dają się łatwo zdefiniować, ponieważ jest to działanie (programowanie) oparte właściwie w dużej mierze na intuicji.

W firmie Sprint programowanie obiektowe jest używane nie tylko do budowania nowych aplikacji, ale też do rozsyłania po przedsiębiorstwie obiektów, które są współdzielone przez wielu użytkowników. Robimy to za pomocą oprogramowania typu ORB (Object Request Broker), takiego jak np. PowerBroker (Expertsoft Corp.), które pozwala rozwiązywać problemy związane z pracami prowadzonymi w ramach rozproszonej, heterogenicznej struktury systemu informatycznego. Dzięki temu radzimy sobie nieźle z problemem współoperatywności obiektów (wymienianych z naszymi kooperantami) i nie mamy kłopotów z niestandardowym oprogramowaniem, ponieważ takowego nie używamy.

Fakt wprowadzenia technologii programowania obiektowego zmienia w różnoraki sposób strukturę systemu informatycznego eksploatowanego przez przedsiębiorstwo. Niektóre cechy tej technologii powodują, że duże przedsiębiorstwa muszą w zasadniczy sposób zmienić model działania i podejście do eksploatowanych przez siebie aplikacji. Ważne jest przy tym dokładne zrozumienie cechy programowania obiektowego i przewidzenie ich wpływu na zmiany kulturowe zachodzące w przedsiębiorstwie. Nieco trudniejszą sprawą - ale możliwą do osiągnięcia - jest zdefiniowanie, w jakim stopniu nowa technologia zmieni zasady działania całego systemu informatycznego.

Jedną z najważniejszych cech technologii programowania obiektowego jest możliwość zagnieżdżania (encapsulation)

danych w obiektach. Dzięki temu, wszystkie informacje odnoszące się do konkretnego obiektu egzystującego w świecie rzeczywistym (może to być np. klient) można zgromadzić w ramach jednego wzrocowego "obiektu cyfrowego". Takie wzorcowe obiekty rezydują w wirtualnej hurtowni obiektów, do której mają dostęp wszyscy użytkownicy systemu informatycznego. Technologia zagnieżdżania ma wiele zalet: zmniejsza koszty tworzenia i utrzymywania aplikacji, nie wspominając już o poprawie jakości usług świadczonych klientom.

W przeciwieństwie do aplikacji obiektowych, niektóre dawne aplikacje mogą przechowywać pewne informacje o kliencie w jednej bazie danych, a pozostałe w innych.

Ponadto ta sama informacja o konkretnym kliencie jest często przechowywana w kilku bazach danych i każda może zawierać błędy. Co gorsze, są to niekiedy bazy danych różnych formatów. Bazy takie nie poddają się łatwo integracji i do ich obsługi trzeba zatrudnić wiele osób.

Technika zagnieżdżania pozwala w szybki sposób wprowadzać do aplikacji zmiany. Na rynku są już dostępne nowe narzędzia (np. opracowane przez Apertus Technologies Inc.), które automatycznie poddają konwersji dane, rezydujące w relacyjnych i nierelacyjnych bazach danych, na obiekty. Narzędzia te oferują doskonałą ścieżkę szybkiej migracji dawnych aplikacji na technologię obiektową.

Jedną z głównych zalet programowania obiektowego jest możliwość wielokrotnego użycia tego samego obiektu. Jest to bardzo ważne, ponieważ technika taka skraca cykl budowania aplikacji (oszczędność czasu) i co za tym idzie obniża koszty. Menedżerowie nadzorujący pracę programistów, budujących system informatyczny, popełniają nierzadko błąd polegający na tym, że - planując cykl budowy aplikacji - nie chcą poświęcić nieco więcej czasu na to, aby programiści tworzyli od razu kod wielokrotnego użytku (czyli obiekty).

Prawdziwe języki programowania obiektowego, takie jak np. SmallTalk czy Java, budują obiekty wielokrotnego użytku posługując się techniką dziedziczenia. I tak, jeśli programista napisał kod definiujący obiekty pewnej ogólnej klasy typu "piłka", to nie musi on już powtórnie pisać tego kodu (przystępując do budowania kodu definiującego różnego rodzaju "piłki"), a tworzy nowe podklasy w rodzaju "piłka nożna" czy "piłka golfowa". Pisze on wtedy tylko tę część kodu, który opisuje konkretny rodzaj piłki, a więc kod definiujący charakterystyczne cechy piłki nożnej (np. to że ma ona specyficzny rodzaj szwu) czy golfowej (np. kształt piłki czy rodzaj powierzchni). Dzięki dziedziczeniu technika wielokrotnego używania kodu jest zwykłą procedurą stosowaną przy projektowaniu aplikacji metodą obiektową.

Programista budujący nową aplikację bardzo niechętnie sięga po napisany przez kogoś kod dawnych aplikacji. Najczęściej pisze on kod od nowa lub komplikuje jeszcze bardziej cały projekt, dodając kolejną warstwę oprogramowania (umieszczając ją na szczycie starszej aplikacji).

Porównajmy to z programowaniem obiektowym. Dobry programista jest w tym momencie po trosze plagiatorem, artystą i integratorem systemów. Z błyskawiczną szybkością sięga po dowolny obiekt, wbudowuje go w swój projekt i jeśli jest to konieczne, modyfikuje go. Aby jednak przedsiębiorstwo mogło w pełni korzystać z dobrodziejstw oferowanych przez tę technologię, musi zatrudnić kogoś w rodzaju "zarządcy obiektów", a więc osobę, która będzie koordynować poczynania programistów.

Dlaczego więc programowanie obiektowe nie zdobyło większej popularności? Jedna z przyczyn leży w tym, że stanowi ono poważne zagrożenie dla organizacji bazujących na standardowych metodach programowania. Głównymi przeciwnikami tej technologii są ci, którzy - wdrażając ją do pracy - mogą stracić najwięcej: zarządzane centralnie

molochy, których siła wyraża się liczbą zatrudnionych pracowników, a nie oszczędnym gospodarowaniem zasobami i zmniejszaniem kosztów działalności firmy.

Kolejna przyczyna tkwi w tym, że przedsiębiorstwa z dużym trudem czy wręcz niechęcią podejmują decyzję o przejściu na programowanie obiektowe. Przeciwnicy projektowania obiektowego wysuwają przy tym argumenty na "nie", pokazujące trudności migracji na nowy system. Proszę ich nie słuchać. Taka fundamentalna zmiana modelu działalności firmy jest potrzebna, aby pociągnąć za sobą generalne zmiany w przedsiębiorstwie. A wymaga to czasu. I jeśli dyrektor przedsiębiorstwa nie zauważy na czas korzyści wynikających z wprowadzenia programowania obiektowego, to wini za to samą technologię i poprzestając na tworzeniu pewnych tylko klas obiektów zatrzymuje się w pół drogi. Zwiera to tylko szeregi przeciwników nowej technologii, którzy znowu czują się bezpieczni, i cały trud włożony w opanowanie nowej technologii idzie na marne.

W niedalekiej przyszłości wszystkie narzędzia do budowania aplikacji będą bazować na programowaniu obiektowym. Jest to zupełnie naturalny trend, co potwierdzają takie języki jak C++, SmalkTalk czy ostatnio Java.

Przyczyna tego stanu rzeczy jest prosta. Języki te tworzą obiekty, które odzwierciedlają warunki panujące w rzeczywistym świecie biznesu. Rekordy, pola i struktury są terminami używanymi w świecie komputerów; słowo obiekt jest terminem używanym i rozumianym przez przeciętnego użytkownika aplikacji. Jeśli tylko zrozumiemy istotę

obiektów kreowanych przez oprogramowanie w równie jasny sposób, w jaki używaliśmy w dzieciństwie klocków Lego, to technologia obiektowa stanie się dla nas oczywista.

Czy chcesz zatem pozostać w tyle, podczas gdy konkurencja stosuje już w swoich systemach informatycznych obiekty, starając się kooperować z Tobą przy ich użyciu? Zewsząd słychać pytanie - czy jest już czas na obiekty? Ależ tak, są one dostępne już od lat. Pytanie powinno brzmieć inaczej - kiedy działy systemów informatycznych w przedsiębiorstwach będą wreszcie gotowe do ich wdrożenia?

***

John A. Strand pracuje w Sprint Corp., gdzie pełni funkcję dyrektora działu integracji i technologii planowania.

Zdecydowanie nie - Martin A. Goetz

Tak jak można być pewny tego, że każdy musi płacić podatki i kiedyś umrze, tak nie ulega też żadnej wątpliwości, że klasyczna technologia programowania obiektowego - którą zdefiniowano już w połowie lat 80. - poniesie porażkę jako sposób nas budowanie aplikacji eksploatowanych przez szeroko pojęty świat biznesu i przedsiębiorstwa. Podobny los czeka też te organizacje, które postawią na tę technologię.

Jakie są charakterystyczne cechy "klasycznej" technologii programowania obiektowego? Technologię tę zaimplementowano do takich języków programowania obiektowego, jak C++ i SmallTalk. Cała logika funkcjonowania obiektów i zmienne są tu zagnieżdżane razem. Programowanie obiektowe definiuje klasy obiektów i łączące je zależności, używając hierarchicznego modelu. Logika prowadzenia biznesu jest rozbita na indywidualne metody postępowania i funkcjonuje w ramach modelu opartego na hierarchii klas. Obiekty dziedziczą w takim systemie pewne elementy funkcjonalności przypisane innym obiektom, usytuowanym wyżej w drzewie hierarchii.

Nie jest to wzorzec postępowania, który odniesie sukces. I proszę nie zrozumieć mnie źle. Doceniam próby poszukiwania nowym metod, które pozwoliłyby w efektywny sposób budować aplikacje biznesowe. Wszyscy wiemy, że potrzebujemy nowatorskich sposobów budowania aplikacji. Ale programowanie obiektowe nie jest taką metodą. Każdej opowieści o tym, jaką to doskonałą metodą jest programowanie obiektowe, można przeciwstawić pięćdziesiąt innych - jednak skrzętnie ukrywanych - opisujących sytuację, w których metoda ta nie zdała egzaminu. I każdemu programiście stosującemu do tej pory język Cobol, który odniósł sukces przechodząc na technologię obiektową, towarzyszy 50 innych, którzy po miesiącach szkoleń i prób w dalszym ciągu nie wiedzą, w jaki sposób posługiwać się nowym narzędziem, aby odnieść sukces.

Na łamach CW USA (z dnia 26 lutego br.) opisywaliśmy historię firmy Duke Power Company, która przeszła na programowanie obiektowe i poniosła same straty: straciła kontakt z systemami informatycznymi swoich klientów i cały projekt spalił na panewce. A artykule tym Steve Perkins (Oracle Consulting), który przeglądał cały projekt, przyznał, że: - "Metoda programowania obiektowego i towarzyszące jej narzędzia udowodniły, iż nie jest to technologia, którą można stosować z powodzeniem do budowania kompleksowych i rozbudowanych projektów informatycznych, w których występuje problem skalowalności", a także "jeden z największych kłopotów polega na właściwym ustaleniu relacji między systemem zarządzającym relacyjną bazą danych a obiektami programu".

Przykład firmy Duke Power Co. nie jest odosobniony. Gartner Group Inc. opracował w 1995 r. raport, w którym wymienia wszystkie wady programowania obiektowego.

"Technologia ta jest wyjątkowo trudna do opanowania" - czytamy w tym raporcie. I dalej - "Narzędzia projektowania obiektowego radzą sobie nieźle z graficznym interfejsem użytkownika (GUI), ale nie nadają się do budowania dużych, kompleksowych systemów (składających się z kilkuset relacyjnych tabel) i nie zdają egzaminu przy projektowaniu

systemów przez duże grupy robocze".

Jaki zatem problem technologia obiektowa próbuje rozwiązać? Przez ostatnich 40 lat główne zadanie działów informatyki polegało na budowaniu i eksploatowaniu pracujących efektywnie aplikacji, które przyczynią się do wzrostu produkcyjności, zredukują koszty funkcjonowania przedsiębiorstwa i pozwolą szybko dostosowywać działanie firmy do zmieniających się warunków prowadzenia biznesu.

Wszyscy pracowali nad tym problemem usilnie, zdobywając wiele nowych doświadczeń w tej dziedzinie. I raptem wszystkie są one ignorowane przez technologię "klasycznego" programowania obiektowego. Nawet zaprzysięgli zwolennicy tej technologii przyznają, że programowanie obiektowe wymaga przestawienia sposobu myślenia na nowe tory, jeśli chodzi o całą logikę budowania aplikacji.

Programowanie obiektowe jest czy raczej powinno być tylko środkiem pozwalającym budować lepsze aplikacje dla biznesu. Ale nie wnosi ono tu żadnych, rzeczywistych korzyści. Przyjrzyjmy się ewolucji zachodzącej w tej dziedzinie przez ostanie cztery dekady: kod maszynowy, asemblery, Cobol i wreszcie języki czwartej generacji (4GL). Każdy z tych etapów reprezentował - jeśli chodzi o technikę programowania - pewne wymierne korzyści. Każdy kolejny język był łatwiejszy do opanowania i obsługi. Właśnie w tym kontekście łatwo zauważyć, że technologia obiektowa nie reprezentuje żadnego nowego etapu w rozwoju technik programowania.

Cobol, tak jak wcześniej asemblery i kod maszynowy, powinno się już odesłać na zasłużoną emeryturę. Aby to zrobić, programiści posługujący się Cobolem muszą dysponować obiektami, które powinny być na tyle elastyczne w użyciu, by spełniły oczekiwania działów informatyki, budujących i eksploatujących aplikacje biznesowe.

Jak zatem poradzić sobie z tym problem? Okazuje się, że rozwiązanie leży przed nami: są to języki programowania czwartej generacji (4GL), które oferują już użytkownikom wiele opcji pozwalających budować aplikacje w efektywny sposób. Narzędzia typu 4GL do budowania aplikacji biznesowych są łatwe w obsłudze i dają się szybko opanować; używają przy tym tylko takiej technologii obiektowej, która jest zgodna z zadaniami związanymi z budowaniem dużych

kompleksowych projektów informatycznych; zawierają one też specjalne rozwiązania, używane do tworzenia aplikacji pracujących w rozproszonym środowisku przetwarzania danych typu klient/serwer.

I właśnie dlatego należy podjąć tę ważną decyzję - która jest kluczem pozwalającym odnieść sukces - i zdecydować się nie na klasyczną technologię programowania obiektowego, a wybrać produkt typu 4GL. Postąpiła tak (w przeciwieństwie do wspomnianej wcześniej Duke Power Co.) firma Mobil Oil Corp., która odrzuciła technologię klasycznego programowania obiektowego, decydując się na narzędzia 4GL. Mobil Oil tworzy aplikacje pracujące w środowisku klient/serwer przy użyciu pakietu Passport, opracowanego przez Passport Corp. Jest to produkt do tworzenia aplikacji biznesowych, bazujący na języku 4GL, który doskonale integruje koncepcję obiektów z technologiami stosowanymi przez systemy zarządzania relacyjnymi bazami danych. Passport jest produktem łatwym do opanowania i został szybko zaakceptowany przez pracowników posługujących się do tej pory Cobolem. Pakiet pracuje efektywnie i pozwala szybko modyfikować aplikacje, dostosowując je do zmieniających się warunków prowadzenia biznesu.

Można wymienić trzy podstawowe powody, dla których technologia obiektowajest skazana na porażkę:

1. Konieczność wcześniejszego przeszkolenia pracowników, którzy muszą zmienić swój sposób myślenia, jeśli chodzi o zasady budowania aplikacji. Wszystko to wymaga czasu i pieniędzy.

2. Klasyczna teoria programowania obiektowego zawiera wiele wad, które utrudniają zadanie budowania aplikacji bazujących na technologiach używanych przez systemy zarządzające relacyjnymi bazami danych.

3. Języki programowania obiektowego i stosowana przez nie metodologia nie przystaje do ciągle zmieniających się warunków prowadzenia działalności biznesowej.

Klasyczna technologia obiektowa nie ma więc przyszłości w środowiskach systemów informatycznych eksploatowanych przez biznes. Naszą uwagę powinniśmy zamiast tego koncentrować na działaniach zmierzających do poprawienia produkcyjności przedsiębiorstwa i wprowadzania do niego takich rozwiązań, które ułatwią nam życie - a nie skomplikują je jeszcze bardziej. Możemy to osiągnąć zdając się na narzędzia 4GL. Inwestycja taka opłaci się nam na pewno.

***

Martin A. Goetz jest prezesem firmy Goetz Associates. Jako założyciel i były prezes Applied Data Research Inc., Goetz zajmuje się od ok. 30 lat problemami nowych technologii budowania systemów informatycznych.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200