OOP (Object-Oriented Programming, programowanie obiektowe) to paradygmat, w którym kod organizujesz wokół obiektów — bytów łączących w jednym miejscu dane (pola, stan) i zachowania (metody operujące na tych danych). Zamiast jednej długiej procedury, która przepycha zmienne od funkcji do funkcji, modelujesz fragment rzeczywistości: masz obiekt Uzytkownik, który sam wie, jak się zalogować, i Koszyk, który sam liczy swoją wartość.
Fundament OOP to klasy i obiekty. Klasa to szablon (przepis), obiekt to konkretny egzemplarz stworzony z tego szablonu. Na tym opierają się cztery filary: enkapsulacja (ukrywasz wewnętrzny stan i wystawiasz tylko bezpieczne metody), dziedziczenie (klasa może rozszerzać inną, przejmując jej zachowania), polimorfizm (ten sam interfejs, różne implementacje) oraz abstrakcja (pokazujesz „co”, chowasz „jak”). Dzięki temu kod łatwiej testować, ponownie wykorzystać i utrzymać, gdy projekt rośnie.
Jak to wygląda w praktyce
Załóżmy, że piszesz sklep w Pythonie. Tworzysz klasę i działasz na obiekcie:
class Product:— definicja klasy z polaminameipricedef __init__(self, name, price):— konstruktor ustawiający standef discount(self, pct):— metoda zmieniająca cenę obiektup = Product("Mysz", 100)— tworzysz konkretny obiektp.discount(10)— wołasz zachowanie na tym obiekcie
Każdy Product pilnuje własnej ceny — nie musisz przekazywać jej w globalnych zmiennych. To samo robisz w Javie (class, new), C# czy JavaScript (od ES6 też masz słowo kluczowe class, choć pod spodem siedzą prototypy).
Częste błędy i mity
Najpopularniejsza pułapka juniorów to nadużywanie dziedziczenia. Tworzą głębokie hierarchie typu „Pies dziedziczy po Ssak dziedziczy po Zwierzę”, a potem nie da się tego zmienić. Złota zasada brzmi: preferuj kompozycję nad dziedziczeniem — częściej składaj obiekty z mniejszych klocków, niż buduj wieżę dziedziczenia.
Drugi mit: „OOP to jedyny słuszny sposób”. Nieprawda. Programowanie funkcyjne czy proceduralne bywa lepsze do konkretnych zadań, a wiele języków (Python, Scala, Kotlin) miesza paradygmaty. OOP to narzędzie, nie religia. Uważaj też na klasy-potwory, które robią wszystko (tzw. God Object) — to znak, że łamiesz zasadę pojedynczej odpowiedzialności.
Pojęcia powiązane: klasa, obiekt, enkapsulacja, dziedziczenie, polimorfizm, interfejs, kompozycja, zasady SOLID, design patterns, programowanie funkcyjne.