Nim w jakiejkolwiek firmie przejdzie się do szczegółowych rozważań na temat metod modelowania obiektowego i jego nowych języków programowania, powinno się postawić zasadnicze pytanie: a dlaczego właściwie obiekty? Wiele firm ma już opanowaną technikę opracowania aplikacji, rozwijaną przez lata i nie ma właściwie żadnegopoważnego powodu, dla którego należy ją zmieniać.

Poniżej podano zalety orientacji obiektowej (OO) i jakie korzyści mogą z niej osiągnąć firmy przechodzące na tę nową technikę programowania.

Popularność orientacji obiektowej

Obecnie każdy człowiek, jako tako zaangażowany w opracowaniu aplikacji, z całą pewnością słyszał o obiektach; technika obiektowa jest używana w aplikacjach czasu rzeczywistego i w wielu aplikacjach ważnych dla przemysłu. Jak wynika z badań przeprowadzonych przez Object Management Group (jest to grupa ponad 200 firm komputerowych mająca na celu opracowanie wspólnej techniki obiektowej dla aplikacji i środowiska komputerowego) tylko ok. 3% zespołów programistów w USA używa obecnie techniki obiektowej, ale przewiduje, że ponad 40% będzie jej używać w 1997 r. i ponad 80% w 2001 r. Równie interesujące są przewidywane nakłady na technikę obiektową: będą one systematycznie rosły w ciągu kolejnych lat.

W niezależnych badaniach rynku przeprowadzonych przez Systems Development w końcu 1991 r. i powtórzonych w końcu 1993 r. otrzymano zbliżone wyniki. Te ostatnie badania dotyczyły szerokiej gamy technologii, łącznie z OO, metodami programowania strukturalnego, narzędziami CASE itd. Liczba projektów, w których korzystano z techniki obiektowej wzrosła z 3,8% w 1991 r. do 12% w 1993 r. W tym samym czasie udział metod programowania strukturalnego zmalał z 72% do 60%.

Nawet jeśli technika obiektowa staje się coraz popularniejsza, to musimy pamiętać, że nadal używa jej niewielka mniejszość programistów. Jak się okazuje w dużych firmach użycie techniki obiektowej sprowadza się do eksperymentowania i projektów pilotażowych. Ponadto większość tych projektów jest wykonywana przy użyciu CI++, bez korzystania z analizy, projektowania i innych metod inżynierii oprogramowania związanych z OO. Wróćmy więc teraz do zasadniczego pytania tego artykułu:

Dlaczego technika obiektowa? Jakie korzyści z OO?

Istnieje kilka dość zasadniczych powodów korzystania z techniki obiektowej, cytowanych przez jej zwolenników.

Większa wydajność produkcyjna. Istnieją dwa najważniejsze powody adoptowania techniki obiektowej: wydajność produkcyjna programisty i szybkość. Poważne badania wykazują, że daje się osiągnąć znacznie zwiększoną wydajność produkcyjną zespołu programistów (czasem nawet większą o rząd wielkości) i że w podobnej skali udaje się zmniejszyć czas opracowania projektu.

Trzeba więc odpowiedzieć na pytanie: jak to jest możliwe? Czy osoba programująca w Smalltalku czy C++ jest w stanie produkować 10 razy więcej niż w Cobolu? Trzeba tu jeszcze uwzględnić jakimi narzędziami posługiwali się ci programiści: czy był to język 3GL czy 4GL? Podobne argumenty padały już w latach 80., gdy przejście z języka 3GL (Cobol, PL/I) na 4GL zwiększało wydajność programisty także 10 razy. Nie należy się więc dziwić stwierdzeniom, że języki OO, takie jak Smalltalk czy Eiffel mają konstrukcje językowe odpowiadające 10-100 instrukcjom języków dawniejszych. Programista staje się więc automatycznie bardziej wydajny. Jest to szczególnie ważne dla współczesnych aplikacji z interfejsem graficznym GUI, w których dopiero po napisaniu ok. 6 stron kodu w C udaje się otworzyć okienko na ekranie.

Wielokrotne używanie obiektów. Jest jednak więcej powodów, dla których technika obiektowa pozwala na osiągnięcie tak znacznej wydajności produkcyjnej: jest to wielokrotne wykorzystanie obiektów i klas. Od dawna wiadomo, że firmy używające powtórnie raz opracowane produkty uzyskują prawie cudowne wyniki. W najgorszym przypadku firma, która uważa, że nie należy używać jakiegoś produktu bo "nie został opracowany u nas" może osiągnąć zero procent powtórnego wykorzystania. W najlepszym przypadku znane są organizacje osiągające powtórne użycie w ponad 90%, gdyż opracowują stale popularne aplikacje o podobnych właściwościach.

Technika obiektowa pozwala na wielokrotne użycie obiektów za pośrednictwem bibliotek klas i obiektów; wykorzystuje w tym celu koncepcję kapsułkowania (encapsulation) i dziedziczenia (inheritance). Z czysto technicznego punktu widzenia powtórne użycie jest łatwiej osiągalne w technice obiektowej niż w innych metodologiach rozwoju oprogramowania; obiekty mają większą spójność, ponieważ kapsułkują one zarówno dane jak kod -- są więc duże szanse, że obiekt można wyjąć z jednego programu i użyć w innym. Wymaga to jednak szczegółowego planowania i zarządzania obiektami, promując zespoły, które poświęcą wiele czasu na stworzenie bibliotek klas i obiektów. Sama technika obiektowa nie gwarantuje jeszcze wielokrotnego użycia obiektów.

Szybsze opracowanie aplikacji. Jeżeli wydajność produkcyjną w projekcie software'owym mocno zwiększyć, to naturalnie można przyjąć, że projekt będzie zakończony szybciej. Niestety, niekoniecznie jest to prawdziwe: technika obiektowa pozwala na wykonanie projektu przez trzech programistów pracowników, zamiast przez trzydziestu, ale sam projekt nadal może ciągnąć się przez lata. Co jest takiego specjalnego w OO, że czas wykonania projektu można zredukować z 3 lat do 3 miesięcy?

Podstawowa odpowiedź jest taka sama, jak poprzednio: wielokrotne użycie. Programiści, posługujący się techniką obiektową mają zwykle do dyspozycji solidną i niezawodną bibliotekę klas i obiektów oraz potrafią szybko stworzyć -- przez dziedziczenie -- specjalizowaną podklasę istniejących obiektów dla własnych potrzeb. Zmniejsza to nie tylko czas programowania, ale także czas testowania (ponieważ wielokrotnie używane klasy były już intensywnie testowane) i projektowania (ponieważ nie trzeba zastanawiać się, jakie klasy i obiekty należy zrealizować, i jak to wykonać). Obiekty redukują zbędne wielokrotne specyfikowanie tej samej części przetwarzającej programu w różnych miejscach, gdyż wystarcza wykonać to jeden raz; ponadto koncepcja dziedziczenia pozwala na korzystanie z właściwości i atrybutów, wspólnych dla różnych typów obiektów.

Jest jeszcze jeden, nawet ważniejszy powód znaczącego zmniejszenia czasu wykonania projektu w technice OO: prototypowanie. Typowa metodologia sekwencyjnych kroków, w której kolejne działania całego projektu są wykonywane w długim okresie jedno po drugim, jest zwykle ignorowana w projektach OO. Jeżeli w trakcie projektu OO zapytamy typowego projektanta: "Co obecnie robisz?" to zapewne odpowie: "Wszystko po trochu: nieco analizy, trochę projektowania, co nieco kodowania i niewiele testowania".

Prototypowanie i wielokrotne używanie dobrze ze sobą współdziałają: łatwiej jest wykonać prototyp, jeśli ma się do dyspozycji solidną bibliotekę obiektów, dających się używać wielokrotnie. Ale to jeszcze nie wystarcza. Jak w każdym przypadku wielokrotnego wykorzystania pojawia się problem zarządzania tymi obiektami, ściśle związany ze zmianą sposobu organizacji projektu, przy przejściu z tradycyjnej metodologii kolejnych kroków na prototypowanie (lub inaczej podejście iteracyjne).

Technika obiektowa jako narzędzie programów "zero defektów"

Zwiększona wydajność produkcyjna i wielokrotne użycie obiektów są najczęściej przytaczanymi argumentami na korzyść techniki obiektowej. Jednakże ludzie, którzy już wykonali kilka projektów OO podnoszą jeszcze dwie cechy tej techniki: jakość produktu i łatwość konserwacji.

Jakość produkcji ma wiele cech, których omówienie zajęłoby całą książkę. Jednakże jednym z aspektów techniki obiektowej jest jej "naturalna" bezbłędność. Tak przynajmniej twierdzą jej zwolennicy. I mają poważne argumenty na poparcie tej tezy. Wielokrotne użycie obiektów powoduje, że jeśli nawet zawierały jakieś błędy, to już dawno zostały one usunięte. Inny poważny powód, to ścisłe kapsułkowanie: obiekty bronią się same (i związanych z nimi danych). Jeżeli więc nawet program "pójdzie w maliny", to małe są szanse, że uszkodzi inne obiekty w tym samym systemie.

Dla wielu działających już aplikacji OO jest jedna interesująca konsekwencja tego zachowania się obiektów: jeżeli pojawi się błąd, to system OO na ogół łagodniej degraduje swe działanie, niż programy wykonane metodami konwencjonalnymi, które zwykle blokują się w momencie pojawienia się błędu.

W "tradycyjnym" projektowaniu obiektowym mówi się: "Jeżeli obiekt otrzyma komunikat, którego nie rozumie, to po prostu odpowiada nadawcy, że nie jest w stanie go przetworzyć. Nie niszczy zaś wszystkiego wokół, łącznie z samym sobą".

Jeśli zaś chodzi o łatwość konserwacji, to ponieważ obiekty zawierają zarówno dane, jak i przetwarzanie z nimi związane, to zarówno zmiana danych, jak przetwarzania są zlokalizowane. Interfejs z innymi obiektami jest mały i dobrze zdefiniowany, co oznacza że wpływ zmian w obiekcie na inne obiekty jest minimalny. Entuzjaści techniki obiektowej podkreślają, że architektura ich systemów (aplikacji) zamiast opierać się na hierarchii funkcji (która może się zmieniać wraz ze zmianą wymagań użytkownika), jest oparta na sieci współpracujących obiektów. Z powodu właściwości kapsułkowania, wszystkie obiekty można podmienić na obiekty wykonane innymi metodami -- czasami nawet w trakcie działania systemu -- bez wpływania na działanie innych obiektów.

Czy zaprzestać korzystania z dawnych metod?

W wyborach powszechnych polityk zostaje wybrany nie dlatego, że jest tak popularny, tylko dlatego, że wyborcy głosowali przeciw innym kandydatom. Z podobnego powodu wiele firm wybiera technikę obiektową: dlatego, że dawne techniki nie spełniają ich oczekiwań. Oto kilka powodów, dla których tak się dzieje.

Dawne metodologie się nie sprawdziły. Największym problemem dawnych metodologii jest oddzielenie modelu procesu (funkcji) od modelu danych. W praktyce te dwa modele są często opracowywane przez różne zespoły ludzkie, korzystające z różnych narzędzi CASE. Gdy przychodzi moment połączenia tych modeli, pojawiają się niezgodności i sprzeczności. Dyskusja przeradza się w sprzeczkę na temat zasad, a nie poprawności modeli. Wątpliwości rozstrzyga się odrzucając jeden model, co powoduje, że projekt jest oparty jedynie na części istotnej informacji, udokumentowanej w formalnym dokumencie.

W niektórych przypadkach pojawiają się poważniejsze wątpliwości, gdy użytkownicy nie rozumieją żadnego z prezentowanych im modeli. Niestety, modele tradycyjnie używane w fazie analizy i projektowania (np. diagramy przepływu danych i diagramy zależności encji) są uważane za zbyt "abstrakcyjne" lub "techniczne". Z tego powodu przechodzi się na technikę obiektową, w której użytkownikowi pokazuje się obiekty, spotykane przez niego w realnym świecie.

Metodologia musi być dopasowana do architektury. Obecnie opracowuje się radykalnie różne projekty niż były one dawniej. Dawniejsze metodologie były przystosowane do mainframe'a, przetwarzania wsadowego, języków 3GL. Obecne aplikacje zakładają korzystanie z PC, sieci klient/serwer i graficznego interfejsu użytkowego. Czasem programiści i szefowie projektów spostrzegają się, że jeśli nie zmienią metodologii na OO, to projekt po prostu nie uda się. Ponadto współczesne projekty są znacznie większe niż były jeszcze 10 lat temu. Jak pokazały badania przeciętny współczesny projekt informatyczny jest ok. 50 razy większy niż projekt z początku lat 80. Co gorsza, współczesne projekty są wykonywane w warunkach silnej konkurencji, wymagającej dostarczania gotowej aplikacji tak szybko, jak jest to możliwe. Tak więc zasadniczego znaczenia nabiera szybkość i wydajność programowania; stąd też coraz większe znaczenie ma możliwość wielokrotnego wykorzystania kodu.

Zmieniły się języki programowania i środowisko. Na tyle radykalnie zmieniły się języki programowania i środowisko programistyczne, że dziś mało kto wyobraża sobie, iż mógłby używać Pascala czy Fortranu do opracowania poważnej aplikacji dla biznesu. Dlaczego nie używaliśmy języków OO w latach 70.? Bo ich nie było. A dlaczego wobec tego nie używaliśmy ich w latach 80.? Bo wczesne wersje Smalltalka czy C++ nie nadawały się do poważnych prac programistycznych. Jeszcze do niedawna nie istniały narzędzia CASE zorientowane obiektowo i nie istniały handlowe biblioteki klas oraz obiektów. Ludzie dążą do używania dostępnej im technologii, nigdy zaś nie chcą używać produktów przestarzałych. Jeżeli więc pewnego dnia Cobol stanie OO-Cobolem, Natural zaś OO-Naturalem (Natural jest to język opracowania aplikacji dla bazy Adabas, firmy Software AG), to programiści na pewno powoli przejdą na te nowe języki.

Kiedy nie używać nowych narzędzi?

Sceptycy w konserwatywnie myślących ośrodkach informatycznych powiedzą: "Po co mamy się spieszyć. Niejedną nową technologię już przeżyliśmy, przeżyjemy i OO. Za parę lat nikt nie będzie wiedział co to było OO".

Czy należy więc koniecznie przechodzić na te nowe narzędzia i metody projektowania aplikacji? Jeżeli nie masz problemów i kłopotów z użytkownikami ani aplikacjami, to zapewne możesz uważać, że cała ta dyskusja cię nie dotyczy. Nieprawda!

Nie wydaje się, byśmy jeszcze kiedykolwiek powrócili do takich metod opracowania aplikacji i organizacji pracy, jakie były na porządku dziennym w latach 70. Rosnąca popularność technik obiektowych musi doprowadzić do rozpowszechnienia się umiejętności korzystania, jeśli nawet nie definiowania własnych klas i obiektów. Nie musimy już obecnie nadawać technikom obiektowym najwyższego priorytetu w naszych poczynaniach. Nawet jeśli konkurencja nie depce nam po piętach, szef nie słyszał o OO, zaś użytkownicy są zadowoleni z terminali znakowych, to jednak dobrze jest czytać materiały na ten temat, szkolić się w nowych technikach, aby być przygotowanym do nowych czasów.

Ludzie są ważniejsi niż metodologie

W wielu organizacjach ważniejsze od przejścia na nowe techniki programowania będzie zapewne prawidłowe wykorzystanie załogi. Trzeba więc dążyć do sprawnej organizacji pracy w dobrze zdefiniowanym i zarządzanym procesie wykonywania projektów. Często bowiem obecny stan można określić jedynie mianem "kompletna anarchia". Każdy robi "za kowboja", który radzi sobie w każdej sytuacji, ale sam. Gdy zaś przychodzi do wykonywania większego projektu, nikt nie potrafi zorganizować zespołu.

Należy także zatrudniać młodych programistów z otwartą głową i nowymi umiejętnościami. Nie pozwolić, aby zdominowali ich starzy "wyjadacze", którzy są na pewno w stanie wykazać tym młodym niekompetencję w dobrze znanych im dziedzinach. Ci młodzi też zapewne lekceważą starych "repów" nie mających pojęcia choćby o OO. Jeżeli da się zorganizować dobry cykl szkoleń, to skorzystają zarówno młodzi, jak starzy programiści i projekty informatyczne będą wykonywane szybko i skutecznie.

Jaki stan obecny?

Gdy napisałem mniej więcej dwa lata temu, że należy przewietrzyć polską informatykę, zostałem odsądzony od czci i wiary. Były to niestety głosy tych, którzy nadal dobrze czują się w świecie izolowanych komputerów, nie połączonych w sieci, realizujących aplikacje takie same od lat, a jednocześnie zupełnie nie panujących nad ich rozwojem. Miałem zresztą okazję przekonać się o tym rozmawiając z użytkownikami.

Przejście na nowe techniki i nowe narzędzia pozwoliłoby zwiększyć nie tylko wydajność produkcyjną, osiągnąć lepsze wykorzystanie raz wykonanej pracy, polepszyć konserwację produktów itd.

Według mej oceny w Polsce ok. 5% zespołów programistów zajmujących się profesjonalnie opracowaniem aplikacji korzysta - i to w niewielkim stopniu - z techniki obiektowej. Zapewne nie więcej niż 1% ludzi potrafi poruszać się w technice obiektowej z pełną świadomością jej możliwości i ograniczeń.

Istnieją pewne anegdotyczne wręcz historie o projektach zawierających ponad 1200 obiektów, których w żaden sposób nie dało się opanować ze względów organizacyjnych, ale są to wyjątki od reguły. Technika obiektowa to przyszłość, zwłaszcza informatyki do zastosowań w biznesie!