Metody obiektowe 

Nietrudno zauważyć, iż powstanie metod obiektowych jest dobrze wplecione w ogólne trendy w inżynierii oprogramowania, które zmierzają do:

Pierwsze dwa postulaty dotyczą etapów projektowania i analizy, jako że istotne jest to, aby byty świata rzeczywistego odpowiadały bytom istniejącym na etapie projektu, czyli aby analityk lub projektant mógł myśleć w kategoriach owych bytów. Dążenie do zmniejszenia izolowanych jednostek projektowych bierze swój początek w językach zapewniających silne mechanizmy do modularyzacji systemu (np. ADA) i nie jest charakterystyczne dla metodologii obiektowych. Szerszego omówienia wymaga spójność odwzorowania obiektów świata rzeczywistego w byty programowe. W metodologii strukturalnej rozdziela się rzeczywistość na dane, oraz procesy operujące na tych danych. Jest to jednak podejście nienaturalne. W programie strukturalnym nie ma tak naprawę pracownika – są dane, które go opisują i procedury, które mogą te dane modyfikować. W metodologiach obiektowych dąży się do całościowego modelowania bytów świata rzeczywistego, bez rozdzielenia systemu na dane i procesy. Izolacja coraz to mniejszych bytów programowych odpowiada wydzielaniu bytów programowych na etapie projektowania. Istotne jest to, aby składowe oprogramowania mogły być projektowane, implementowane oraz testowane oddzielnie. Istotne jest również bezpośrednie powiązanie jednostki projektowej z programową, o czym jest, choć w innym kontekście, mowa w [5]. Oddzielenie wymagań od sposobu ich realizacji, wynikające z zasady oddzielania pojęć [9], jest silnie wspierane przez metodologie obiektowe. Zapewniają one oddzielenie definicji sposobu używania jednostki programowej od realizacji wymagań oraz możliwość zmiany sposobu tej realizacji.

Na etapie implementacji bardziej istotne wydają się własności powiązane z konkretnym językiem oprogramowania, jego semantyką, bibliotekami programistycznymi. Ważna jest możliwość powtórnego wykorzystania kodu i tworzenia abstrakcyjnych typów danych. Możliwości te ściśle zależą od języka implementacji i są mniej ważne, za wyjątkiem, możliwości powtórnego wykorzystania kodu dla samego paradygmatu obiektowego. Osoby intensywnie używające języka C++ mogą się w tym miejscu oburzyć, – ale trzeba pamiętać, że np. w typowo obiektowym języku Smalltalk nie ma w ogóle pojęcia typu. Język ten mniej znany w Polsce używany jest do implementacji dużych systemów.

Omawiając właściwości paradygmatu obiektowego należy zachować dużą ostrożność, aby nie zbliżyć się za bardzo do jakiejś konkretnej metodologii czy języka. Zdaniem autora mówiąc o technologii obiektowej należy pozostać na poziomie abstrakcji powyższego opisu, którego kluczowymi punktami są: wydzielenie małych bytów projektowych i odpowiadających im bytów programowych, holistyczne pojmowanie informatyzowanej rzeczywistości bez rozdzielenia na dane i procesy. W językach o ścisłej typizacji istotne jest tworzenie typów danych, które są używane tak samo jak typy wbudowane, w tym abstrakcyjnych typów danych.

Nasze usługi