Przykład (ten sam co w stylu NOOP) w OOP
#include <iostream.h> class Student { public : void SetName(char * tName); void SetSex(char tSex); void SetGrade(int tGrade); char * GetName(); char GetSex(); int GetGrade(); private : char * name; char sex; int grade; }; //koniec klasy Student void Student::SetName(char * tName) { name = tName; }; //koniec Student::SetName void Student::SetSex(char tSex) { sex = tSex; } //koniec Student::SetSex void Student::SetGrade(int tGrade) { grade = tGrade; } //koniec Student::SetGrade char * Student::GetName() { return name; } char Student::GetSex() { return sex; } int Student::GetGrade() { return grade; } int main() { Student * StudentList[20]; char tName[35]; char tSex; int tGrade; for (int i=0; i<20; i++) { StudentList[i] = new Student(); cin >> tName; StudentList[i]->SetName(tName); cin >> tSex; StudentList[i]->SetSex(tSex); cin >> tGrade; StudentList[i]->SetGrade(tGrade); } //wpisz studentów //..zrób coś ze studentami.. for (int i=0; i<20; i++) { delete StudentList[i]; } //kasuje obiekty return 0; } //koniec MainZauważysz, że w powyższym kodzie deklaracja klasy zawiera sekcje public i private. Informacja w sekcji public jest widziana na zewnątrz, natomiast sekcja private ukrywa informację, jest ona widziana tylko przez kod obiektu. W tym przykładzie dane są enkapsulowane i zabezpieczone przed modyfikacją lub nawet przeglądaniem z zewnątrz obiektu, podczas gdy metody zapisujące i odczytujące dane są dostępne dla całego programu. To czyni ten prosty przykład znacznie większym, ale sprawia, że użycie obiektu jest łatwiejsze, bo wszystko co trzeba wiedzieć o obiekcie zawarte jest w sekcji public. Programista, który widzi pierwszy raz ten obiekt nie musi wiedzieć nic o prywatnych członkach klasy, albo o kodzie obsługującym prywatne składniki. Zauważ, że kod znajduje się poza deklaracją klasy. Normalnie będziesz umieszczał kod metod w pliku .CPP, a deklarację klasy w pliku .H, albo w .CPP (jeżeli klasa jest prywatna). To pozwoli programiście używać klasy bez znajomości jej kodu. W mniejszych programach taka warstwowa budowa może nie być przydatna, ale w wielkich projektach przyspiesza znacznie produkcję i umożliwia ponowne wykorzystywanie kodu. W powyższym przykładzie Student jest klasą podstawową, nie dziedziczy właściwości z istniejącej klasy. Teraz stwórzmy następnego członka i zobaczmy jak wygląda ponowne wykorzystanie kodu. Poniższy przykład jest deklaracją klasy i implementacją obiektu Business Major: class BusinessMajor: public Student { public : void SetMinorCode(int tMinor); int GetMinorCode(); private : int minorCode; } //Koniec klasy BusinessMajorW przykładzie tym nowa klasa dziedziczy wszystko z klasy Student i dodaje dwie metody oraz prywatną daną. Wywołanie BusinessMajor->GetName użyje metody z klasy Student. Programista może dodać nową funkcję do każdej istniejącej klasy i nie musi się wcale martwić o oryginalną implementację. W powyższym przykładzie mogliśmy stworzyć nową metodę GetGrade i zmienić sposób w jaki klasa ją obsługuje poprzez dodanie tej funkcji do sekcji public. Jeżeli dokonałbyś konwersji tej nowej klasy do klasy Student, to i tak będzie użyta nowa metoda. Żeby zobaczyć prawdziwe korzyści tego przykładu, pomyśl, jak zaimplementowałbyś ten sam scenariusz w programowaniu liniowym. Musiałbyś utworzyć kilka struktur z różnymi danymi, albo jedną strukturę ze wszystkimi danymi i wykorzystywać tylko niektóre, konieczne dla danego kierunku. Pierwszy sposób doprowadziłby do zwiększenia ilości kodu, drugi zwiększyłby wykorzystanie zasobów systemowych. Czy programowanie liniowe umarło? Ależ nie! Bez podstaw programowania liniowego nie będziesz umiał programować w OOP. Cała logika programowania metod jest podobna do programowania liniowego. Główną różnicą jest to, że w OOP istnieje ścisły związek między danymi a kodem. Wady OOP Nic nie jest doskonałe... Chociaż w dobrym projekcie OOP ilość kodu i czas wykonania będą zmniejszone, to będzie miał on kilka wad. Kod OOP zajmuje zwykle więcej pamięci i wykonuje się wolniej, w zależności od implementacji. Wirtualne metody są interpretowane, a nie kompilowane, ponieważ logika wybierana jest w czasie pracy programu. Wymaga również dokładnej dokumentacji, ponieważ ewentualne błędy mogą być trudne do wykrycia. Może być również trudno zlokalizować deklarację klas. Te typowe problemy będą nieco inne w zależności od użytego języka i kompilatora. Kluczem do udanego projektu jest dobra dokumentacja i optymalizacja kodu. Jest jeszcze jedna wada. Czas potrzebny na opanowanie w dobrym stopniu OOP to około 2 - 3 lata. Oczywiście może on być inny, w zależności od umiejętności programisty. Jednakże OOP nie można się nauczyć czytając podręcznik, konieczna jest ciągła praktyka. Prędzej czy później zaczniesz jednak myśleć "obiektywnie".
|