We wcześniejszych odcinkach tej serii felietonów pisałem o różnych językach programowania. Przy okazji omawiania niektórych spośród tych języków pojawiało się stwierdzenie, że są to języki obiektowe. Nie było przy tym miejsca na wyjaśnienie, czym właściwie jest obiektowość i jaką drogę przebyła ta metoda myślenia o programach od ogólnej koncepcji do realizacji we współczesnych narzędziach programowania. Tę lukę wypełni dzisiejszy felieton.
Przy programowaniu komputerów możliwe są różne podejścia. Do dyspozycji jest wiele koncepcji, spośród których programista musi wybrać tę, do której chce się stosować. Z koncepcją taką wiąże się zawsze zbór spójnych zasad, wokół których organizowany jest tekst tworzonego programu. Ten zbiór zasad nazywany jest paradygmatem programowania. W tym felietonie będę opisywał paradygmat programowania obiektowego i jego historyczną ewolucję, ale muszę zacząć od tego, co było wcześniej, zanim ten paradygmat sformułowano.
Paradygmaty imperatywny i strukturalny
Pierwsze języki programowania, jakie stworzono po to, żeby proces stawiania zadań komputerowi uczynić łatwiejszym i wygodniejszym dla człowieka, ukierunkowane były głównie na specyfikację czynności, które komputer ma wykonać. Znajdowało to odbicie nawet w ich nazwach: FORTRAN, czyli tłumacz wzorów matematycznych, ALGOL, czyli język do zapisywania algorytmów – pisałem o nich w artykule „Pierwsze języki programowania” („Rzecz o Historii” z 31 grudnia 2021 r.). Ten paradygmat sformułowany na przełomie lat 50. i 60. XX wieku nazywamy obecnie paradygmatem imperatywnym. Program to był zestaw poleceń: zrób to, sprawdź tamto, wykonaj wielokrotnie itp. Taki sposób programowania pozwalał na szybkie uzyskanie programu o wymaganych cechach, był więc ceniony i chętnie używany. Jednak ten paradygmat miał istotne ograniczenie: programy tak pisane trudno było adaptować do nowych wymagań, a prawie każdy program po dłuższej eksploatacji wymaga pewnych zmian wynikających z ewolucji potrzeb użytkowników programu oraz ze zmienności otoczenia (choćby z przepisów prawnych).
Odpowiedzią był nowy paradygmat programowania strukturalnego. Zakładał on podzielenie programu na segmenty, z których każdy powinien mieć dokładnie zdefiniowany cel i zrozumiałą budowę. Taki sposób programowania bardzo porządkował działania programu, a w przypadku koniecznej modyfikacji wiadome było, co i gdzie należy zmienić. Był chętnie stosowany przez kilka dziesięcioleci, ale miał słaby punkt: wszystkie ładnie wydzielone segmenty operowały na wspólnych zasobach danych. Wprawdzie te dane mogły być przekazywane do segmentów przez specjalne mechanizmy parametrów formalnych i aktualnych, ale niestety „majstrowanie” na tych samych danych przez różne segmenty, pisane często przez oddzielnych programistów (bo duże programy tworzy się w dużych zespołach programistów), prowadziło czasem do trudno wykrywalnych błędów. Utarło się brzydkie powiedzenie, że często jeden programista „zapluwał” dane innemu programiście, który w efekcie nie wiedział, co się dzieje. To spostrzeżenie otworzyło drogę do omawianych w tym felietonie metod programowania obiektowego.
Paradygmat obiektowy
W połowie lat 60. XX wieku w środowiskach informatyków zaczęła dojrzewać idea, że dane trzeba chronić. Postanowiono chować je w niedostępnych z zewnątrz „kapsułach”, gdzie jedynymi procedurami, które mogą na tych danych wykonywać określone działania, będą elementy owej „kapsuły”. Wzorzec takiej kapsuły nosi nazwę klasy, a na podstawie tego wzorca można wytworzyć dowolnie dużo egzemplarzy konkretnych obiektów mających formę kopii owego wzorca (klasy), ale wypełnionych konkretnymi danymi. Całą pracę w programie wykonują obiekty (stąd nazwa „paradygmat obiektowy”), które mogą wzajemnie od siebie czegoś wymagać, wysyłając i odbierając komunikaty, ale wszelkie operacje na danych w środku kapsuły wykonują tylko procedury wbudowane w ściany tej kapsuły.