Obecny stan programowania porównuje się do stanu produkcji przed wynalezieniem części zamiennych.

W czasach gdy nie znano pojęcia części zamiennych, doświadczony rzemieślnik dostawał surowiec, z którego ręcznie tworzył produkt. Jego jakość zależała od doświadczenia twórcy, a szybkość produkcji - od sprawności jednego człowieka. Jeżeli w trakcie używania wyrób został uszkodzony, mógł go naprawić jedynie równie wysoko wykwalifikowany rzemieślnik, który odtwarzał go, na podstawie oględzin uszkodzonego produktu.

Obecnie podobnie wygląda sytuacja większości projektów dotyczących oprogramowania. Badania pokazują, że w miarę wzrostu złożoności projektu, szybko rośnie jego "wadliwość"; duże systemy znane są z tego, że trudno je utrzymać w działaniu i usprawnić.

Zbyt często projekt zależy od jednej osoby, znającej go w całości, tj. projektanta systemu. Poszczególni programiści zajmują się swoją dziedziną, nie mają oglądu całości i nie wiedzą, jak ich część projektu pasuje do całości. Czterdzieści lat po opracowaniu koncepcji podprogramu, nadal opracowuje się programy ręcznie, linia kodu za linią.

Całość problemów gnębiących informatyków od początku lat 70. jest określana jako Kryzys Programistyczny. W przemyśle informacyjnym, w którym nowy produkt to idea usługi i jej programowa realizacja, kryzys ten ma przerażające skutki. Spektakularnym przykładem nieudanego przedsięwzięcia informatycznego jest system obsługi bagaży na lotnisku w Denver, który spowodował opóźnienie jego otwarcia o ponad rok i straty oceniane na około 1 mln USD za każdy dzień zwłoki.

Wysokie koszty projektów informatycznych zachęcały do poszukiwania lepszych metod budowania dużych systemów informatycznych. Kilkanaście lat temu pojawiła się technika obiektowa, zapowiadająca rozwiązanie kryzysu programistycznego. W połączeniu z dobrą praktyką inżynierską, technika obiektowa umożliwia zmniejszenie czasu "od pomysłu do produktu". Służy ona także programistom, umożliwiając im szybsze pisanie aplikacji łatwiejszych w utrzymaniu i wyższej jakości. Programy tworzone tradycyjnymi metodami, często są przestarzałe już w chwili uruchomienia. Nadszedł więc czas na zmiany.

Obiekty, stany i metody

Podobnie jak w wielu innych dziedzinach wiedzy, technika obiektowa zgromadziła własny zestaw terminów i definicji. Specjalizowany język często stanowi barierę dla osób, które chcą poznać nową dziedzinę. Rzadko zdarza się, aby świeży adept techniki obiektowej dobrze rozumiał, o co w niej naprawdę chodzi.

Obiekt software'owy reprezentuje obiekt świata rzeczywistego - adres, część zamienną - którą system informatyczny musi operować. Obiekt jest definiowany jako pakiet programowy, zawierający dane oraz wszystkie procedury i funkcje niezbędne do dostępu i operowania na danych. Dane zawarte w obiekcie często określa się mianem stanu obiektu. Funkcje zawarte w obiekcie to jego metody. Wywołanie dowolnej metody obiektu określa się mianem wysyłania komunikatu do obiektu, żądając od niego konkretnej usługi.

Stan obiektu przypomina struktury danych w tradycyjnym programowaniu strukturalnym. Metody można porównać do procedur bibliotecznych, powszechnie stosowanych w programowaniu proceduralnym. Analogia jest dobra, ale istnieją zasadnicze różnice. Na przykład w programowaniu proceduralnym dane można zmienić za pomocą kodu zawartego w dowolnym miejscu programu. W technice obiektowej wykonuje się je za pomocą jedynie metod obiektu. Obiekt jest otoczony nieprzezroczystą osłoną, ukrywającą jego wewnętrzną strukturę przed pozostałą częścią programu. To ukrywanie informacji określono terminem enkapsulacji (co jest prostym przeniesieniem angielskiego terminu na polski grunt) lub kapsułkowaniem (niepoprawny neologizm). Kapsułkowanie ma podstawowe znaczenie przy konserwacji oprogramowania i wielokrotnego używania jego komponentów.

W programowaniu proceduralnym np. aplikacja korzystająca z danych o miejscu zamieszkania, może używać wielu procedur do wyszukania kodu pocztowego. Procedury te pisane przez różnych programistów dla różnych potrzeb na pewno będą różne, mimo prawie takich samych właściwości.

To niepotrzebne powielanie kodu zwiększa rozmiar binariów i złożoność programu. Utrudnia także utrzymanie programu. Przy każdej zmianie struktury danych adresowych osoba odpowiedzialna za program musi prześledzić cały kod źródłowy, sprawdzając, czy zmiana struktury nie wpłynie na działanie poszczególnych procedur związanych z adresem. Taki sposób pisania kodu określono pogardliwie jako "kod spaghetti", lecz stosowany jest on często. Małe zmiany i poprawki kodu często powodują pojawienie się nowych błędów, mających wpływ na inne części kodu (efekt domina). Nie kończąca się praca przy utrzymaniu kodu!

Jeżeli natomiast adres będzie przechowywany jako obiekt, problem nie ma. Obiekt będzie zawierał tylko jedną metodę dostępu do kodu pocztowego i każdy programista musi jej użyć. Nawet jeśli uzna za celowe napisanie własnej metody dostępu, nie będzie mógł jej użyć, bowiem kapsułkowanie obiektów wyklucza tę możliwość. Zmiana struktury danych adresowych, dodanie do niej nowego elementu (np. regonu) lub dołączenie nowej albo ulepszenie starej metody dostępu/operowania na danych odbywa się tylko w jednym miejscu - w obiekcie.