Orientacja obiektowa (OO) w programowaniu stała się na tyle hasłem dnia, że nikt nie zastanawia się na ile przystaje ona do codziennej rzeczywistości ośrodka obliczeniowego lub jak się ma do kwalifikacji programistów pracujących od lat w Cobolu.

Teoretycznie orientacja obiektowa w programowaniu, wymyślona w zaciszu naukowych gabinetów, powinna przynieść wiele korzyści. Często podkreślana jest możliwość wielokrotnego wykorzystywania raz wyprodukowanego kodu. Praktyka pokazuje jednak, że większość programistów podchodzi do niej jak do pokrzywy: nie dotykać jeśli się nie musi. I czasem - przechodząc do programowania obiektowego - próbują stworzyć model działania w znacznej mierze nie pasujący do praktyki i sposobu działania firmy.

Jak osiągnąć sukces?

Ed Yourdon, znany zapewne większości informatyków specjalista od metodyki projektowania, stwierdził że dla ponad 90% programistów z przemysłu problem orientacji obiektowej sprowadza się do konieczności nauczenia się jeszcze jednego języka programowania. I tylko 10% organizacji, rozważających przejście z aplikacjami na orientację obiektową, wraca do fazy analizy i projektowania aplikacji, które mogą uczynić z aplikacji całkiem nową jakość. Reszta próbuje przejść na taką orientację posługując się kodem dawnych aplikacji. Entuzjazm dla nowej techniki powoduje, że ludzie często nie zastanawiają się na tym, jaki problem należy rozwiązywać tą nową techniką, ani jak to rozwiązanie pasuje do działalności przedsiębiorstwa.

Czasem kierownictwo działu informatyki zastanawia się od jakiego rodzaju projektu zacząć swoją pierwszą aplikację obiektowo zorientowaną. Tymczasem problem jest znacznie głębszy niż dopasowanie technologii do specyficznego zagadnienia. Problem polega raczej na dopasowaniu projektu do specyfiki działania i możliwości firmy. Nie można bowiem zaczynać obiektowo zorientowanej aplikacji w firmie mającej tylko programistów w Cobolu! I na dodatek, jeśli każe się znaną im dobrze aplikację przerabiać w nowej wersji obiektowej, można mieć całkowitą pewność, że nic z tego nie wyjdzie.

Ed Yourdon cytuje kilka reguł, których spełnienie jest niezbędne do sukcesu (ale go nie gwarantuje) aplikacji obiektowej ( ramka).

Warstwy projektu

Jeżeli wiele z materiałów nt. technologii obiektowej wydaje się niezrozumiałych i niespójnych, wynikać to może z faktu, że dotyczą one czterech różnych warstw orientacji obiektowej. Te same dane mogą znaczyć różne rzeczy dla ludzi szukających w nich różnej informacji ("informacja to dane przetworzone").

Najniższa, czwarta warstwa programowania zorientowanego obiektowo dotyczy narzędzi, takich jak języki programowania, które mogą zawierać obiekty (moduły zawierające zarówno wykonywalny kod, jak i dane dobrze chronione za pomocą tego kodu). Smalltalk jest przykładem języka w pełni obiektowego, podczas gdy C++ jest typowym językiem proceduralnym, który wyposażono w możliwości obiektowe. Przewiduje się nawet, że pojawi się obiektowa wersja Cobolu (!). Większość dyskusji nt. programowania zorientowanego obiektowo dotyczy tej warstwy.

Warstwa trzecia zawiera dwie kategorie metodologii projektowania obiektowego: analizę i projektowanie aplikacji. Celem obiektowo zorientowanej analizy (OZA) jest takie rozłożenie projektu na elementy składowe, aby był zrozumiały w procesie projektowania OO. Obiektowo zorientowane projektowanie (OZP) ma pozwolić na podjęcie decyzji, jakich narzędzi należy użyć w trakcie rozwiązywania problemu.

Istnieje wiele konkurujących ze sobą metodologii OZA i OZP: Shalaer-Mellor, Firesmith, Coad-Yourdon. Każda proponuje metodę oszczędzania wysiłku programisty i produkowania większej ilości, lepszego kodu. Yourdon napisał nawet na ten temat kilka książek (np. "Object-oriented systems design", Yourdon Press, 1993).

Warstwa 2 dotyczy problemów integracji technologii i zarządzania tym procesem. Koncentruje się na zrozumieniu organizacji oraz sposobu pracy przedsiębiorstwa i jak one wpływają na technologię, powodując szybki lub powolny wzrost firmy. Coraz więcej dyskusji nt. przydatności metod OO dotyczy tego właśnie poziomu przygotowania aplikacji, gdyż wiele firm ma kłopoty ze zdecydowaniem się, co mają zrobić z istniejącymi już aplikacjami i ile pieniędzy przeznaczyć na szkolenie swych informatyków w dziedzinie projektowania OO.

Wreszcie ostatni, najwyższy poziom dotyczy restrukturyzacji przedsiębiorstwa (zwanej po angielsku Business Process Reengineering -BPR). Powszechnie panuje opinia, że informatycy powinni lepiej zrozumieć działalność różnych działów przedsiębiorstwa, któremu służą. Niektórzy specjaliści posuwają się nawet do stwierdzenia, że należy tak przeorganizować przedsiębiorstwo, aby jego operacje lepiej pasowały do technologii OO.

Z dołu do góry czy odwrotnie?

Opinia ludzi, którzy w praktyce zetknęli się projektowaniem obiektowym lub realizowali konkretne projekty jest następująca: lepiej zaczynać od dwóch najniższych poziomów - zarówno poznawać język programowania OO, jak i metody analizy oraz projektowania OO. Jednakże samo programowanie OO bez analizy i projektowania zwykle nie przynosi oczekiwanych rezultatów. Lepiej zainwestować dostatecznie wiele czasu na analizę przed przystąpieniem do realizacji projektu niż próbować poprawiać go później.

W ciągu ostatnich 25 lat rozwoju informatyki profesjonalnej najbardziej efektywna strategia realizacji dowolnego projektu sprowadzała się do stwierdzenia: minimum inwestycji przy maksimum imitacji. Ponieważ OO wymaga więcej inwestycji niż inne metody realizacji projektów i mało jest możliwości korzystania z istniejących aplikacji, to może okazać się że firmy próbujące stosować OO czekają ciężkie czasy.

Jak inwestować w programowanie OO?

Większość programistów przechodzących z programowania strukturalnego do OO skarży się na brak dostatecznego

przeszkolenia i brak wiedzy ze strony szefów projektów informatycznych. Być może jedyną metodą łagodnego przejścia z programowania strukturalnego do programowania OO jest pokazywanie szefowi ciągle jakiejś nowej wersji prototypu aplikacji (ciągłe prototypowanie aplikacji). Pozwala to także na wielokrotne wykorzystywanie przynajmniej części kodu aplikacji, o co głównie chodzi w programowaniu OO.

Jeżeli zespół programistów ma już spore doświadczenie w programowaniu OO i dobrą znajomość działania przedsiębiorstwa, wydaje się, że metoda z góry na dół jest efektywniejsza. Po dokładnym zrozumieniu sposobu działania firmy można bowiem przystąpić bezpośrednio do modelowania obszarów działalności firmy w postaci obiektów, a potem je wielokrotnie stosować do pisania aplikacji. Może to jednak wymagać zmiany sposobu działania przedsiębiorstwa (reengineering) w celu dopasowania jej do możliwości technologii.