W programowaniu obiektowym odpowiednikami zmiennych oraz funkcji w programowaniu strukturalnym są
Pola i metody to absolutna podstawa, jeśli chodzi o programowanie obiektowe. Właśnie one są najbliższym odpowiednikiem zmiennych i funkcji z podejścia strukturalnego. Moim zdaniem, gdy uczysz się OOP, warto od razu wyłapać tę analogię – pola (czyli inaczej: atrybuty, właściwości, fields) przechowują stan obiektu, a metody (czyli funkcje w klasie) definiują, co obiekt potrafi zrobić. Przykład z życia: klasa Samochód ma pole kolor, które opisuje jego cechę oraz metodę jedź(), która realizuje jakąś akcję. W praktyce programiści bardzo często modelują swoje klasy tak, aby pola były prywatne (zgodnie z zasadą hermetyzacji), a dostęp do nich zapewniały metody publiczne – tzw. gettery i settery. Standardy branżowe, np. JavaBeans w Javie czy konwencje C#, też polegają na tym, że pola odzwierciedlają dane, a metody operacje na tych danych. Z mojego doświadczenia wynika, że rozumienie tej relacji ułatwia zarówno pisanie czytelnego kodu, jak i jego dalsze rozwijanie. To właśnie dzięki rozdzieleniu na pola i metody klasy mogą odwzorowywać obiekty z realnego świata i ich zachowania, co jest głównym celem programowania obiektowego.
Wiele osób gubi się na początku, próbując przypisać funkcje i zmienne z programowania strukturalnego do bardziej zaawansowanych pojęć OOP, takich jak hermetyzacja, dziedziczenie, czy różne typy metod. Metody statyczne i abstrakcyjne to specjalne mechanizmy, które mają konkretne zastosowania: statyczne należą do klasy, nie do obiektu (nie przechowują stanu pojedynczego egzemplarza), a abstrakcyjne służą do definiowania interfejsu bez implementacji. Żadna z tych kategorii nie odzwierciedla podstawowego podziału na dane i operacje na nich, tak jak pola i metody. Hermetyzacja oraz dziedziczenie to zupełnie inne pary kaloszy – pierwsza dotyczy ukrywania danych i kontrolowania dostępu, druga umożliwia tworzenie hierarchii klas i ponowne wykorzystanie kodu. Oba te pojęcia są kluczowe w OOP, ale nie są odpowiednikami zmiennych i funkcji. Kwalifikatory dostępu, jak public, private czy protected, decydują, kto ma dostęp do pól czy metod, ale same w sobie nie są strukturami danych, ani funkcjonalnościami. Typowy błąd, z którym się spotykam, to mylenie mechanizmów zarządzających dostępem lub abstrakcji z podstawowymi elementami składowymi klasy. W praktyce, jeśli modelujesz klasę, zawsze najpierw myślisz o tym, jakie dane ma reprezentować (pola), a potem – jakie operacje można na tych danych wykonać (metody). Pozostałe aspekty, jak hermetyzacja czy wybór typu metody, są decyzjami na dalszym etapie projektowania, a nie bezpośrednimi odpowiednikami zmiennych i funkcji znanych z programowania strukturalnego.