Zasady programowania
obiektowego
Prostota przede wszystkim
Zasady programowania
obiektowego
Prostota przede wszystkim
Zasady dla klas
Law of Demeter
• Demeter była boginią przyrody (Gleba-Matka), urodzajów, patronką
rolnictwa. Główny mit związany z Demeter opisuje jej poszukiwania zaginionej
córki (swojej i Zeusa) - Persefony (Kora - Dziewczyna). Bogini zostawiła ją na
łące, bawiącą się z nimfami (okeanidami). Odchodząc zabroniła jej zrywać
narcyzów - kwiatów związanych z bóstwami podziemnymi. Persefona nie
posłuchała matki. Z woli Zeusa wyrósł na łące wspaniały kwiat, w którym
z korzenia wyrastało sto łodyg o cudownym wyglądzie i zapachu. Gdy
dziewczyna odkryła kwiat zapomniała o przestrogach matki i zerwała go.
Otwarła się wówczas ziemia i Hades, bóg podziemi, porwał Persefonę
i zaczarowanym rydwanem wywiózł ją w dal. Lecieli ponad ziemią i morzem - do
Tartaru. Nikt nie słuchał krzyków Persefony. Dopiero po długim czasie dotarły
one do matki - Demeter.
• Zrozpaczona Demeter rozpoczęła poszukiwania. Przekazała swoją żałobę po
Persefonie polom. Zasiewy zmarniały, spiekota wysuszyła źródła i rzeki, padały
zwierzęta, a ludzi nawiedził głód. Nie było nawet z czego składać ofiar bogom.
Bogowie olimpijscy wystraszyli się, że jeżeli ludzie wyginą, to kto będzie składał
im ofiary. Zeus wysłał do Demeter muzy, charyty i kolejno innych olimpijczyków.
Ale nikomu nie udało się ubłagać bogini. W końcu Zeus wysłał Heraklesa do
Hadesa z żądaniem uwolnienia Persefony. Hades posłuchał rozkazu Zeusa, ale
rozstając się z Persefoną podał jej słodką pestkę granatu. Persefona zjadła ją,
nie wiedząc, że związała się tym na zawsze z podziemnym królestwem.
• Gdy Persefona wyszła z podziemi uradowana Demeter sprawiła, że wszystko na
ziemi rozkwitło. Z powodu zjedzonej pestki granatu Persefona odtąd trzecią
cześć roku musiała spędzać w królestwie Hadesa. Na ziemi panowała wtedy
zima - przerwa w wegetacji. Pozostałą część roku matka z córką spędzały
razem, obdarzając ziemię plonami.
Prawo Demeter
Law of Demeter
• Law of Demeter (LoD) (Don't Talk to
Strangers; or Principle of Least Knowledge)
• Treść: Niech obiekt rozmawia tylko z bliskimi
współpracownikami.
• Opis: Chodzi w niej o to, żeby obiekt nie
komunikował się (wywoływał metod, pobierał
wartości pól) z obiektów w dalekiej odległości w
grafie powiązań między obiektami. Oznacza to, że
obiekt powinien mieć minimalną wiedzę o innych
obiektach. Unika się dzięki temu „kruchych”
połączeń, co ogranicza wpływ miejscowych zmian
w projekcie na resztę projektu.
Law of Demeter – intuicja
Możesz się bawić:
• sam ze sobą,
• swoimi zabawkami (ale nie
wolno Ci rozbierać ich na części!),
• zabawkami, które dostaniesz od innych,
• zabawkami, które sam stworzysz, gdzie
zabawkami są po prostu obiekty, a
zabawa polega na wywoływaniu metod.
Law of Demeter -
formalizacja
public class Demeter { // Prawo Demeter dla klas
private A a;
private int func() { ... }
public void example (B b) {
// obiekt może wywołać tylko takie metody:
int k = func(); // <--------- tego samego obiektu
b.invert(); // <------------- parametru przesłanego do funkcji
a = new A();
a.setActive(); // <---------- obiektu stworzonego przez
Demeter
}
}
Law of Demeter -
naruszenie
class A {public: void m(); P p(); B b; };
class B {public: C c; };
class C {public: void foo(); };
class P {public: Q q(); };
class Q {public: void bar(); };
void A::m() {this.b.c.foo();
this.p().q().bar();}
Zmniejszenie powiązań
między obiektami. Przykład.
• Kiepskie rozwiązanie dla wyszukiwania
wina
• W= ListaWin.dajWina();
• /* Wyszukiwanie liniowe w liście win... */
• Odwołujemy sie do pola klasy ListaWin.
• Nadopiekuńczość – chcemy wykonać
pracę za kogoś innego, bo na przykład
uważamy, że lepiej to zrobimy.
Zmniejszenie powiązań
między obiektami. Przykład.
• Związane są z tym dwa potencjalne problemy:
• Klasa ListaWin może zawierać struktury
przyśpieszające wyszukiwanie win po nazwie,
w czasie logarytmicznym, dlatego liniowe
przeglądanie listy jest nieefektywne.
• Po pewnym czasie może się okazać, że
będziemy chcieli przechowywać listę win w
innej strukturze danych (np. w posortowanej
tablicy) i trzeba będzie przerabiać wszystkie
wyszukiwania win w programie.
Korzyści ze stosowania LoD
Dwie główne korzyści, które daje nam
stosowanie prawa Demeter to:
• Nie musimy znać struktury innych
obiektów.
• Wszelkie zmiany w innych obiektach
nie maja wpływu na naszą metodę.
Korzyści cd.
• Wnioski płynące ze stosowania prawa Demeter,
potwierdzone empirycznie podczas badań na
rzeczywistych programach wskazują, że ułatwia
ono pielęgnację, zmniejsza gęstość błędów, a
także ogranicza liczbę i rodzaj powiązań pomiędzy
obiektami, a co za tym idzie – wzmacnia
hermetyzację i abstrakcję klasy.
• Zastosowanie prawa Demeter na poziomie kodu
programu powoduje przeniesienie
odpowiedzialności za dostęp do metod i atrybutów
klasy z obiekt odwołującego się do nich do ich
właściciela.
LoD króciutko
• Rumbaugh podsumował zasadę Law
of Demeter w następujący sposób:
Metoda powinna mieć ograniczoną
wiedzę o modelu obiektów.
Cienie
• Konsekwentne stosowanie prawa
Demeter, może skutkować nadmierną
liczbą metod, których jedynym zadaniem
jest przedłużenie wywołania metody
• class Samochód{
• private Silnik silnik;
• public void uruchom() { silnik.uruchom;}
• }
A co z tym zrobić?
• System.Console.Writeln(„Hello World”);
• Żeby prawo Demeter nie rodziło takich
sprzeczności, zezwala na odwoływanie
sie do pól i metod obiektów globalnych
(w szczególności do różnych
przestrzeni nazw; w Javie pakietów).
Law of Demeter
Istnieją dwie postaci prawa Demeter:
silna i słaba.
W przypadku wersji słabej prawo to
jest rozszerzone także na podklasy
klasy analizowanej
Single-Responsibility
Principle
• Zasada ta jest silnie powiązana z zasadą
skupienia (high cohesion) ze wzorów GRASP
(General Responsibility Assignment Software
Patterns ). Chodzi o to, żeby klasa miała
tylko jedną odpowiedzialność (responsibility),
ponieważ odpowiedzialność jest
potencjalnym źródłem zmian. Jeżeli klasa ma
więcej niż jedną odpowiedzialność to zmiana
jednej z nich będzie wpływać na
implementację reszty.
Single-Responsibility
Principle
• Prostym przykładem złamania tej zasady
jest klasa, która jednocześnie zawiera logikę
(np. obliczanie powierzchni figury) oraz kod
związany z grafiką (np. odpowiedzialny za
rysowanie tej figury). Trochę lepszym
przykładem złamania zasady SRP jest klasa
zawierająca jednocześnie kod wybierający
dane z bazy oraz logikę odpowiedzialną za
obliczanie pozycji faktury (typowy i częsty
przykład pomieszania logiki biznesowej)
Single-Responsibility
Principle
• class Suma
{
private int wynik;
public void Dodaj(int a, int b)
{
wynik = a + b;
}
public void Wypisz()
{
Console.WriteLine(wynik);
}
}
Single-Responsibility
Principle
• interface IWyświetl
{
void Wyświetl(int wynik);
}
class Suma{
private int wynik;
public int Wynik
{
get
{
return wynik;
}
• }
public void Dodaj(int a, int
b)
{
wynik = a + b;
}
}
• class SumaUI : IWyświetl
{
public void Wyświetl(int
wynik)
{
Console.WriteLine(wynik);
}
}
//UI – User Interface
• class Program
{
static void Main(string[] args)
{
Suma s = new Suma();
s.Dodaj(2,2);
IWyświetl w = new
SumaUI();
w.Wyświetl(m.Wynik);
}
}
Open/close principle
• Treść: Elementy oprogramowania powinny być otwarte na
rozszerzenia, ale zamknięte na modyfikacje.
Opis: Podstawą dla tej zasady jest spostrzeżenie, że każdy kod (klasa,
moduł, itp.) zmienia się z czasem i ma więcej niż jedną wersję. Dobre
stosowanie tej zasady powoduje, że wprowadzenie rozszerzeń w jednej
klasie nie spowoduje całej kaskady zmian w innych klasach.
Trzeba zatem tworząc kod od razu mieć na uwadze możliwość
przyszłych rozszerzeń. Trzeba przewidzieć możliwość tworzenia
rozszerzeń i zmiany zachowania kodu, ale nie powinno się to odbywać
poprzez zmianę już istniejącego kodu.
Można powiedzieć, że OCP to główna zasada projektowania
obiektowego, która pozwala spełniać jego slogany reklamowe
(flexibility, reusability, maintainability).
Przykład: stosowanie się do tej zasady zazwyczaj oznacza bazowanie
na abstrakcji (klasy abstrakcyjne) i stosowanie polimorfizmu
(oczywiście nie tylko do tego). Dobrym przykładem złamania tej zasady
jest tworzenie logiki zawierającej instrukcje „switch..case”
rozróżniającej typy obiektów.
Open/close principle
class
Shape
{
private
Punkt _center;
#region
Center Get / Set
}
class
Circle : Shape
{
private
int
_radius;
#region
Radius Get / Set
}
class
Square : Shape
{
private
int
_side;
#region
Side Get / Set
}
Open/close principle
class
DrawManager
{
private
List
<
Shape
>
shapeList;
public
DrawManager(){…}
public
void
add(Shape s){…}
public
void
drawShapes(){->}
private
void
drawCirle(Circle c){..}
private
void
drawSquare(Square sq){..}
}
public
void
drawShapes()
{
foreach(Shape s
in
shapeList)
{
if
(s is Circle)
{
drawCirle((s as Circle));
}
else
if
(s is Square)
{
drawSquare((s as Square));
}
}
}
Open/close principle
abstract
class
Shape
{
private
Punkt _center;
public
abstract
void
Draw();
};
class
Circle : Shape
{
private
int
_radius;
public
override
void
Draw()
}
class
Square : Shape
{
private
int
_side;
public
override
void
Draw()
}
class
DrawManager
{
//......
public
void
drawShapes()
{
foreach (Shape s
in
_shapeList)
s.Draw();
}
//......
}
OCP - metody
• Podstawowymi mechanizmami
umożliwiającymi stosowanie zasady
OCP są abstrakcja i polimorfizm.
• W językach programowania ze
statyczną obsługą typów (C#) ważny
jest mechanizm dziedziczenia
(hierarchia).
OCP na koniec
• Stosowanie programowania
obiektowego, bezmyślne wykorzystanie
abstrakcji we wszelkich możliwych
miejscach to nie jest zasada OCP.
• Najlepszym wyjściem jest definiowanie
abstrakcji tylko w tych obszarach
programowania, co do których istnieje
przypuszczenie szczególnie częstych
zmian.
Problem testowy
• CA14
• Lsp+Ocp.doc
Liskov Substitution
Principle
• Treść: [W hierarchii dziedziczenia] podtypy muszą
być „podstawialne” za typy bazowe.
Opis: Zasada ta umożliwia wykrycie źle stworzonej
hierarchii dziedziczenia, w szczególności źle
zaimplementowaną klasę pochodną. Chodzi o to,
żeby wszystkie podtypy zachowywały się tak jak
zakłada się, że zachowuje się typ bazowy.
Zazwyczaj domyślnie się zakłada, że za typ bazowy
można podstawić klasę pochodną i zachowanie
będzie zmodyfikowane, ale będzie poprawne z
punktu widzenia „klientów” klasy bazowej.
Zasada ta jest nawet silniejsza niż podstawowa
zasada dziedziczenia „is-a” (jest).
Liskov Substitution
Principle
• Zasada Liskov Substitution Principle (LSP)
wprowadza wskazówki dotyczące projektowania
używając dziedziczenia. Została sformułaowana
przez Barbarę Liskov i w wolnym tłumaczeniu
brzmi następująco:
Jeżeli dla każdego obiektu o1 typu S istnieje
obiekt o2 typu T, taki że dla wszystkich
programów P zdefiniowanych używając T,
zachowanie P pozostaje niezmienne po zamianie
o1 na o2 to typ S jest podtypem typu T.
Przecież kwadrat jest (IS-A)
prostokątem
•
public
class
Rectangle
•
{
•
private
double
width;
•
private
double
height;
•
•
public virtual double
Width
•
{
•
get
{
return
width; }
•
set
{ width = value;}
•
}
•
•
public
virtual
double
Height
•
{
•
get
{
return
height; }
•
set
{ height = value;}
•
}
•
•
}
public class Square: Rectangle
{
public override double Width
{
set
{
base.Width = value;
base.Height = value;
}
}
public override double Height
{
set
{
base.Height = value;
base.Width = value;
}
}
}
public class RectangleTests
{
public void AreaOfRectangle()
{
Rectangle r = new Rectangle();//wstawmy Square
r.Width = 5;
r.Height = 2;
if (r.Area() != 10) throw new Exception("ZŁe pole");
}
}
Relacja IS-A
• LSP mówi, że ta relacja musi
zachowywać zachowania
• Zachowanie prostokąta: w czasie
zmiany jednego z boków, drugi nie
może być zmieniony
• Zachowanie kwadratu: gdy
zmieniamy jeden bok to drugi też
DBC
• Sposób projektowania
oprogramowania zaproponowany
przez Bertranda Meyera w latach 80
• Wspierany przez język Eiffel
• Idea:
• Kontrakt między klientem (miejsce
wywołania procedury) i dostawcą
(procedurą)
Projektowanie przez
kontrakt
• Warunki wstępne
• Warunki końcowe
• Przestrzeganie kontraktu - asercje
• Dla prostokąta i kwadratu
• WW - puste
• Width=w;
• WK : width==w &&
height==old.height
Proste i odcinki
public class Prosta
{
private Punkt p1;
private Punkt p2;
public Prosta(Punkt p1, Punkt p2)
{this.p1=p1; this.p2=p2;}
public Punkt P1 { get { return p1; } }
public Punkt P2 { get { return p2; } }
public double Slope { get {/* kod */} }
public double YIntercept { get {/* kod
*/} }
public virtual bool JestNa(Punkt p) {/*
kod */}
}
public class Odcinek : Prosta
{
public Odcinek(Punkt p1, Punkt
p2) : base(p1, p2) {}
public double Length() {
get {/* kod */} }
public override bool
JestNa(Punkt p) {/* kod */}
}
I co teraz – naruszenie LSP
• Przymknąć oko. W końcu czy musimy
używać klasy bazowej w miejsce
pochodnej?
• Ale to świadczy o niezbyt wysokiej
jakości naszego kodu. Trzeba
przemyśleć.
• Wyodrębnić (factor) !
To jest to
public abstract class ObiektLiniowy
{
private Punkt p1;
private Punkt p2;
public ObiektLiniowy(Punkt p1, Punkt p2)
{this.p1=p1; this.p2=p2;}
public Punkt P1 { get { return p1; } }
public Punkt P2 { get { return p2; } }
public double Slope { get {/* kod */} }
public double YIntercept { get {/* kod
*/} }
public virtual bool IsOn(Punkt p) {/* kod
*/}
}
public class Prosta : ObiektLiniowy
{
public Prosta(Punkt p1, Punkt p2) :
base(p1, p2) {}
public override bool IsOn(Punkt p) {/* kod
*/}
}
public class Odcinek : ObiektLiniowy
{
public Odcinek(Punkt p1, Punkt p2) :
base(p1, p2) {}
public double GetLength(){/* kod */}
public override bool IsOn(Punkt p) {/* kod
*/}
}
//Promień
Klasyczne naruszenie LSP
• class Bazowa
• {
public virtual void f() {/*jakiś kod*/}
• }
• class Pochodna
• {
• public override void f(){}
• }
OCP a LSP
• OCP jest jedną z podstawowych reguł
programowania obiektowego
• LSP jest jednym z warunków OCP
• Czynnikiem który naprawdę definiuje
podtyp, jest możliwość zastępowania
wynikająca z jawnego bądź
niejawnego kontraktu.
Dependency-Inversion
Principle
• Treść: Moduły wysokopoziomowe nie powinny zależeć
od modułów niskopoziomowych. Oba powinny zależeć
od abstrakcji. Abstrakcje nie powinny zależeć od
detali. Detale powinny zależeć od abstrakcji.
Opis: Główną ideą tej zasady jest wymuszenie, aby
moduły czy klasy nie zależały od bardziej
niskopoziomowych elementów, a raczej, aby
niskopoziomowe klasy czy moduły bazowały na
klasach abstrakcyjnych, czy wyższych modułach.
Dzięki temu niskopoziomowe zmiany nie będą miały
wpływu na wyższy poziom aplikacji. Zastosowanie tej
zasady najważniejsze jest przy podziale aplikacji na
warstwy, ale także powinno się ją stosować przy
projektowaniu klas.
Dependency-Inversion
Principle
• Tam gdzie to tylko możliwe bądź zależny
od abstrakcji a nie konkretów. Czyli jeśli
chcesz mieć w klasie pole typu lista, to nie
deklaruj LinkedList, ArrayList ani nic
takiego, tylko po prostu List. To ułatwi ci
refaktoryzację jeśli okaże się, że trzeba
skorzystać z innej implementacji.
• Typowym naruszeniem DIP jest pobieranie
z formy danych (grid) i obliczanie np. sumy
w tej samej funkcji
Dependency-Inversion
Principle
•
class B
{
public void ZrobCos() { }
}
class A
{
public void Metoda()
{
B b = new B();
b.ZrobCos();
}
}
Jakakolwiek zmiana w klasie B może mieć wpływ na zachowanie klasy A. Poza tym, klasa A może tylko sterować
zachowaniem B. Jak to zmienić?
interface IB
{
void ZrobCos() { }
}
class B : IB
{
public void ZrobCos() { }
}
class A
{
public void Metoda()
{
IB b = new B();
b.ZrobCos();
}
}
Co osiągnęliśmy?
-klasa A może sterować dowolnymi klasami implementującymi interface IB
Dependency-Inversion
Principle
Interface Segregation
Principle
• Treść: klient nie powinien być zmuszony do
zależności od metod, których nie używa.
Opis: jest to chyba najrzadziej łamana zasada
ze wszystkich dotychczas przedstawionych.
Postuluje ona, aby interfejsy były jak
najbardziej skupione na jednym celu, a tym
samym nie były „przeładowane” metodami.
Jeżeli klasa implementuje interfejs, który ma
bardzo wiele metod to możliwe jest, że nie
wszystkie będzie wykorzystywać, a co gorsze
będzie musiała, co spowoduje złamanie SRP.
Interface Segregation
Principle -naruszenie
• Najprostszym złamaniem ISP byłoby
umieszczenie w jednym interfejsie metod
służących do operacji graficznych (np.:
Draw(), Rotate()) oraz odpowiedzialnych za
trwałość (np.: Save(), Load()).
• Każdorazowo, gdy implementujemy
metodę interfejsu (bo musimy) i
zostawiamy ją pustą to oznacza
nadmiernie rozbudowany interfejs.
• Interface pollution
