15.1 Programowanie obiektowe... 1 15.2 Zasada otwartości-zamkniętości... 2 15.3 Zasada podstawiania liskowej... 5 15.4 Zasada odwrotnej zaleŝności... 6 15.5 Zasada rozdzielania interfejsów... 7 15.6 Trzy zasady spójności pakietów... 9 15.7 Zasady budowania relacji między pakietami... 10 15.8 Zasada ograniczania nadpisania interfejsów... 11 15.9 Zasada Demeter... 11 15.1 Programowanie obiektowe Programowanie obiektowe (ang. object-oriented programming) technika programowania w której program komputerowy jest tworzony jako zbiór typów (klasy) i instancji typów czyli obiektów. Powodem powstania języków obiektowych i obiektowych technik programowania była rosnąca wielkość programów, konieczność budowania duŝych, rozproszonych systemów komputerowych z róŝnych dziedzin Ŝycia. Obiektowe techniki programowania spowodowały powstanie obiektowych techniki analizy i modelowania rozproszonych systemów komputerowych i obiektowych baz danych, http://www.omg.org/ Obiekty są określone przez stan, czyli zdefiniowany i zainicjowane atrybuty obiektu, zachowanie, czyli metody które słuŝą do wykonywania operacji na atrybutach obiektu). Istotą programowania obiektowego jest łączenie róŝnych typów danych z operacjami na tych typach w jeden abstrakcyjny typ (klasę), moŝliwość definiowania relacji między abstrakcyjnym typami danych w celu umoŝliwienia polimorfizmu instancji abstrakcyjnych typów danych (obiektów), moŝliwość dynamicznej konwersji między abstrakcyjnym typami danych. Języki zorientowane obiektowo: Simula 67, pierwszy język zorientowany obiektowo, stworzony przez Ole-Johan Dahl i Kristen Nygaard w Norwegian Computing Center, http://www.edelweb.fr/simula/ Smalltalk, język stworzony przez Alana Kay a w Xerox Palo Alto Research Center. Java, język opracowny przez James a Gosling a w Sun Microsystems w 1991. The Java programming language is a general-purpose concurrent class-based object-oriented programming language, specifically designed to have as few implementation dependencies as possible. The Java Language Specification, Third Edition, http://java.sun.com/docs/books/jls/ C++, językiem zaprojektowany przez Bjarne'a Stroustrup a, jest obiektowym rozszerzeniem języka C. Standard for the C++ Programming Language, ISO/IEC 14882:1998. C#, językiem zbudowany w oparciu składnię języka C++. ECMA-334 3rd Edition / June 2005 C# LanguageSpecification: C# is intended to be a simple, modern, general-purpose, object-oriented programming language. 1
15.2 Zasada otwartości-zamkniętości Zasada otwartości-zamkniętości, (ang.) open-close principle. KaŜda część systemu (funkcja, klasa, moduł) powinna być tak modelowana, aby moŝna było łatwo ją funkcjonalnie rozszerzać (rozbudowywać) bez konieczności modyfikowania istniejącego kodu. (ang.) A module should be open for extension but closed for modification. Zasada OCP została sformułowana przez Bertrand'a Meyer'a w 1988, jest najwaŝniejszą zasadą zorientowanego obiektowo projektowania (object oriented design). Zasada OCP oznacza, Ŝe Dodanie nowej funkcjonalności do istniejącego pakietu (modułu) nie powinno wiązać się z przebudową pakietu a tylko z dopisaniem nowego komponentu. open - do modelowanego komponentu powinno łatwo dodawać się nowe elementy (metody, atrybuty). closed rozbudowa modelowanego komponentu nie powinna wymagać modyfikacji istniejącego kodu. Zasadę Open-Close realizuje się poprzez stosowanie elementów abstrakcyjnych języka, np. w języku C++ stosowanie klas abstrakcyjnych. 2
Przykład 1. Program niezgodny z zasadą otwartości-zamkniętości. #include <iostream> using namespace std ; enum TypFigury okrag, kwadrat class FiguraGeometryczna TypFigury typ; class Punkt class Okrag TypFigury typ; private: double promienokregu; Punkt srodekokregu; class Kwadrat TypFigury private: double Punkt typ; dlugoscbokukwadratu; gornylewywierzcholek; void RysujKwadrat(class Kwadrat*) cout << "RysujKwadrat()" << endl; void RysujOkrag(class Okrag*) cout << "RysujOkrag()" << endl; void RysujFigury(FiguraGeometryczna * list[], int n) int i; for (i=0; i<n; i++) class FiguraGeometryczna* s = list[i]; switch (s->typ) case kwadrat: RysujKwadrat((class Kwadrat*)s); break; case okrag: RysujOkrag((class Okrag*)s); break; 3
Program napisany zgodnie zasadą otwartości-zamkniętości. class FiguraGeometryczna // klasa abstrakyjna virtual void Rysuj() const = 0; // metoda czysto wirtualna class Kwadrat : public FiguraGeometryczna virtual void Rysuj() const cout << "Rysuj kwadrat "<< endl; class Okrag : public FiguraGeometryczna virtual void Rysuj() const cout << "Rysuj okrag "<< endl; void RysujFigureGeometryczna(Set<FiguraGeometryczna*>& list) for (Iterator<FiguraGeometryczna*>i(list); i; i++) (*i)->rysuj(); 4
15.3 Zasada podstawiania liskowej Zasada podstawiania liskowej, (ang.) the Liskov substitution principle. Klasy główne (klasa bazowa) powinna dać się zastąpić klasami dziedzicznymi (klasami pochodnymi). (ang.) Subclasses should be substitutable for their base classes. Zasada sformułowana w 1996 przez Barbarę Liskov w pracach dotyczących teorii abstrakcyjnych typów danych. Zasadę moŝna równieŝ sformułować następująco: funkcja której argumentem jest wskaźnik lub referencja do obiektu klasy bazowej powinna równieŝ akceptować obiekty z klas pochodnych. B. Meyer, Design by Contract, Technical Report TR-EI-12/CO, Interactive Software Engineering Inc., 1986. D. Mandrioli, B. Meyer, eds., Design by Contract, in Advances in Object-Oriented Software Engineering, Prentice Hall, 1991. Przykład. Obiekty typu B, (typ B jest typem pochodnym dla A) mogą zastępować obiekty typu A. #include<iostream> using namespace std; class A virtual void metoda( A & ra, int i) cout << "metoda() w A" << endl; ra.xa=i; private: int xa; class B :public A void metoda( B & rb, int i) cout << "metoda() w B" << endl; rb.xb=i; private: int xb; void main() A a; B b; a.metoda(b,10); b.a::metoda(a,100); 5
15.4 Zasada odwrotnej zaleŝności Zasada odwrotnej zaleŝności, (ang.) dependency inversion principle. Relacje między klasami naleŝy tak modelować aby zaleŝności były od elementów abstrakcyjnych, nie od elementów konkretnych. (ang.) Depend upon Abstractions. Do not depend upon concretions. Przy modelowaniu relacji między klasami klasy główne (bazowe) powinny być klasami abstrakcyjnymi lub interfejsami. NaleŜy unikać zaleŝności od konkretnych funkcji lub klas. Przykład. Zastowanie zasady odwrotnej zaleŝności. class A virtual void metoda() cout << "metoda() w A " << endl; class B : public A void metoda() cout << "metoda() w B " << endl; void main( ) B b; b.metoda(); A a; a.metoda(); Prawidłowo określona zaleŝność między klasami. class Abs virtual void metoda() const = 0; class A : public Abs void metoda() cout << "metoda() w A " << endl; class B : public Abs void metoda() cout << "metoda() w B " << endl; void main( ) B b; b.metoda(); A a; a.metoda(); 6
15.5 Zasada rozdzielania interfejsów Zasada rozdzielania interfejsów, (ang.) interface segregation principle. Lepiej mieć kilka interfejsów o konkretnej funkcjonalności niŝ jeden interfejs uniwersalny. (ang.) Many client specific interfaces are better than one general purpose interface. W języku C++ interejs jest klasą zawierającą tylko publiczne metody. Typową implementacją interfejsu jest deklaracja klasy abstrakcyjnej, która zawiera tylko publiczne, czysto wirtualne metody. Język C++/ CLI. Interejs jest klasą deklarowaną za pomocą modyfikatora interface. Klasa która dziedziczy od intefejsu (od klasy typu interface) musi implementować wszystkie elementy interfejsu. Elementy interfejsu są tylko deklaracjmi (są elementami wirtualnymi). Interfejsy mogą między sobą być w relacji dziedziczenia. Domyślny typ dostępu w interfejsie jest public, i nie moŝe być zmieniony. W jęzku UML interfejs definiowany jest jako nazwany zbiór operacji, charakteryzujący zachowanie się elementu modelowanego systemu (specyfikacja UML 2.0 ). Przykład. Deklaracja klasy typu interfejs w języku C++/ CLI. public interface class A #include "stdafx.h" #include <iostream> using namespace std; interface class IA void meoda1(int val); void meoda2(double val); ref class A: IA virtual void meoda1(int val) // błąd, brak implementacji meoda2() // virtual void meoda2(double val) void main() 7
Przykład. Zastosowanie zasady rozdzielania interfejsów. #include "stdafx.h" #include <iostream> using namespace std; interface class IOtworz void otworz(); void zamknij(); interface class IUruchom void uruchom(); void wylacz(); ref class Samochod: IOtworz, IUruchom virtual void otworz() virtual void zamknij() virtual void uruchom() virtual void wylacz() ref class Motocykl: IUruchom virtual void uruchom() virtual void wylacz() void main() 8
15.6 Trzy zasady spójności pakietów Trzy zasady spójności pakietów, (ang.) package cohesion principles. Zasada 1. Zasada wielokrotnego uŝycia w kolejnych wersjach systemu, (ang.) Release reuse equivalency principle. Klasy podlegające wielokrotnemu uŝyciu powinny być umieszczane w jednym pakiecie. (ang.) The granule of reuse is the granule of release. Jednym z kryteriów grupowania klas w pakiet jest ich wielokrotne uŝycie (reuse). Pakiet stanowi pewną zamkniętą cześć modelowanego systemu, dlatego jest równowaŝność między wielokrotnym uŝyciem kodu (wielokrotnym uŝyciem klas) a wielokrotnym uŝyciem pakietu (części systemu). Zasada 2. Powszechna zasada zamkniętości, (ang.) common closure principle. Modyfikacja klasy w pakiecie nie powinna powodować konieczności modyfikacji klasy w innym pakiecie. Zbiór klas w którym modyfikacja jednej klasy powoduje modyfikacje innej naleŝy grupować w jeden pakiet. (ang.) Classes that change together, belong together. Zasada 3. Zasada wielokrotnego uŝycia, (ang.) common reuse principle. Klasy które nie są razem wielokrotnie wykorzystywane nie powinny być w jednym pakiecie, (ang.) classes that aren't reused together should not be grouped together. 9
15.7 Zasady budowania relacji między pakietami Trzy zasady budowania relacji między pakietami, (ang.) package coupling principles. Zasada 1. Zasada acyklicznej zaleŝności, (ang.) acyclic dependencies principle. ZaleŜność między pakietami nie powinny tworzyć cykli. (ang.) The dependencies betwen packages must not form cycles. Zasada oznacza, Ŝe naleŝy budować programy złoŝone z niezaleŝnych pakietów, komponetów. Zmiana kodu w jednym pakietów nie powinna wymuszać zmian w innych pakietach. Zasada 2. Zasada stabilnej zaleŝności, (ang.) stable dependencies principle. Przy modelowaniu naleŝy wybierać najbardziej stabilne zaleŝności. (ang.) Depend in the direction of stability. Stabilność pakietu jest miarą prawdopodobieństwa, Ŝe pakiet będzie musiał być modyfikowany. Zasada oznacza, Ŝe zaleŝności między pakietami naleŝy modelować biorąc pod uwagę ich stabilność w relacji z innymi pakietami. Zasada 3. Zasada stabilności pakietów, (ang.) stable abstractions principle. Stabilne pakiety powinny być pakietami abstrakcyjnymi. (ang.) Stable packages should be abstract packages. 10
15.8 Zasada ograniczania nadpisania interfejsów Zasada ograniczania nadpisania interfejsów, (ang.) narrow inheritance interface. NaleŜy minimalizować liczbę metod abstrakcyjnych (czysto wirtualnych) dziedziczonych przez klasę pochodną. Zasada ograniczania interfejsów, (ang.) narrow inheritance interface - related heuristic NaleŜy ograniczać (minimalizować) liczbę interfejsów w klasie. (ang.) Minimize the public interface of a class. 15.9 Zasada Demeter Zasada Demeter dla metod: Metoda powinna wywoływać metody ze swojej klasy bezpośrednio. Metoda powinna wywoływać metody ze swojego obszaru bezpośrednio (nie z podobszaru). JeŜeli matoda wywoływana jest z parametrem, to moŝe zawierać wywoływania metod wykorzystujacych ten parametr. JeŜeli metoda tworzy lokalny obiekt, to moze zawierać wywołania metod tego obiektu. Metody nie powinny wywoływać obiektów globalnych, ale mogą je przekazywać jako parametry. 11