Testy jednostkowe (ang. Unit tests)
Cel:
Weryfikacja oczekiwanego zachowania z faktycznym
Obiekt testowany:
wyizolowana instancja klasy, która podlega testom
Przypadek testowy:
weryfikacja jednego zachowania jednej metody
Klasa testująca: klasa z przypadkami testowymi
dotyczącymi jednego obiektu testowanego
Technologie obiektowe
Testy jednostkowe
Technologie obiektowe
Testy jednostkowe
" Niezależność oraz izolacja
" Nie można pisać testów badających kilka funkcji naraz.
" Jeżeli wywołanie jednej metody pociąga za sobą wykonanie innych
funkcji (np. metoda A wywołuje metodę B itp.), należy wykorzystać
tzw. makiety obiektów.
" Makiety obiektu naśladują zachowanie metod, zwracając z góry
zdefiniowane wyniki.
" Za pomocą frameworku NMock łatwo zdefiniować, co poszczególne
metody powinny zwracać.
" Dzięki takiej izolacji w przypadku wystąpienia błędu wiemy
dokładnie, w którym miejscu szukać przyczyny błędu  obszar
poszukiwań znacząco się pomniejszył.
Technologie obiektowe
Testy jednostkowe
" Ponadto testy jednostkowe powinny być niezależne od zewnętrznych
zasobów (usługa sieciowa czy zdalna baza danych). Pozwoli to na łatwe
uruchamianie testów na różnych komputerach  bez konieczności
skomplikowanej konfiguracji.
" Przejrzystość  testy jednostkowe powinny zostać napisane z wielką
starannością, ponieważ mogą posłużyć jako dokumentacja. Ze względu na
ich specyfikę programista, czytając kod testu jednostkowego, może łatwo
zrozumieć, jak korzystać z danej klasy oraz jak dobierać parametry
wejściowe.
" Szybkość  wykonanie poszczególnych testów nie powinno przekraczać 5
10 sekund (jeśli nie złamano zasady atomowości). Często wykonuje się
automatycznie szereg testów jednostkowych i naturalne jest, aby zostały
one zakończone w jak najkrótszym czasie.
Technologie obiektowe
Co należy testować w pierwszej kolejności?
" Dogłębnie cały system  wszystkie metody wraz ze wszystkimi przypadkami
użycia. W rzeczywistości nie zawsze jest to możliwe.
" Publiczne metody - stanowią interfejs dostępowy do całego systemu.
Podczas powstawania nowych wersji bibliotek rzadko zmieniają sygnaturę
(zachowanie kompatybilności wstecz). Pisanie testów metod publicznych
jest bardzo proste i sprowadza się do standardowego wywoływania
badanych funkcji. Wadą podejścia jest niezgodność z podstawą zasadą
atomowości  metody publiczne często pełnią rolę funkcji opakowujących
(ang. wrappers).
" Metody chronione - wykonują bardziej atomowe operacje. Niestety, ich
przetestowanie jest trudniejsze, ponieważ nie można w bezpośredni sposób
wywołać metody chronionej ze sterownika testu. Rozwiązaniem
jest stworzenie klasy opakowującej dziedziczącej po badanej klasie.
Technologie obiektowe
Testowanie metod chronionych
11-12-4
Technologie obiektowe
Przykład
class Account
{
private double balance=0;
public void wplata(double value)
{
balance = balance + value;
}
public void wyplata(double value)
{
balance = balance - value;
}
public double stan_konta()
{
return balance;
}
}
11-12-4
Technologie obiektowe
Przykład
11-12-4
Technologie obiektowe
Przykład
11-12-4
Technologie obiektowe
Przykład
[TestMethod()]
public void wplataTest()
{
Account target = new Account(); // TODO: Initialize to an appropriate value
double value = 0F; // TODO: Initialize to an appropriate value
target.wplata(value);
Assert.Inconclusive("A method that does not return a value cannot be verified.");
}
[TestMethod()]
public void wplataTest()
{
Account target = new Account(); // TODO: Initialize to an appropriate value
double value = 0F; // TODO: Initialize to an appropriate value
target.wplata(value);
double actual=target.stan_konta();
double expected=value;
Assert.AreEqual(expected, actual); ;
}
11-12-4
Technologie obiektowe
Przykład
11-12-4
Technologie obiektowe
Asercje
" Asercja  w logice i w analizie filozoficznej języka, uznanie jakiegoś zdania za
prawdziwe.
" W programowaniu asercja (ang. assertion) to predykat (forma zdaniowa w
danym języku, która zwraca prawdę lub fałsz), umieszczony w pewnym
miejscu w kodzie. Asercja wskazuje, że programista zakłada, że predykat ów
jest w danym miejscu prawdziwy. W przypadku gdy predykat jest fałszywy
(czyli nie spełnione są warunki postawione przez programistę) asercja
powoduje przerwanie wykonania programu. Asercja ma szczególne
zastosowanie w trakcie testowania tworzonego oprogramowania, np. dla
sprawdzenia luk lub jego odporności na błędy.
" Za: wikipedia
11-12-4
Technologie obiektowe
Asercje
Metoda Opis
AreEqual Sprawdza, czy wartości są równe.
AreNotEqual Sprawdza, czy wartości są różne.
AreNotSame Sprawdza, czy przekazane wartości nie odnoszą się do tego samego obiektu. W przeciwieństwie
do AreEqual, metoda bada referencje, a nie konkretne wartości.
AreSame Sprawdza czy przekazane wartości odnoszą się do tego samego obiektu. W przeciwieństwie do
AreEqual, metoda bada referencje, a nie konkretne wartości.
Fail Wywołanie powoduje, że test jednostkowy jest niezaliczony.
Inconclusive Powoduje, że wykonanie testu jest nierozstrzygnięte.
IsFalse Sprawdza, czy dostarczona wartość lub wyrażenie są fałszywe
IsInstanceOfType Sprawdza, czy dostarczona wartość jest podanego typu.
IsNotInstanceOfType Sprawdza, czy dostarczona wartość nie jest podanego typu.
IsNotNull Sprawdza, czy dostarczona wartość nie jest NULL.
IsNull Sprawdza, czy dostarczona wartość jest NULL.
IsTrue Sprawdza, czy dostarczona wartość lub wyrażenie jest prawdziwe.
11-12-4
Technologie obiektowe
TDD
Test Driven Development, czyli TDD, to technika tworzenia
oprogramowania sterowana przez testy. Tworzenie kodu
składa się z wielokrotnie wykonywanych trzech głównych
kroków:
1. Stworzenie testu jednostkowego,
" możliwie najprostszy, aby uniknąć możliwości popełnienia błędu w samym teście.
" test ma sprawdzać funkcjonalność, która będzie implementowana w kroku 2.
2. Implementacja funkcjonalności  tworzymy funkcjonalność
" funkcjonalność ta powinna spełniać założenia testu jednostkowego
" wykonanie testu jednostkowego powinno kończyć się sukcesem.
3. Refaktoryzacja, czyli porządki w stworzonej funkcjonalności.
" uporządkowanie kodu, tak aby spełnione były standardy.
" Czynności wykonywane w tym kroku nie mogą zmienić wyniku testów.
11-12-4
Technologie obiektowe
TDD krok 1.
" Przygotowanie takiego testu, który będzie testował
funkcjonalność, którą będziemy dopiero tworzyć.
" Przemyślenie interfejsu tej funkcjonalności oraz
pozwala skupić się nad tym, czego tak naprawdę
oczekujemy od implementowanej póz
niej
funkcjonalności.
" Czas poświęcony na tworzenie testu skutecznie
zmusza programistę do sprecyzowania problemu, z
jakim ma się zmierzyć.
11-12-4
Technologie obiektowe
TDD krok 2.
" Implementacja funkcjonalności. Dopiero mając test,
przechodzimy do implementacji funkcjonalności.
" Co ważne, wprowadzane zmiany nie mogą naruszać
innych testów, dzięki czemu mamy pewność, że nowo
tworzona funkcjonalność nie zaburza tej już
istniejącej.
11-12-4
Technologie obiektowe
TDD 3.
" Trzeci krok to refaktoryzacja, czyli uporządkowanie kodu,
doprowadzenie go do stanu zgodnego ze standardami dobrego
kodowania.
" Zmiany wprowadzane podczas refaktoryzacji nie mogą
powodować błędów w wykonaniu zarówno testu
jednostkowego z pierwszego kroku, jak i tych, które powstały
wcześniej.
" Jest to pierwszy etap, na którym testy jednostkowe zaczynają
pokazywać swoją potęgę  jeżeli jakakolwiek zmiana
wprowadzona w kodzie powoduje, że jeden lub więcej testów
przestaje działać, to wprowadzona zmiana
najprawdopodobniej generuje błąd.
11-12-4
Technologie obiektowe
Wady TDD
Wady Test Driven Development
Metodologia TDD posiada jednak dwie główne
wady :
" wymaga dodatkowego czasu na stworzenie
testów jednostkowych oraz
" wymaga czasu w na utrzymanie testów.
11-12-4
Technologie obiektowe
Wady
" Pierwsza wada może być bardzo zniechęcająca dla
kierownictwa, szczególnie w początkowym okresie korzystania
z TDD, kiedy deweloper potrzebuje czasem nawet do 30%
więcej czasu na wykonanie tych samych zadań. Z czasem
jednak, po nabraniu płynności w pisaniu testów, ten
dodatkowy czas zmniejsza się, dzięki czemu koszt stosowania
tej metodologii maleje.
" Druga wada wynika z faktu, że aby testy były użyteczne, muszą
być odpowiednio zarządzane i uaktualniane wraz ze zmianami
logiki aplikacji. Dopóki dodajemy nową funkcjonalność,
problem ten praktycznie nie istnieje, jednak przy
wprowadzaniu zmian w istniejącej funkcjonalności należy
pamiętać, że potrzebny jest czas na odpowiednie
zmodyfikowanie istniejących testów jednostkowych.
Technologie obiektowe
TDD - zalety
" Podstawową zaletą TDD jest szybkie wychwytywanie błędów.
Już w momencie tworzenia oprogramowania wiele błędów
można wychwycić za pomocą tej metodologii.
" Nie jest to bez znaczenia, ponieważ każdy błąd z czasem
 nabiera wartości  im póz
niej błąd zostanie wykryty, tym
więcej osób angażuje i tym więcej kosztuje zarówno w aspekcie
czasu, jak i pieniędzy.
" Dlatego chcemy, aby wszystkie błędy były wychwytywane
możliwie najszybciej i jak najbliżej programisty.
" Wystarczy sobie uzmysłowić, ile czasu potrzebujemy, aby
poprawić błąd, który zrobiliśmy 5 minut wcześniej, a ile czasu
potrzebujemy na poprawienie błędu sprzed 30 dni.
11-12-4
Technologie obiektowe
TDD - zalety
" Błędy wykryte przez autora kodu i poprawiane na bieżąco
kosztują niewiele, ponieważ angażują tylko jedną osobę. Błędy
wykryte przez zespół QA angażuje już czas zarówno
programisty, jak i testera (lub testerów), co znacząco
podwyższa koszty. A jak takie koszty wyglądają, gdy błąd dotrze
do klienta?
" Kolejną zaletą TDD jest bardziej przemyślany kod. Ponieważ w
pierwszym kroku tworzony jest kod, który będzie
wykorzystywał tworzoną funkcjonalność (test), to zazwyczaj
naturalnie ten kod jest bardzo prosty i elegancki. Tak stworzony
test wymaga, aby tworzona klasa była schludna i prosta do
wykorzystania. Jest to efekt, który bardzo łatwo się osiąga 
bez dodatkowego nakładu pracy  a przy okazji bardzo cenny
szczególnie dla początkujących programistów.
Technologie obiektowe
TDD - zalety
" Największą chyba zaletą tej metodologii pracy jest możliwość
przetestowania funkcjonalności bez uruchamiania całego
oprogramowania  tworzony kod można uruchamiać
częściowo, bez uruchamiania całej aplikacji.
" Nie ma to szczególnego znaczenia w małych projektach, ale już
przy średnich i dużych czas jest niezwykle istotny.
" Za pomocą kilku kliknięć myszy, nie wychodząc z ulubionego
środowiska programistycznego, można uruchomić części
aplikacji i otrzymać miarodajne wyniki  bez żmudnego
uruchamiania kodu, bez męczącego  przeklikiwania aplikacji i
bez tracenia czasu na ponowne koncentrowanie się na
istotnym problemie.
" Test jednostkowy pozwala w ciągu kilku sekund odpowiedzieć
na pytanie, czy dany kawałek kodu będzie działał tak, jak chciał
tego programista.
Technologie obiektowe
TDD - zalety
" Ostatnia, choć nie jedyna, bardzo ciekawa zaleta TDD to
tworzenie swoistej dokumentacji. Ile razy zdarzyło się, że nie
wiadomo, jak skorzystać z biblioteki rozwijanej przez kolegów i
koleżanki? Wiadome jest, że programiści lubią i piszą najlepsze
dokumentacje, więc& .. wystarczy sięgnąć do testów
jednostkowych i poszukać takiego testu, który pokaże nam jak
użyć owej biblioteki.
11-12-4
Technologie obiektowe
Kiedy stosować TDD?
Kiedy stosować TDD?
" Chciałoby się powiedzieć  zawsze. Praktyka jednak pokazuje, że nie ma
sensu korzystać z TDD w przypadku krótkich, kilkulinijkowych projektów. W
takiej sytuacji nadmiarowość czasu jest po prostu zbyt duża. Nie ma również
większego sensu korzystanie z tej metodologii w przypadku aplikacji (dalej,
kilkulinijkowych), które nigdy nie będą rozwijane.
" Powyższe ma zastosowanie praktycznie w małych, próbnych
aplikacjach/szkieletach. W codziennej pracy okazuje się, że praktycznie
każdy projekt warto rozwijać za pomocą TDD.
" Rozwijać  ponieważ generalną zasadą TDD jest pisanie testów
jednostkowych przed tworzeniem właściwego kodu. Jak pokazuje praktyka,
nie ma większego sensu tworzenie testów jednostkowych do istniejącego
kodu (jakość takich testów zazwyczaj jest bardzo niska), zatem pozostaje w
istniejących projektach tworzenie testów jednostkowych do nowej
funkcjonalności oraz korzystanie z pełni dobrodziejstw Test Driven
Development w nowych projektach.
11-12-4
Technologie obiektowe
Symptomy złego projektu
Sztywność
- brak elastyczności
- uniemożliwia wprowadzenie do systemu nawet najdrobniejszych
zmian
- projekt można uznać za sztywny, jeśli pojedyncza zmiana
powoduje całą serię następujących po sobie zmian w modułach
zależnych
-  Zadanie okazało się bardziej skomplikowane niż sądzilismy
Technologie obiektowe
Wstęp do modelowania obiektowego
- Jeśli mamy szczęście już na początku prac nad
projektem dysponujemy pełną wiedzą nt.
Kształtu przyszłego systemu.
- Reakcja łańcuchowa
- Wprowadzenie nawet najmniejszej zmiany,
wymagają bardzo dużych nakładów pracy
Technologie obiektowe
Symptomy złego projektu
Wrażliwość
- tendencja do ulegania uszkodzeniom lub usterkom w wielu
różnych miejscach wskutek wprowadzenia nawet
najdrobniejszych zmian
- często pojawiają się w obszarach na pozór nie związanych ze
zmienianym fragmentem
Programiści wiedzą że takie moduły wymagają przeprojektowania,
ale nikt nie chce podjąć się tego trudnego zadania.
Technologie obiektowe
Symptomy złego projektu
Nieelastyczność
- System jest nieelastyczny, jeśli zawiera elementy, które  choć
teoretycznie mogłyby zostać wykorzystane w innych systemach
 nie mogą być oderwane od oryginalnego systemu
Niedostosowanie do rzeczywistości
- niedostosowanie oprogramowania
- niedostosowanie środowiska (niefektywne)
Technologie obiektowe
Symptomy złego projektu
Nadmierna złożoność
- system zawiera elementy, które w danej chwili są zbędne
- programiści, próbują przedwcześnie przewidywać potencjalne
zmiany wymagań
Niepotrzebne powtórzenia
- copy & paste
Nieprzejrzystość
- kod jest niezrozumiały, trudny do odczytania
- Kod który ewoluuje, zwykle staje się nieprzejrzysty
-
Technologie obiektowe
Program Copy
Poniedziałek rano.
Technologie obiektowe
Burza mózgów
Technologie obiektowe
Rozwiązanie
Copy
KeyboardReader PrinterWriter
Technologie obiektowe
Kod
public class Copier
{
public static void Copy()
{
int c;
while ((c = Keyboard.Read()) != -1)
Printer.Write(c);
}
}
Technologie obiektowe
Technologie obiektowe
3 miesiące póz
niej
Technologie obiektowe
Nowy wspaniały kod
public class Copier
{
// musimy pamiętać o konieczności przywrócenia wartości tej flagi
public static bool ptFlag = false;
public static void Copy()
{
int c;
while ((c = (ptFlag ? PaperType.Rrad() : Keyboard.Read()) != -1)
Printer.Write(c);
}
}
Technologie obiektowe
Technologie obiektowe
Killka tygodni póz
niej
MAMY JUŻ DOŚĆ KLIENTÓW!!
ONI ZAWSZE RUJNUJ
NASZE PROJEKTY
GDYBY NIE ONI TWORZENIE OPROGRAMOWANIA
BYA
OBY NIEPORÓWNYWALNIE A
ATWIEJSZE
Technologie obiektowe
I znowu wspaniały kod
public class Copier
{
//musimy pamiętać o modyfikacji flag
public static bool ptFlag = false;
public static bool punchFlag = false;
public static void Copy()
{
int c;
while ((c = (ptFlag ? PaperType.Read() : Keyboard.Read()) != -1)
punchFlag ? PaperTape.Punch(c) : Printer.Write(c);
}
}
Technologie obiektowe
`
Technologie obiektowe
Wnioski
Żyjemy w świecie zmieniających się wymagań
Naszym zadaniem jest tworzenie
oprogramowania, które będzie potrafiła te
zmiany przetrwać!!!
Technologie obiektowe
Zasada pojedynczej odpowiedzialności
Single-Responsibilty Principle  SRP
Żadna klasa nie może być zmodyfikowana z więcej niż jednego
powodu.
Każdy obszar odpowiedzialności jest faktyczną osią zmian
Kiedy wymagania ulegają zmianie, zakres niezbędnych modyfikacji
jest określany na podstawie obszarów odpowiedzialnści
przypisanych do poszczególnych klas
Jeżeli pojedyncza klasa odpowiada za więcej niż jeden obszar
jednocześnie, może istnieć więcej niż jeden powód jej
modyfikowania
Technologie obiektowe
SRP
Jeżeli jakaś klasa odpowiada za więcej niż jeden obszar te
rozłączne obszary są ze sobą złączone
Zmiany jednego obszaru odpowiedzialności mogą nadwątlać
lub hamować funkcjonowanie w innym obszarze.
Ograniczenie elastyczności projektów.
Technologie obiektowe
Znowu figury
Rectangle
Computational
Geometry
Graphical
+draw()
Application
Application
+area():double
GUI
Klasa Rectangle wykorzystywana jest przez dwie różne aplikacje (CGA i GA)
Jedna odpowiada za obliczenia, druga za rysowanie.
Technologie obiektowe
SRP a figury
Klasa Rectangle narusza zasadę pojedynczej
odpowiedzialności.
Klasa Rectangle odpowiada za dwa obszary
Pierwszy  polega na zapewnieniu modelu
matematycznego dla reprentowanej figury
Drugi  wizualizacja prostokąta za
pośrednictwem GUI
Technologie obiektowe
Naruszene SRP - konsekwencje
- musimy uwzględnić moduł GUI w aplikacji zajmującej się
wyłącznie obliczeniami (kompilacja pełnego projektu razem z
obłsugą GUI)
- jeżeli z jakiegoś powodu aplikacja GraphicalApplication z
jakiegoś powodu wymusi modyfikację klasy Rectangle,
ponownie będziemy musilei skompilować, przetstować i
wdrożyć aplikację ComputationalGeometryApplication
Technologie obiektowe
Rozwiązanie
Podzielenie obu obszarów odpowiedzialności pomiędzy dwie całkowite
rozłączne klasy.
Elementy obliczeniowe GeometricRectangle
Sposoby wizualizacji nie mają żadnego wpływu na obliczenia
Computational
Geometry
Graphical
Application
Application
Geometric
Rectangle
Rectangle
+draw()
+area():double
GUI
Technologie obiektowe
Odpowiedzialność
Odpowiedzialność jako przyczna zmiany.
Jeśli jesteśmy w stanie wyobrazić sobie więcej niż jeden bodziec
skłaniający programistę do zmiany tej klasy, mamy do czynienia z
więcej niż jednym obszarem odpowiedzialności
public interface Modem
{
public void dial(string pno);
public void hangup();
public void send(char c);
public char recv();
}
Technologie obiektowe
Odpowiedzialności
Dial i hangup  odpowiadają za zarządzanie połączeniem
Send i recv  służą do przesyłania danych
Czy należy te dwie odpowiedzialności rozdzielić?
1) TAK
2) NIE
O osi zmian możemy mówić wtedy i tylko wtedy, gdy odpowiednie
zmiany mają miejsce.
Technologie obiektowe
Rozwiązanie
<>
<>
DataChannel
Connection
+send
+dial
+recv
+hangup
ModelImplementation
Technologie obiektowe
Trwałość
Employee
+CalculatePay
+Store
Klasa Employee implementuje zarówne reguły
biznesowe jak i mechanizmy zarządzania
trwałością
Podobne obszary NIGDY nie powinny być
łączone`
Technologie obiektowe
Zasada otwarte-zamknięte
Jak tworzyć projekty, które z jednej strony będą zachowywały
stabilność mimo zmian, a z drugiej będą rozbudowywane i
wydawane w formie wielu wersji?
Składniki oprogramowania (klasy, moduły, funkcje) powinny być
otwarte na rozbudowę, ale zamknięte dla modyfikacji.
Jeżeli pojedyncza zmiana programu, skutukuje koniecznością
wprowadzenia całej sekwencji modyfikacji w modułach
zależnych, możemy być pewni że nasz projekt nie jest
wystarczająco elastyczny.
" Zasada Open/Closed Principle
Technologie obiektowe
Zasada OCP
Prawidłowe zastosowanie zasady OCP, powoduje że dalsza
rozbudowa systemu będzie wymagała tylko dodawania nowego
kodu, a nie modyfikowania kodu już istniejącego i zdającego
egzamin w dotychczasowych wersjach
Modułu zbudowane zgodnie z zasadą OCP:
1) muszą być otwarte na rozszerzenia,
2) muszą być zamknięte dla modykacji.
Moduł, który nie może być modyfikowany w ten sposób, z reguły
jest postrzegany jako niezmienny, stały zbiór zachowań
Technologie obiektowe
Abstrakcja
Abstrakcje mają charakter stały (niezmienny) i jako takie mogą z
powodzeniem reprezentować grupę niezwiązanych ze sobą,
możliwych zachowań.
Abstrakcje mają postać klas abstrakcyjnych (interfejsów)  a grupa
możliwych zachowań to klasy potomne.
Moduł, który wykorzystuje abstrakcję, może być zamknięty dla
modyfikacji, ponieważ uzależnia swoje zachowanie od stałej
niezmiennej abstrakcji. Mimo to istnieje możliwość rozbudowy
tego modułu przez stworzenie nowych klas potomnych.
Technologie obiektowe
Przykład projektu niezgodnego z zasadą OCP
Client Server
Obiekt klasy Client wykorzystuje klasę Server.
Gdybyśmy chcieli zmienić Server (obiekt innej klasy) 
musielibyśmy w klasie Client zmienić nazwę wykorzystywanej
klasy Servera.
Technologie obiektowe
Rozwiązanie
<>
Client
ClientInterface
Server
ClientInterface  występuje w roli klasy abstrakcyjnej definiującej
abstrakcyjne funkcje składowe
Abstrakcja jest wykorzystywana przez klasę Client
Obiekty tej klasy będą wykorzystywały obiekty potomnej klasy Server
W przypadku zmiany Server'a  Client nie będzie wymagała
modyfikacji
Technologie obiektowe
Inny przykład  figury znowu
public class Class
public class Circle
{
{
static void Main(string[] args)
void DrawYourSelf()
{
{
ArrayList listka = new ArrayList();
Console.WriteLine("KOLKO");
Circle c = new Circle();
}
Rectangle r = new Rectangle();
}
listka.Add(c);
public class Rectangle
listka.Add(r);
{
}
void DrawYourSelf()
{
void DrawAllShapes(ArrayList listka)
{
Console.WriteLine("PROSTOKAT");
foreach (Object el in listka)
}
{
}
if (el is Circle)
(Circle)el.DrawYourSelf();
if (el is Rectangle)
(Rectangle)el.DrawYourSelf();
}
}
Technologie obiektowe
Dobrze
class Program
interface IDrawable
{
{
static void Main(string[] args)
void DrawYourself();
{
}
Shape myShape;
List shapes=new List();
class Rectangle : IDrawable
{
shapes.Add(new Rectangle());
public double width = 20, height = 20;
shapes.Add(new Circle());
public void DrawYourself()
{
Console.WriteLine(" PROSTOKAT ");
DrawAllShapes(shapes);
}
}
Console.ReadKey();
}
class Circle : IDrawable
{
public void DrawYourself()
void DrawAllShapes(List listka)
{
{
Console.WriteLine(" KOLKO ");
foreach (Shape el in listka)
}
{
}
el.DrawYourSelf()
}
}
}
Otwarte na rozbudowę- można dodać nową klasę Triangle
Zamknięte na modyfikacje  nie musimy zmieniać kodu, żeby wyświetlić wszystkie
elementy
Technologie obiektowe
Uwaga!!
Chcemy zmienić algorytmy wyświetlania figur  najpierw
wszystkie Circle, potem Rectangle itd.
Nasz projekt nie jest zamknięty na modyfikacje, gdyż musimy
zmienić metodę DrawAllShapes
Nasz model nie jest naturalny !!!
NIE ISTNIEJE JEDEN MODEL, KTÓRY BYA
BY NATURALNY WE
WSZYSTKICH KONTEKSTACH
Technologie obiektowe
Zmiany
Projektant musi przewidzieć zmiany, które mogą nastąpić
Projekt zatem jest zamknięty na pewien rodzaj zmian 
określonych przez projektanta.
Naszym celem jest zgromadzenie wiedzy o rodzajach
prawdopodobnych zmian.
Zachowanie zgodności z zasadą OCP jest dość kosztowne. Im
więcej abstrakcji tym bardziej złożony projekt.
Testy opracowanych scenariuszy użycia
Technologie obiektowe
Zasada podstawiania Liskov
Podstawowymi mechanizmami ułatwiającymi stosowanie OCP
jest abstrakcja i polimorfizm.
Kluczowy element umożliwiający stosowanie  dziedziczenie
Jakie reguły projektowe rządzą tym zastosowaniem dziedziczenia?
Zasada Podstawiania Liskov (Liskov Substitution Principle)
Musi istnieć możliwość zastępowania typów bazowych ich
podtypami
Technologie obiektowe
Naruszenie Zasady Podstawiania Liskov
public class Class
Public class Shape
{
{
static void Main(string[] args)
Void DrawYourSelf()
{
{
ArrayList listka = new ArrayList();
//costam cos tam
Circle c = new Circle();
}
Rectangle r = new Rectangle();
public class Circle : Shape
listka.Add(c);
{
listka.Add(r);
void DrawYourSelf()
}
{
Console.WriteLine("KOLKO");
void DrawAllShapes(ArrayList listka)
}
{
}
foreach (Object el in listka)
{
public class Rectangle : Shape
if (Shape is Circle)
{
el.DrawYourSelf();
void DrawYourSelf()
if (el is Rectangle)
{
el.DrawYourSelf();
}
Console.WriteLine("PROSTOKAT");
}
}
}
Technologie obiektowe
Naruszenie zasady
public class Rectangle
{
private double width;
private double height;
public double Width
Rectangle
{
get { return width; }
set { width = value; }
}
public double Height
{
get { return height; }
set { height = value; }
}
}
public class Square
Square
{
public double Width
{
set { base.Width = values; base.Height = value; }
}
public double Height
{
set { base.Width = values; base.Height = value; }
}
}
Technologie obiektowe
Naruszenie zasady
Square s = new Square();
s.SetWidth(1);
s.SetHeight(2);
void f(Rectangle r)
{
r.SetWidth(32);
}
f(s);
Autor klasy Square naruszył niezmienność
Klasy Rectangle!!!
Technologie obiektowe
Technologie obiektowe


Wyszukiwarka

Podobne podstrony:
pca w3
W3, Wiazania atomowe
informatyka II w3
nw asd w3
Optymalizacja w3 a pdf
DROGI w2 w3 tyczenie
Zsbd 2st 1 2 w3 tresc 1 1 kolor
w3 1
W3 Panstwo i polityka fiskalna
w3
w3 4 nowe pol srodki obrotu 14
W3 WYTYCZNE PROJEKTOWANIA RAM STALOWYCH ekran
W3 ?HAWIORALNA TERAPIA MALZENSTW
W3
R W3 przebieg
w3 nowe pol 10(1)
wmat w3
W3 spektrofotometria w podczerwieni

więcej podobnych podstron