O rozlicznych zaletach programowania zorientowanego obiektowo słyszał już chyba każdy. Niestety tworzenie programów za pomocą języków obiektowych ma także swoje ciemniejsze strony.

Coraz więcej aplikacji jest pisana za pomocą języków programowania obiektowego. Wedle badań Microsoftu, ok. 17% programistów tworzących aplikacje pod MS Windows, w swojej pracy posługuje się językiem C++, a daleko większa grupa wyraża duże zainteresowanie "obiektowym" podejściem do programowania okienek.

Jednak dotychczasowa ekspansja języków obiektowych okazała się daleko mniejsza niż tego oczekiwano. Zdecydowana większość firm programistycznych posługuje się standardowymi językami, takimi jak C. Wbrew temu co chcą twierdzić niektórzy prawomyślni akademicy, źródeł tej inercji nie należy szukać w opieszałości czy wręcz lenistwie informatyków. Wolnym rynkiem zawsze rządzi pieniądz, a przeniesienie się w środowisko obiektowe wymagać musi ogromnych nakładów finansowych. Dobrodziejstwa płynące z budowania aplikacji za pomocą języków obiektowo zorientowanych wcale nie muszą zrównoważyć kosztów poniesionych na zatrudnienie nowych pracowników bądź przeszkolenie dotychczasowych. Właśnie dlatego popularność zyskuje C++, a nie Smalltalk czy Eiffel. Lepsze, niestety, nie zawsze znaczy tańsze.

Należy jednak pamiętać, że programowanie obiektowe nie jest żadnym złotym środkiem, a wszystkie jego zalety łatwo mogą się przeistoczyć w wady. Wszystko wygląda ładnie i logicznie, gdy mamy do rozwiązania mały problem, ale kiedy przyjdzie do pisania ogromnej aplikacji, w skład której wchodzą setki czy nawet tysiące obiektów, sprawa poważnie się komplikuje. Tak zachwalana hermetyzacja, polimorfizm i dziedziczenie mogą wówczas przyczynić się do powstania ogromnej liczby małych klas, których funkcji i wzajemnego współdziałania nie sposób prześledzić.

Oczywiście tradycyjne języki programowania mogą przysporzyć znacznie więcej rozmaitych problemów. Dla twórcy programu najważniejsza jest jego struktura, którą można wyrazić chociażby w postaci diagramów przepływu danych czy związkach encji. Użytkownik testujący oprogramowanie zainteresowany jest natomiast jego zachowaniem i zawsze postrzega je właśnie od tej strony. Opracowano wiele wydajnych metod testowania programów. Problem polega na tym, że języki programowania obiektowego są oparte na zupełnie innym paradygmacie. Jeśli patrzy się na działanie całej obiektowo napisanej aplikacji, to taki program przypomina swoim funkcjonowaniem raczej języki deklaratywne (większość podejmowanych akcji jest tutaj w gruncie rzeczy obsługą różnorodnych komunikatów, przez które rozumie się wywołanie metody wraz z towarzyszącymi jej parametrami). Dynamiczne łączenie tworzy z kolei ogromną liczbę różnorodnych kontekstów w jakich może znaleźć się procedura czy pojedynczy obiekt. Zawodzą wówczas tradycyjne metody testowania programów. Brak opracowania nowych reguł weryfikacji poprawności działania jest dzisiaj najsłabszą stroną języków obiektowych. Ta odmienność koncepcji, na której są one oparte, sprawia, że zwyczajnie nie przystają do obecnego stanu wiedzy o testowaniu oprogramowania.

Nadzieja leży w tym, że świat nie stoi w miejscu. Języki programowania obiektowego są tylko jednym z kroków na drodze budowy sprawnych i elastycznych narzędzi tworzenia coraz bardziej niezawodnego oprogramowania.