Programowanie obiektowe jest jednym z dostępnych paradygmatów programowania polegających na podzieleniu problemu na obiekty starając się zachować najbardziej zbliżony podział jak w rzeczywistości. Wszystko w informatyce rządzi się własnymi prawami, a pewne 4 zasady programowania obiektowego muszą Wam być znane. Opanujcie to jak najprędzej, gdyż znajomość tych zasad jest często weryfikowana na egzaminach i rozmowach. Najpopularniejszym "przedstawicielem" tego paradygmatu jest oczywiście Java, natomiast istnieje o wiele więcej języków wspierających programowanie obiektowe.
| Tweet |
WSZYSTKIE 4 ZASADY PROGRAMOWANIA OBIEKTOWEGO
Przedstawione tu zasady nie są jedynymi, które powinny obowiązywać przy pisaniu w stronę obiektowości. Są to jedynie najważniejsze i najczęściej spotykane frazy gdy mowa o programowaniu obiektowym. Częstym problemem u ludzi jest mylenie terminów z definicjami. Mimo wszystko, trzeba jak najszybciej sobie wytłumaczyć te cztery terminy i zachować je w głowie do końca życia, a przynajmniej do momentu kiedy odpuścimy sobie już programowanie obiektowe.
DZIEDZICZENIE
Pierwsza zasada to możliwość dziedziczenia przez obiekty czyli ustalanie relacji i powiązań między obiektami od "części wspólnej" do szczegółowych reprezentacji. Wszystkie dane składowe (nie "zmienne") i metody mające dostęp publiczny lub chroniony będą "przenoszone" na klasę potomną. To 1 z 4 zasad programowania obiektowego. Ważne szczegółowe zagadnienia odnośnie dziedziczenia zostały przeze mnie ukazane zarówno na języku Java, jak i na "CSharpie".
ENKAPSULACJA / HERMETYZACJA / KAPSUŁKOWANIE
Tutaj pojawiają się problemy z terminami, bo ta zasada posiada kilka synonimów. Jest to określanie dostępu do danych składowych i metod poprzez modyfikatory dostępu, czyli co ma być dostępne dla każdego, a co ma być prywatne i zabezpieczone przed modyfikacją z zewnątrz ("public", "private", "protected"). Programowanie obiektowe wręcz wymaga odpowiedniej dbałości o ochronę danych. Dlaczego? Zapraszam na wytłumaczenie na języku C# albo na Javie.
POLIMORFIZM / WIELOPOSTACIOWOŚĆ
Oto kolejna zasada mówiąca tyle, że dane wyrażenie można zapisać na kilka sposobów. Przykładem jest obiekt dziedziczący po klasie bazowej, który można podstawić do zmiennej typu klasy bazowej lub też wywołanie indywidualnej treści tej samej metody interfejsu dla każdego obiektu w pętli. Więcej informacji znajdziecie w osobnym artykule dotyczącym języka Java. Na 4 zasady programowania obiektowego sprowadza się coś jeszcze, co wcześniej przegapiłem.
ABSTRAKCJA
I ostatnia zasada poruszająca zagadnienie abstrakcyjności danych składowych i metod celem wymuszenia ich zdefiniowania przez klasy potomne, nieabstrakcyjne (chyba, że one także są abstrakcyjne). Kiedy coś jest abstrakcyjne, to oznacza niemożliwe do ścisłego określenia na ogólnym poziomie klasy (mowa o klasie bazowej, która zwykle dysponuje tylko "szkieletem" informacji dla późniejszych uszczegółowionych klas). Kiedy klasa potomna nie jest abstrakcyjna, kompilator nie dopuści do kompilacji, dopóki wszystkie abstrakcyjne dane nie zostaną jasno zdefiniowane. Tak się składa, że o tym też napisałem całą litanię, więc zapraszam do artykułu na języku C# albo na Javie, to już jak chcecie.
Jeżeli kiedykolwiek będziecie "przesiadywać" na długo wykorzystując programowanie obiektowe, to zdecydowanie lepiej pójdzie Wam budowa programów przy rozumieniu powyższych wyrażeń. One naprawdę są częstym tematem na egzaminach i sprawdzianach. To jest taki króciutki artykuł mający na celu przypomnienie fundamentalnych założeń jakie muszą być spełnione, żeby program miał ręce i nogi. Programowanie obiektowe jest bardzo przyjemnym "sposobem widzenia" i podejrzewam, że jeszcze przez wiele dekad nie wypadnie z powszechnego użytku. Dlatego te wszystkie 4 zasady programowania obiektowego wymagają dokładnego rozumienia ich znaczenia!