Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

Wydaje mi się, że często początkujący mają problem z rozróżnieniem między polami, metodami a funkcjami, szczególnie że w niektórych językach te pojęcia się trochę mieszają. Funkcje i metody służą do wykonywania operacji – czyli do działania, modyfikowania czegoś, wyliczania, a nie do przechowywania danych. Jeśli próbujesz zrobić z ‘marka’ czy ‘rocznik’ funkcję lub metodę, tracisz całą strukturę danych, bo te wartości powinny być częścią obiektu – czyli być przechowywane jako pola. Interfejsy to zupełnie inna bajka – one opisują, co klasa powinna potrafić (czyli jakie metody ma mieć), ale same nie przechowują żadnych danych. To tak jakbyś powiedział, że samochód jest instrukcją obsługi, a nie fizycznym przedmiotem z konkretnymi atrybutami. Typowym błędem jest też mylenie pojęcia 'parametry' jako argumentów funkcji – tutaj chodzi o właściwości opisujące obiekt, więc nie pasuje to do funkcji ani metod. Dopiero po zrozumieniu, że pola są miejscem przechowywania stanu obiektu, można dobrze zaprojektować klasę oddającą realny obiekt z rzeczywistości. W praktyce, złe przypisanie atrybutów do funkcji czy interfejsów skutkuje chaosem w kodzie, trudnościami w utrzymaniu aplikacji oraz problemami z rozwojem projektu. Pola są po prostu fundamentem do budowania logiki obiektowej i każda próba ich zastąpienia innymi mechanizmami rodzi niepotrzebne komplikacje.