Wielokrotne używanie obiektów

Już od dawna wszystkie właściwości techniki obiektowej - na ogół pod innymi nazwami - istniały w praktyce programowania proceduralnego. Dziedziczenie jest natomiast nowością techniki obiektowej i to ono zapewnia cechy dające tej technice przewagę nad innymi metodami projektowania.

Na rynku dostępnych jest wiele doskonale opracowanych zestawów funkcji bibliotecznych, służących do budowy większości aplikacji. Jednakże każdy programista woli napisać własne procedury, niż zastanawiać się, jakie parametry należy podać procedurze bibliotecznej, aby uzyskać żądany wynik. Ta praktyka wynika po części z chęci udowodnienia, że programista-twórca potrafi to zrobić lepiej, po części zaś dlatego, że nie podoba mu się interfejs funkcji lub jej dokumentacja. To właśnie powoduje te tony (tak, tak, licząc na wagę wydruków kodu) "kodu spaghetti" i kryzys oprogramowania.

Porównajmy to podejście z typową praktyką inżynierską w dowolnej dziedzinie produkcyjnej. Czy ktoś potrafi sobie wyobrazić inżyniera mechanika, projektującego każdą śrubę, dźwignię, a nawet podzespoły mechaniczne przy okazji konstruowania nowego ciągnika, samochodu czy dźwigu? Dobiera on większość elementów z katalogu konstrukcji typowych, opracowanych przez specjalistów, dokładnie przetestowanych, produkowanych tanio i szybko masowo. Sprzęgła, układy hamulcowe, reflektory, felgi, opony, a nawet silniki kupuje się od specjalistów, nie zaś projektuje i produkuje samodzielnie.

Celem technik obiektowych jest promowanie takiej samej metody tworzenia aplikacji z gotowych obiektów, kupowanych na rynku, w ostateczności opracowywanych we własnym zakresie. Obecnie większość interfejsu graficznego aplikacji wykonywana jest w taki sposób, korzystając z gotowych elementów (nie zawsze są to obiekty w rozumieniu techniki obiektowej), dostarczanych przez dostawcę pakietu narzędziowego.

Istnieje wiele poziomów złożoności obiektów, które można używać jako elementy składowe aplikacji informatycznych. Najdrobniejsze elementy to komponenty interfejsu graficznego; wyższy poziom to duże procedury funkcjonalne - księga główna, moduł obsługi magazynu, lista płacy; można z nich tworzyć wielkie aplikacje biznesowe. Wreszcie najwyższy poziom to gotowe aplikacje, które - otoczone powłoką obiektową - stanowią części składowe większego systemu informatycznego.

Przykładem takiego podejścia jest czyniona obecnie próba "skomponentyzowania" modułów funkcjonalnych największej aplikacji do zarządzania przedsiębiorstwem SAP R/3 i umożliwienie klientowi łączenie ich w zależności od potrzeb. W metodzie wielokrotnego użycia modułów SAP niewiele jest technik obiektowych, więcej technik marketingowych.

Techniki wielokrotnego używania obiektów

Techniki wielokrotnego używania obiektów można pogrupować w trzy duże (nie wykluczające się) kategorie. W każdej z nich wykorzystuje się specyficzne cechy technologii obiektowej: dziedziczenie, kapsułkowanie i polimorfizm.

Najpopularniejsza jest technika wielokrotnego używania obiektów poprzez dziedziczenie właściwości. Zdefiniowanie subklasy na podstawie klasy oryginalnej (superklasy) oznacza dziedziczenie przez nią wszystkich metod, a więc i całego kodu, który wbudowali w nią twórcy. Można ją wykorzystywać do używania obiektów utworzonych lokalnie w firmie, jak również zakupionych na rynku, a oferta jest bogata.

Druga technika polega na używaniu gotowych obiektów, spełniających wymagania, i używać ich bez zmiany właściwości jako komponentów, z których składa się aplikacje. Podobnie jak poprzednio, mogą to być komponenty opracowane samodzielnie, kupione na rynku lub stanowiące wyposażenie pakietów narzędziowych do tworzenia aplikacji.

Większość gotowych komponentów występuje w zestawach bibliotecznych w kodzie maszynowym, specyficznym do realizacji sprzętowej i systemowej, dołączanych do aplikacji podczas jej konsolidowania. Nowe techniki komunikacyjne, sieć WWW i jej protokoły komunikacyjne mają stworzyć możliwość korzystania z rozproszonych obiektów, które nie będą łączone do pliku wykonywalnego aplikacji, ale staną się dostępne dynamicznie z serwera sieciowego lub lokalizacji !WWW. Wymaga to jednak rozwiązania wielu problemów technicznych i legislacyjnych. Zajmują się nimi m.in. konsorcjum Object Management Group (OMG) i inne organizacje standaryzujące.