Technika obiektowa to przyszłość programowania, ale wymaga czasu i sporych pieniędzy na gruntowne przeszkolenie zespołu.

Idea obiektów jest powszechnie znana, toteż całkowicie inne spojrzenie, do którego usiłują nas przekonać zwolennicy tej metody programowania, bardzo utrudnia przyswojenie idei techniki obiektowej. Jeżeli jednak przywrócimy obiektom ich naturalne znaczenie - jako samodzielnych części oprogramowania, z których można składać aplikacje, to ich akceptacja może okazać się łatwiejsza (choć nie zmieni to w istotny sposób trudu programisty). Trud, jaki trzeba włożyć w składanie aplikacji z komponentów, zależy od tego, na ile jedna aplikacja różni się od następnej.

Elementy typowe

Interfejs użytkownika (menu, opcje, pasek narzędziowy i stanu, okienko dialogowe Tak/Nie/Anuluj) to typowy element używany praktycznie bez zmiany w każdej aplikacji. Programista nie musi zajmować się takimi elementami aplikacji, gdyż ich gotowe wersje są dostępne w wielu komercyjnych i stosunkowo tanich bibliotekach. Szef zespołu, który każe budować u siebie w przedsiębiorstwie takie elementy aplikacji, marnuje cenny czas programistów.

Inne komponenty, także używane w różnych wersjach w interfejsie użytkownika, wymagają jedynie nieznacznych zmian od aplikacji do aplikacji. Przykładowo, rozwijana lista opcji wymaga od programisty jedynie wpisania nowego zestawu opcji. Takie łatwo modyfikowalne elementy są także w sprzedaży.

Komponenty nie muszą się jednak ograniczać do stosunkowo niewielkich elementów aplikacji. Wyobraźmy sobie aplikację do obsługi ubezpieczeń samochodowych. Można ją złożyć z kilku typowych, dużych komponentów:

• do wczytywania szkicu kolizji samochodowej potrzebny jest program obsługi skanera;

• aplikacja do wprowadzania danych o kolizji z opisu uczestników może mieć kształt typowej formatki ekranowej, opracowanej za pomocą jednego z licznych dostępnych na rynku programów do tworzenia formularzy;

• konieczność napisania informacji dla klienta i wysłania listu oznacza użycie standardowego procesora tekstowego;

• akceptację szefa można uzyskać, przesyłając mu pocztą elektroniczną kompletny zestaw dokumentów utworzonych podczas opisania szkody.

Jak wynika z przykładu, trud programisty sprowadza się do zintegrowania we wspólnym interfejsie graficznym (także stworzonym z gotowych komponentów) kilku gotowych większych komponentów-aplikacji.

Elementy specyficzne

Przykładem komponentów wymagających opracowania w przedsiębiorstwie będą zapewne te elementy aplikacji, które opisują specyfikę jego działania, tj. komponenty biznesowe. Opisują one ustalone w firmie i ogólne zasady działania: jakie rabaty się przyznaje, jakiego kredytu można udzielić zależnie od statusu klienta, jakie są narzuty i jakie podatki należy doliczyć itp.

Jednym z ważnych elementów procesu składania aplikacji jest możliwość komunikowania się komponentów między sobą. Aby mogły to czynić, muszą wiele "wiedzieć" o sobie: jak każdy z nich działa, jakich danych i w jakim formacie potrzebuje, jakie są dostępne polecenia dla tego komponentu i jak na nie odpowiada. Próbę standaryzowania interfejsu komunikacji między komponentami podjęło konsorcjum firm, do którego należą m.in. HP, Microsoft, Oracle i Texas Instruments (od kilku miesięcy Texas Instruments wycofuje się z działalności informatycznej, więc zapewne jego rolę przejmie Sterling Software, który kupił wiele produktów TI). Konsorcjum zgłosiło projekt takiego interfejsu do organizacji Object Management Group (OMG), zajmującej się standaryzacją komunikacji obiektowej w środowisku rozproszonym.

Repozytorium

Drugim ważnym elementem środowiska do składania aplikacji jest repozytorium komponentów, tj. miejsce, gdzie przechowuje się informacje o wszystkich komponentach używanych w firmie, łącznie z ich lokalizacją na serwerze. Do obsługi niewielkiego zestawu komponentów wystarczy proste repozytorium dostępne w większości pakietów narzędziowych CASE i niektórych narzędziach do szybkiego generowania aplikacji.

Poważni producenci od lat zapowiadają opracowanie taniego, a jednocześnie wysoko wydajnego, uniwersalnego repozytorium, które zastąpi rozproszone repozytoria narzędziowe, ale - jak dotąd - są to jedynie obietnice. Uniwersalne repozytoria są oczywiście dostępne, ale ich cena jest raczej zaporowa. Wydaje się, że najbliżej do opracowania idealnego repozytorium jest Microsoft, współpracujący od dwóch lat z Texas Instruments.

Zarządzanie konfiguracją

Ważne, choć nie niezbędne, są programy do tzw. zarządzania konfiguracją, pozwalające na "wypożyczanie" komponentów od "bibliotekarza" w celu użycia lub modyfikacji, składowania ich łącznie z opisem wersji oraz zarządzania kodem źródłowym aplikacji. Większe zespoły programistyczne (ponad 10 osób) w zasadzie nie mogą się obyć bez pewnego programu zarządzania konfiguracją.

Firmy korzystające z intranetu mają większe możliwości dostępu do opisu komponentów, a nawet mogą je obejrzeć (jeśli są to elementy graficzne) za pomocą typowych narzędzi Web.

Repozytorium komponentów nie powstaje samo, nawet jeśli kupimy kilkanaście gotowych elementów interfejsu użytkownika czy dostępu do bazy danych. To lokalni programiści muszą je uzupełniać o przydatne im komponenty, opracowane w firmie, dostępne za darmo do testowania lub uzyskane razem z aplikacjami. Aby je pielęgnować, trzeba wyznaczyć osobę za nie odpowiedzialną - bibliotekarza komponentów.