Programowanie obiektowe

From Obrona

(Difference between revisions)
m (usunięty zbędny link)
Line 1: Line 1:
-
'''Programowanie obiektowe''' (ang. ''object-oriented programming'') to metodologia tworzenia [[Oprogramowanie|programów komputerowych]], która definiuje programy za pomocą "[[obiekt|obiektów]]" - elementów łączących ''stan'' (czyli dane) i ''zachowanie'' (czyli procedury, tu: ''metody''). Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań. Podejście to różni się od tradycyjnego programowania proceduralnego, gdzie dane i procedury nie są ze sobą bezpośrednio związane. Programowanie obiektowe ma ułatwić pisanie, konserwację i wielokrotne użycie programów lub ich fragmentów.
+
'''Programowanie obiektowe''' (ang. ''object-oriented programming'') to metodologia tworzenia programów komputerowych, która definiuje programy za pomocą "[[obiekt|obiektów]]" - elementów łączących ''stan'' (czyli dane) i ''zachowanie'' (czyli procedury, tu: ''metody''). Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań. Podejście to różni się od tradycyjnego programowania proceduralnego, gdzie dane i procedury nie są ze sobą bezpośrednio związane. Programowanie obiektowe ma ułatwić pisanie, konserwację i wielokrotne użycie programów lub ich fragmentów.
==Programowanie obiektowe a rzeczywistość==
==Programowanie obiektowe a rzeczywistość==

Revision as of 07:57, 25 June 2006

Programowanie obiektowe (ang. object-oriented programming) to metodologia tworzenia programów komputerowych, która definiuje programy za pomocą "obiektów" - elementów łączących stan (czyli dane) i zachowanie (czyli procedury, tu: metody). Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań. Podejście to różni się od tradycyjnego programowania proceduralnego, gdzie dane i procedury nie są ze sobą bezpośrednio związane. Programowanie obiektowe ma ułatwić pisanie, konserwację i wielokrotne użycie programów lub ich fragmentów.

Contents

Programowanie obiektowe a rzeczywistość

Największym atutem programowania, projektowania oraz analizy obiektowej jest zgodność takiego podejścia z rzeczywistością - mózg ludzki jest w naturalny sposób najlepiej przystosowany do takiego podejścia przy przetwarzaniu informacji. Już Arystoteles analizując rzeczywistość wprowadził pojęcia formy (odpowiednika platońskiej idei) i materii. Formie w programowaniu obiektowym odpowiada Klasa, materii - instancja - obiekt. Jest to najbardziej naturalny sposób rozumienia rzeczywistości - podstawową cechą mózgu ludzkiego jest klasyfikacja - łączenie występujących w rzeczywistości obiektów w grupy - klasy. Odbywa się to na podstawie wspólnych cech dla grup obiektów - w tym podobnych zachowań. Od urodzenia cały świat jawi się nam jako zbiór obiektów, które wchodzą ze sobą w interakcje. Obiekty te w trakcie poznawania coraz większej ich ilości grupujemy w klasy. Korzystając z podejścia obiektowego przy programowaniu korzystamy w najlepszy sposób z właściwości naszego mózgu - jesteśmy w stanie panować nad większymi strukturami, niż przy innych - mniej naturalnych podejściach. Jeżeli działający program ma być pewnym tworem przetwarzającym informację - pewnym modelem rzeczywistości - to im bardziej ten twór będzie naśladował rzeczywistość, w której żyjemy - tym lepiej będzie z nią współpracował (tym bardziej będzie zrozumiały). Jest to zgodne z teorią, która mówi, że tym lepszy jest model, im bardziej jest zgodny z rzeczywistością.

Podstawowe założenia paradygmatu obiektowego

Istnieje pewna różnica zdań co do tego, jakie cechy metody czy języka programowania czynią je "orientowanymi obiektowo", jednak powszechnie uważa się, że najważniejsze są następujące cechy:

Abstrakcja

Każdy obiekt w systemie służy jako model abstrakcyjnego "wykonawcy", który może wykonywać pracę, opisywać i zmieniać swój stan, oraz komunikować się z innymi obiektami w systemie, bez ujawniania, w jaki sposób zaimplementowano dane cechy. Procesy, funkcje lub metody mogą być również abstrahowane, a kiedy tak się dzieje, konieczne są rozmaite techniki rozszerzania abstrakcji.

Enkapsulacja

Czyli ukrywanie implementacji, hermetyzacja. Zapewnia, że obiekt nie może zmieniać stanu wewnętrznego innych obiektów w nieoczekiwany sposób. Tylko wewnętrzne metody obiektu są uprawnione do zmiany jego stanu. Każdy typ obiektu prezentuje innym obiektom swój "interfejs", który określa dopuszczalne metody współpracy. Pewne języki osłabiają to założenie, dopuszczając pewien poziom bezpośredniego (kontrolowanego) dostępu do "wnętrzności" obiektu. Ograniczają w ten sposób poziom abstrakcji.

Polimorfizm

Referencje i kolekcje obiektów mogą dotyczyć obiektów różnego typu, a wywołanie metody dla referencji spowoduje zachowanie odpowiednie dla pełnego typu obiektu wywoływanego. Jeśli dzieje się to w czasie działania programu, to nazywa się to późnym wiązaniem lub wiązaniem dynamicznym. Niektóre języki udostępniają bardziej statyczne (w trakcie kompilacji) rozwiązania polimorfizmu - na przykład szablony i przeciążanie operatorów w C++.

Dziedziczenie

Porządkuje i wspomaga polimorfizm i enkapsulację dzięki umożliwieniu definiowania i tworzenia specjalizowanych obiektów na podstawie bardziej ogólnych. Dla obiektów specjalizowanych nie trzeba redefiniować całej funkcjonalności, lecz tylko tę, której nie ma obiekt ogólniejszy. W typowym przypadku powstają grupy obiektów zwane klasami, oraz grupy klas zwane drzewami. Odzwierciedlają one wspólne cechy obiektów.

Historia programowania obiektowego

Koncepcja programowania obiektowego pierwotnie pojawiła się w Simuli 67, języku zaprojektowanym do zastosowań symulacyjnych, stworzonym przez Ole-Johana Dahla i Kristena Nygaarda z Norsk Regnesentral w Oslo. (Mówi się, że pracowali oni nad symulacjami zachowania się statków i mieli kłopoty z opanowaniem wszystkich zależności, jakie wywierały na siebie nawzajem wszystkie parametry statków w symulacji. Wtedy wpadli na pomysł, by pogrupować typy statków w różne klasy obiektów, a każda z klas sama odpowiadałaby za określanie własnych danych i zachowań.) Później koncepcja została dopracowana w języku Smalltalk, stworzonym w Simuli w Xerox PARC, ale zaprojektowanym jako w pełni dynamiczny system, w którym obiekty mogą być tworzone i modyfikowane "w locie", a nie system oparty na statycznych programach.

Programowanie obiektowe zyskało status techniki dominującej w połowie lat 80-tych, głównie ze względu na wpływ C++, stanowiącego rozszerzenie języka C. Dominacja C++ została utrwalona przez wzrost popularności graficznych interfejsów użytkownika, do tworzenia których programowanie obiektowe nadaje się szczególnie dobrze.

W tym okresie cechy obiektowe dodano do wielu języków programowania, w tym Ady, BASIC-a, Lisp-a, Pascala i innych. Dodanie obiektowości do języków, które pierwotnie nie były do niej przystosowane zrodziło szereg problemów z kompatybilnością i konserwacją kodu. Z kolei "czysto" obiektowym językom brakowało cech, z których programiści przyzwyczajeni byli korzystać. By zapełnić tę lukę podejmowano liczne próby stworzenia języków obiektowych dostarczających jednocześnie "bezpiecznych" elementów proceduralności. Eiffel Bertranda Meyera był wczesnym przykładem w miarę udanego języka spełniającego te założenia; obecnie został on w zasadzie całkowicie zastąpiony przez Javę, głównie za sprawą pojawienia się Internetu, dla którego Java dostarcza szeregu użytecznych funkcji.

Podobnie, jak programowanie funkcyjne doprowadziło do udoskonalenia technik takich, jak programowanie strukturalne, do współczesnych metod projektowania oprogramowania obiektowego zaliczają się takie usprawnienia, jak design patterns, design by contract i języki modelowania (np. UML).

Obiektowość rozprzestrzeniła się dość znacznie, jednak zwykle w systemach hybrydowych, w połączeniu z programowaniem niskopoziomowym (C++), funkcyjnym (Ruby, Ocaml, niektóre dialekty Lisp-a), sieciowym (Java), skryptowym (Perl, Python) itd. Systemy czysto obiektowe typu Smalltalk nie znalazły zbyt szerokiego zastosowania.

Różne podejścia do realizacji paradygmatu

Niektóre języki wprowadzają modyfikacje do założeń obiektowości, na przykład:

  • w niektórych językach każda klasa musi mieć nadklasę
  • w niektórych językach nadklas może być więcej niż jedna

Elementarna charakterystyka cech popularnych języków programowania obiektowego

Powyższa charakterystyka dopuszcza bardzo dużą różnorodność - i w rzeczywistości, o ile systemy programowania strukturalnego czy funkcyjnego były do siebie stostunkowo podobne, o tyle systemy obiektowe różnią się tak bardzo, że nie wiadomo co tak naprawdę znaczy nazwa obiektowe.

  • Dziedziczenie wielokrotne:
    • jest: C++, Python, Incr Tcl
    • tylko interfejsy: Object Pascal, Java, C#
    • tylko metody: Ruby
  • Klasa jest obiektem:
    • tak: Ruby, Python, Java (za pomocą obiektu Class)
    • nie: C++, C#, Ocaml
  • Wszystkie obiekty wywodzą się z jednego korzenia i muszą mieć nadklasę:
    • tak: Java, C#, Ruby, Object Pascal, Incr Tcl, Python (klasy nowego typu)
    • nie: C++, Ocaml, Python (klasy starego typu)
  • Obiekt można pytać do której podklasy należy:
    • tak: Ruby, C#, C++ (z RTTI), Java (RTTI lub mechanizm refleksji), Python, Object Pascal, Incr Tcl
    • nie: Ocaml
  • Mechanizm szablonów do automatycznego generowania klas (np. szablon Drzewo_Binarne<> z klasy X tworzy Drzewo_Binarne<X>):
    • tak: Ruby, C++, Ocaml, C# 2.0
    • nie: Java, (od wersji 1.5 wprowadzono mechanizm pozwalający uzyskać podobną funkcjonalność)
  • Przeładowywanie (przeciążanie) operatorów:
    • tak: Ruby, C++, Python, C#
    • nie: Java (choć przeciążonych jest kilka operatorów wbudowanych, np. + w klasie String), Ocaml, Object Pascal (tak od BDS 2006)

Pochodzenie tekstu

Tekst pochodzi z polskiej Wikipedii i udostępnionu jest na licencji GFDL.

  • Co to GFDL? - artykuł na pl.wikipedia.org
  • GFDL - lokalna kopia treści licencji GFDL
  • GFDL - kopia licencji GFDL w witrynie gnu.org
Personal tools