Wstęp

Imperatywne języki programowania, w tym języki obiektowe, są wyposażone w mechanizmy abstrakcji i hermetyzacji znane pod nazwą procedur. Istotą tych konstrukcji jest to, że hermetyzują one dowolnie skomplikowane obliczenia, ich wnętrze jest niedostępne z zewnątrz, mogą być wywoływane z wielu miejsc, zaś ich przystosowanie do konkretnego celu następuje poprzez określenie ich parametrów lub przez efekty uboczne, czyli korzystanie ze stanu spoza danej procedury lub zmiany tego stanu. W zależności od pewnych dodatkowych własności procedury mogą być dalej podzielone według następującej klasyfikacji:

• Procedury właściwe i procedury funkcyjne (zwane też funkcjami);
  
  
• Procedury vs. metody;
  
  
• Procedury znajdujące się po stronie programu aplikacyjnego i procedury przechowywane w bazie danych.
  

Procedury właściwe nie zwracają wyniku, nie mogą więc być użyte jako składniki wyrażeń, zaś procedury funkcyjne zwracają wynik i przez to ich wywołania są szczególnymi przypadkami wyrażeń.

Jeżeli chodzi o podział na procedury i metody, różnica dotyczy miejsca logicznego ulokowania kodu procedur oraz sposobu ich wywołania. Procedury są zwykle ulokowane w określonych jednostkach programu, np. w modułach, natomiast metody są zwykle ulokowane logicznie w klasach. Dodatkowo, niejawnym (pośrednim) parametrem metody jest obiekt, na którym ta metoda działa. Metodę funkcyjną (zwracającą wynik) nazywa się niekiedy atrybutem wirtualnym. Poza tym, różnice pomiędzy procedurami a metodami są drugorzędne (wbrew twierdzeniom niektórych zwolenników obiektowych języków programowania). Popularne w obiektowości "wysyłanie komunikatu do obiektu" jest dokładnie tym samym co wywołanie procedury (zwanej metodą) działającej na tym obiekcie.

Tradycyjnie, procedury po kompilacji są nierozerwalną częścią danego programu aplikacyjnego (są drugiej kategorii programistycznej), w związku z czym nie można ich podczas czasu wykonania usunąć, wstawić, zmienić itd. W systemach zarządzania bazami danych pojawił się inny typ procedury, zwany zapamiętaną procedurą (stored procedure) lub procedurą bazy danych (database procedure). Są to byty pierwszej kategorii programistycznej, wiązane dynamicznie. Można je dynamicznie tworzyć, usuwać lub zmieniać. Z reguły są pisane w specjalnym interpretowanym języku, np. w PL/SQL systemu Oracle. Ze względu na odmienność mechanizmu wiązania, związki z określonym modelem danych (np. relacyjnym) oraz mocną typizacją procedury bazy danych nie mogą być pisane w klasycznych lub obiektowych językach programowania, takich jak C++ lub Java.

Możliwa jest dowolna kombinacja tych opcji. Np. w systemie Oracle występują zapamiętane metody, czyli kombinacja procedur bazy danych i metod. Znane z SQL perspektywy (views) można uważać za zapamiętane procedury funkcyjne. W SQL definicje perspektyw są ograniczone do pojedynczego zdania SQL, co należy uważać za ograniczenie ad hoc nie posiadające głębszego uzasadnienia; wynika ono raczej z zaszłości historycznych oraz przyjętych algorytmów przetwarzania perspektyw w zapytaniach. Pomiędzy zapamiętanymi procedurami funkcyjnymi a perspektywami występują jednak głębsze różnice związane z problemem aktualizacji perspektyw (view updating).

Kolejną cechą, która może charakteryzować procedury, są efekty uboczne. Z reguły projektanci języków nie ograniczają możliwości dostępu do zasobów zewnętrznych, w tym danych globalnych i danych z bazy danych, oraz aktualizacji tych zasobów. Jednocześnie wykształcił się styl zapisu procedur i ich zewnętrznej specyfikacji, który ignoruje fakt, że mogą mieć efekty uboczne. Są opinie krytykujące ten stan rzeczy jako błędogenny. W oryginalnej propozycji Parnasa dotyczącej modułów efekty uboczne były uwzględnione w postaci tzw. list importowych. Rozwiązanie to zostało zastosowane w języku Modula-2 (następca Pascala). Brak specyfikacji i kontroli efektów ubocznych w popularnych językach programowania, takich jak C++ i Java, niedocenianie tego aspektu programistycznego jest, zdaniem autora, zwiększaniem skłonności oprogramowania do błędów. Najbardziej spektakularny błąd programistyczny, który zaowocował katastrofą rakiety Ariane-5 (co kosztowało 500 mln dolarów strat bezpośrednich), był spowodowany brakiem wyspecyfikowanych efektów ubocznych oprogramowania przenoszonego z poprzedniej rakiety Ariane-4.

Procedury mogą być rekurencyjne, co implikuje konieczność stosowania dyscypliny w zakresie komunikowania parametrów oraz mechanizmu kontrolującego zakresy obowiązywania nazw użytych w ciałach procedur oraz wiązania tych nazw. Mechanizmy te są oparte na stosie środowiskowym znanym nam z poprzedniego rozdziału. Dalej pokażemy, w jaki sposób ten stos będzie przystosowany do wspomagania wszelkiego rodzaju procedur (w tym metod). Będziemy przy tym przyjmować, że zarówno parametry procedur, jak i wynik procedur funkcyjnych będą określone poprzez zapytania.