Programowanie w języku Java WYKŁADriad.pk.edu.pl/~pzabawa/files/JP/ProgramowanieJava_W01.pdfW...

Programowanie w języku Java

WYKŁAD

dr inż. Piotr Zabawa

Certyfikowany Konsultant IBM/Rational

e-mail: [email protected]

www: http://www.pk.edu.pl/~pzabawa 24.02.2014

Zakład Inżynierii Oprogramowania

WYKŁAD 1Wzorce projektowe

dr inż..Piotr Zabawa Instytut Informatyki Wydział Fizyki, Matematyki i Informatyki


Znaczenie wzorców projektowych

• Podstawowe biblioteki Java oparte są o wzorce projektowe – widać je

od strony programisty Java

• Wzorce projektowe są podstawową dobrą praktyką programistyczną w

językach obiektowych

• Samodzielne stosowanie wzorców projektowych pozwala na:

– Uodpornienie kodu na zmiany (gł. związane z iteracyjnością

procesu wytwórczego)

– Zwiększenie ponownego użycia przez osłabienie relacji

– Prawidłowe uchwycenie podziału odpowiedzialności (wspiera

kryterium jakości programowania obiektowego weak coupling &

strong cohesion)

• Pozwala wprowadzić podstawowe pojęcia z UML



Czym są wzorce projektowe

• Są to ustandaryzowane rozwiązania często spotykanych problemów

projektowych o niewielkim zasięgu w kodzie (zwykle obejmują kilka

klas)

• Dzięki nim nie trzeba odkrywać za każdym razem na nowo tych

rozwiązań

• W inżynierii oprogramowania wyróżnia się szereg wzorców:

– Projektowe

– Architektoniczne

– Korporacyjne

– Przypadków użycia

– Analityczne

– Testowe…



Wzorce projektowe a Java

W każdym języku programowania wzorce mogą mieć różne realizacje.

W języku Java:

• Interfejsy

• Klasy abstrakcyjne

• Klasy wewnętrzne, w tym anonimowe klasy wewnętrzne

Dodatkowo potrzebna jest znajomość podstawowych mechanizmów

wspierających obiektowość:

• Abstrakcja

• Enkapsulacja

• Dziedziczenie

• Polimorfizm



Model UML a Java

Nie ma bezpośredniego związku między pojęciami UML a

mechanizmami dostępnymi w językach programowania. Model wyraża

koncepcje, które trzeba obsługiwać ręcznie w kodzie. To samo dotyczy

Javy.

Zrobić rysunki relacji i kodu ręcznie na tablicy.



Model UML a Java - generalizacja

Relacja generalizacji znana z UML (dotyczy nie tylko pojęcia klasy i

interfejsu) jako generalizacja ma swoje ucieleśnienie w obiektowych

językach programowania w postaci relacji dziedziczenia. Pojęcia te są

zbieżne.



Model UML a Java

class A1 {}

classs B1 extends A1 {}



Jest to relacja najsilniej wiążąca ze sobą klasy, a więc najbardziej

utrudniająca wprowadzanie zmian. Zmiany te mają tendencję do

propagowania się w hierarchii dziedziczenia. Wzorce projektowe

ograniczają negatywne skutki wprowadzania hierarchii dziedziczenia do

kodu źródłowego poprzez zmianę podziału odpowiedzialności.

Model UML a Java – relacje

asocjacyjneJest to zbiór relacji wiążących ze sobą obiekty czasem życia. Obejmuje

trzy relacje:

• Kompozycję

• Agregację

• Asocjację



Model UML a Java

class A2 {

class B2 {}

}



Relacja kompozycji wiąże ze sobą obiekty czasem życia w sposób bardzo

silny. Jeśli obiekt nadrzędny zostanie usunięty, to automatycznie musi

zostać usunięty obiekt podrzędny. Obiekt podrzędny jest widoczny tylko z

obiektu nadrzędnego, więc nie może być uwikłany w inne relacje

asocjacyjne.

Rzadko spotykana we wzorcach projektowych ze względu na zbyt silne

wiązanie ze sobą obiektów.

Model UML a Java

class B3 {}

class A3 {

B3 b3;

}



Relacja agregacji jest słabsza od relacji kompozycji. Wiąże ze sobą

obiekty czasem życia, jednak usunięcie obiektu nadrzędnego nie musi

oznaczać usuwania obiektów podrzędnych, gdyż mogą one uczestniczyć w

relacjach asocjacyjnych z innymi obiektami. O tym czy można usunąć

obiekty podrzędne decyduje programista/kod źródłowy. Relacja ta nie ma

bezpośredniego wsparcia w językach programowania.

Występuje często we wzorcach projektowych.

Model UML a Java

class B4 {}

class A4 {

B4 b4;

}



Najsłabsza z relacji asocjacyjnych. Wiąże obiekty czasem życia bardzo

słabo. Reprezentuje sytuację, w której są one dynamicznie podpinane

wzajemnie do siebie lub odpinane od siebie. Usunięcie jednego obiektu nie

implikuje usunięcia drugiego obiektu. Kod źródłowy w Java dla tej relacji

jest identyczny jak dla relacji agregacji. Jedyna różnica polega w sposobie

zarządzania czasem życia obiektów.

Często spotykana we wzorcach projektowych.

Model UML a Java

class B5 {}

class A5 {

void method(B5 b5) {}

}



Relacja zależności jest relacją najsłabiej wiążącą ze sobą klasy. Oznacza

ona, że jeśli wprowadzono zmianę do klasy B5, to zmiana ta może, ale nie

musi wpłynąć na kod źródłowy klasy A5.

Należy dążyć do maksymalnego wykorzystywania tej relacji. Odgrywa

ona ważną rolę w dekompozycji funkcjonalnej systemów oprogramowania.

Model UML a Java

Typowy dla wielu wzorców schemat dekompozycji odpowiedzialności

można zilustrować dekompozycją hierarchii dziedziczenia łączącej w

sobie zbyt wiele odpowiedzialności na hierarchie dziedziczenia połączone

słabą relacją asocjacyjną, zwykle relacją asocjacji.

Schemat ten został zilustrowany na kolejnym slajdzie.



Model UML a Java

Omówienie kwestii osłabiania relacji otwiera drogę do omówienia:

• Wzorców projektowych

• Wstrzykiwania zależności w Spring



Obiektowość w Java

Zostaną przedstawione podstawowe konstrukcje językowe wspierające

4 wyróżniki obiektowości:

• Abstrakcja

• Enkapsulacja

• Dziedziczenie

• Polimorfizm



Obiektowość w Java - abstrakcja

Mechanizm służący ukrywaniu implementacji przed jej

użytkownikiem. W podejściu obiektowym wspierany jest przez pojęcia:

• Interfejsu (obiekt jako instancja klasy lub jako komponent)

• Klasy abstrakcyjnej




Interfejs

W Java wykorzystuje się słowa kluczowe:

interface

implements




Klasa abstrakcyjna

W Java wykorzystuje się słowo kluczowe:

abstract



Obiektowość w Java - enkapsulacja

Ochrona dostępu do metod lub danych.

W Java wykorzystuje się słowa kluczowe:

private

protected

public

package

Domyślny jest package. Jest on związany z koncepcją podziału

elementów kodu źródłowego na pakiety – pojęcie z UML. Pełnią one w

Java rolę przestrzeni nazw reprezentowanej w C++ przez namespace.

Nawiązać do pakietu i podsystemu w UML. Podkreślić znaczenie.



Obiektowość w Java - dziedziczenie

Dziedziczenie oznacza, że jedna klasa jest uogólnieniem drugiej. Klasa

będąca jej uszczegółowieniem przejmuje cechy swojej nadklasy –

atrybuty i/lub zachowania.

W Java wykorzystuje się słowo kluczowe:

extends

W Java dziedziczenie pomiędzy klasami jest zawsze jednokrotne –

nie ma wielodziedziczenia pomiędzy klasami. Jednocześnie Java

umożliwia stosowanie wielodziedziczenia pomiędzy interfejsami.



Obiektowość w Java - polimorfizm

Zachowywanie się jednych obiektów jakby były szczególnymi

rodzajami obiektów innych klas. Zachowania zawsze dotyczą obiektów, a

rodzaje – klas, ponieważ klasy te mogą być abstrakcyjne, a więc mogą nie

mieć swoich instancji. Polimorfizm dotyczy operacji a nie danych.

Do realizacji polimorfizmu wykorzystuje się dziedziczenie i

rzutowanie w górę.



Obiektowość w Java - przykład

Wydawanie odgłosów przez zwierzęta.

Klasa abstrakcyjna Animal – w rzeczywistym świecie nie ma instancji.

[wszystkie klasy w jednym pakiecie]

[nie korzystamy z interfejsów]



Animal.java

package pl.edu.pk.javaprogramming.animals;

public abstract class Animal {

abstract public String say();

}




Klasy zwierząt konkretnych – podklasy klasy abstrakcyjnej Animal.



Dog.java, Cat.java


public class Dog extends Animal {

public String say() {

return "Hau";

}

}


public class Cat extends Animal{

public String say() {

return "Miau";

}

}




Klasa główna z metodą główną.

[biblioteka kontenerów ale bez iteratora]



AskAnimals.java


import java.util.ArrayList;

import java.util.List;

public class AskAnimals {

private static List<Animal> listOfAnimals = newArrayList<Animal>();

public static void main(String[] args) {

listOfAnimals.add(new Dog());

listOfAnimals.add(new Cat());

listOfAnimals.add(new Dog());

for(int i=0; i<3; i++)

System.out.println(listOfAnimals.get(i).say());

}

}



Klasyfikacja wzorców projektowych

Wg rodzaju:

• Kreacyjne

• Strukturalne

• Czynnościowe

Wg zakresu

• Obiektowe

• Klasowe



Klasyfikacja wzorców projektowych



Rodzaj

Kreacyjne Strukturalne Czynnościowe

Zakres Klasy Factory Method Adaptor (klasy) Interpreter

Template Method

Obiekty Builder

Abstract Factory

Prototype

Singleton

Adaptor

(obiekty)

Decorator

Facade

Composite

Bridge

Proxy

Flyweight

Iterator

Chain of Responsibility

Mediator

Observer

Visitor

Memento

Command

State

Strategy

Sposób specyfikowania wzorców• nazwa wzorca i jego kategoria

• przeznaczenie

• inne nazwy

• uzasadnienie stosowania

• stosowalność

• struktura

• uczestnicy

• współpraca

• konsekwencje

• implementacja

• przykłady

• znane zastosowania

• pokrewne wzorce



Przykłady wzorców projektowych

Przykłady wszystkich wzorców GoF zaimplementowane w Java:

http://www.fluffycat.com/Java-Design-Patterns/

Znajdują się tam jedynie fragmenty kodów źródłowych. Cały projekt

pod Eclipse jest dostępny do pobrania z:

http://riad.usk.pk.edu.pl/~pzabawa/StaticXHTML/files/samples/PK-

DP_samples.zip



Wzorce projektowe

Wprowadzenie wzorców projektowych otwiera drogę do omówienia:

• Typów prostych i ich opakowań

• Definicji interfejsów i klas

• Klas wewnętrznych

• Programowania aspektowego



Wzorzec strukturalny

Dalej zostanie omówiony strukturalny wzorzec projektowy Dekorator.

Na wykładzie przedstawiony zostanie w ujęciu GOF w sposób ogólny, a

na laboratorium w postaci implementacji Java w ujęciu Fluffycat.

Powodem omawiania tego wzorca jest intensywne wykorzystywanie

go przez programistów Java SE w bibliotekach działających na

strumieniach, czyli:

• java.io

• java.nio

• java.util.zip

Przykład wywołania:

DataOutputStream os = new DataOutputStream(

new BufferedOutputStream (

new FileOutputStream (fileName)));



Wzorzec strukturalny

Wprowadzenie tego wzorca otwiera drogę do omówienia biblioteki

wejścia/wyjścia i strumieni w Java.



Wzorzec Strukturalny: Dekorator

Dynamicznie dołącza do obiektów dodatkowe zobowiązania.

Zapewnia elastyczną alternatywę dla tworzenia podklas w celu

rozszerzania funkcjonalności.

Inne nazwy:

Opakowanie (Wrapper)




Uzasadnienie stosowania:

Czasami chcemy dołączyć pewne zobowiązania do niektórych

obiektów a nie całych klas. Np. dodanie ramek i pasków przewijania do

składników GUI.

Dziedziczenie jest kłopotliwe – statyczny wybór ramki, na dodatek dla

każdego elementu.




Lepszym rozwiązaniem jest umieszczenie obiektu dekorowanego

(element GUI) wewnątrz obiektu dekorujacego (ramka, scrollbars).

Dekorator dostosowuje się do interfejsu dekorowanego obiektu stając

się przeźroczystym dla klienta obiektu dekorowanego.




Dekorator przekazuje żądania do obiektu dekorowanego i może

wykonywać dodatkowe operacje przed lub po otrzymaniu żądania.

Przeźroczystość ta umożliwia rekurencyjne zagnieżdżanie dekoratorów.




Mamy obiekt klasy WidokTekstowy wyświetlający tekst w okienku.

Standardowo nie ma on suwaków. Możemy je dodać za pomocą

DekoratorZSuwakami. Ramkę możemy dodać za pomocą

DekoratoraZRamkami. Klasy DekoratorZSuwakami i

DekoratoraZRamkami są podklasami abstrakcyjnej klasy Dekorator

reprezentującej komponenty wizulane, które ozdabiają inne komponenty

wizualne.




Klasa Dekorator przesyła żądania do swojego komponentu a podklasy

mogą rozszerzać to działanie. Jeśli klient wie jaki dekorator został

wykorzystany, to może skorzystać z tych rozszerzeń.




Stosowalność:

• dynamiczne i przeźroczyste dodawanie zobowiązania do pojedynczych

obiektów

• dodanie zobowiązań, które mogą zostać cofnięte

• niepraktyczne rozszerzanie przez podklasy – mnóstwo niezależnych

rozszerzeń może spowodować eksplozję hierarchii.

Struktura:




Uczestnicy:

• Komponent (KomponentWizualny)

– definiuje interfejs obiektów, do których można dynamicznie dołączać zobowiązania

• KomponentKonkretny (WidokTekstowy)

– definiuje obiekt, do którego można dołączać dodatkowe zobowiązania




• Dekorator

– zarządza odwołaniem do obiektu Komponent i definiuje interfejs dopasowany do interfejsu Komponentu

• DekoratorKonkretny (.,.)

– dodaje zobowiązania do Komponentu

Współpraca:

• Dekorator przesyła żądania do swojego obiektu Komponent. Może opcjonalnie wykonywać inne operacje przed lub po przesłaniu żądania




Konsekwencje:

• większa elastyczność niż przy stosowaniu statycznego dziedziczenia –runtime, mieszanie zobowiązań, wielokrotne dołączanie właściwości (podwójna ramka)

• unikanie przeładowanych właściwościami klas na szczycie hierarchii –koncepcja prostej klasy na szczycie wzbogacanej w miarę potrzeb przez dekoratory




• Dekorator i jego komponent nie są identyczne

• wiele małych obiektów – takie systemy składają się z wielu małych

połączonych ze sobą w skomplikowany sposób obiektów – ich autorzy

mogą je bardzo łatwo zmieniać, ale trudno je zrozumieć i trudno

usuwać z nich błędy




Implementacja:

• zgodność interfejsów obiektu dekorujacego i dekorowanego

• pomijanie klasy abstrakcyjnej Dekorator – gdy dodajemy tylko jedno zobowiązanie (po co ujednolicać interfejsy)

• utrzymanie lekkości klasy Komponent – nie powinna definiować danych

• zmiana skóry obiektu (Decorator) a zmiana wnętrza obiektu (Strategy)




Przykłady:

Znane zastosowania:

• GUI

• strumienie IO [rys.]




Pokrewne wzorce:

• Adapter – zmienia interfejs a nie tylko zobowiązania.

• Kompozyt. Decorator to zdegenerowany Kompozyt z jednym

komponentem.

• Strategia – zmienia wnętrze obiektu, a Dekorator zewnętrze –

konkurencyjny sposób zmieniania obiektu (Strategia - gdy klasa

Komponent jest ciężka)



Koniec



Programowanie w języku Java WYKŁADriad.pk.edu.pl/~pzabawa/files/JP/ProgramowanieJava_W01.pdfW...

Documents

Transcript of Programowanie w języku Java WYKŁADriad.pk.edu.pl/~pzabawa/files/JP/ProgramowanieJava_W01.pdfW...