Zpo-8-wyk-Slajd35: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Linia 1: Linia 1:
==Przykład(1)==
==Incomplete Library Classs==


[[Image:zpo-8-wyk-Slajd35.PNG|Przykład(1)]]
[[Image:zpo-8-wyk-Slajd35.PNG|Incomplete Library Classs]]




Po wykonaniu przekształcenia powstał nowy interfejs – Wydawnictwo, który deklaruje identyczne dwie metody co klasa Książka. Zadeklarowanie tego interfejsu w klasie Książka nie wymaga zatem żadnych innych zmian w kodzie. Dzięki tej zmianie możliwe jest rozszerzenie typu argumentu metody ''wyswietlDane'' ''()'' do interfejsu Wydawnictwo, co umożliwia użycie w przyszłości innych implementacji tego interfejsu (np. czasopisma, książki wielotomowej etc.).
Niekompletność klasy bibliotecznej nie jest wynikiem błędu programisty korzystającego z tej klasy, jednak niewątpliwie stanowi zagrożenie dla struktury programu. Brakująca funkcja musi być zaimplementowana w miejscu, w którym intuicyjnie będzie można ją odnaleźć.


W efekcie w miejsce klasy, która definiowała jednocześnie typ i implementację powstały dwa odrębne elementy: interfejs określający zakres odpowiedzialności oraz klasa będąca jego realizacją.
Sugerowane są dwa rozwiązania: w prostych przypadkach należy zaimplementować funkcję po stronie klienta, opatrując ją komentarzem dotyczącym niewłaściwej lokalizacji i jej przyczyn. Jeżeli brakuje większej liczby funkcji, wówczas można zastosować tzw. lokalne rozszerzenie klasy bibliotecznej, czyli specjalizowaną podklasę lub opakowanie (ang. ''wrapper'' ), posiadające te funkcje. Oba rozwiązania mają wady, które wpływają na decyzję dotyczącą ich zastosowania. Stworzenie podklasy wymaga, aby klasa była niefinalna, z drugiej strony udostępnia jednak składowe klasy aż do poziomu chronionego. Aby stworzyć opakowanie należy m.in. zaimplementować interfejs klasy bibliotecznej, co oznacza, że jego brak uniemożliwia zastosowanie tego rozwiązania. Ponadto opakowanie ma dostęp jedynie do publicznych składowych klasy bibliotecznej.




[[zpo-8-wyk-Slajd34 | << Poprzedni slajd]] | [[zpo-8-wyk-toc|Spis treści ]] | [[zpo-8-wyk-Slajd36 | Następny slajd >>]]
[[zpo-8-wyk-Slajd34 | << Poprzedni slajd]] | [[zpo-8-wyk-toc|Spis treści ]] | [[zpo-8-wyk-Slajd36 | Następny slajd >>]]

Aktualna wersja na dzień 18:14, 4 lis 2006

Incomplete Library Classs

Incomplete Library Classs


Niekompletność klasy bibliotecznej nie jest wynikiem błędu programisty korzystającego z tej klasy, jednak niewątpliwie stanowi zagrożenie dla struktury programu. Brakująca funkcja musi być zaimplementowana w miejscu, w którym intuicyjnie będzie można ją odnaleźć.

Sugerowane są dwa rozwiązania: w prostych przypadkach należy zaimplementować funkcję po stronie klienta, opatrując ją komentarzem dotyczącym niewłaściwej lokalizacji i jej przyczyn. Jeżeli brakuje większej liczby funkcji, wówczas można zastosować tzw. lokalne rozszerzenie klasy bibliotecznej, czyli specjalizowaną podklasę lub opakowanie (ang. wrapper ), posiadające te funkcje. Oba rozwiązania mają wady, które wpływają na decyzję dotyczącą ich zastosowania. Stworzenie podklasy wymaga, aby klasa była niefinalna, z drugiej strony udostępnia jednak składowe klasy aż do poziomu chronionego. Aby stworzyć opakowanie należy m.in. zaimplementować interfejs klasy bibliotecznej, co oznacza, że jego brak uniemożliwia zastosowanie tego rozwiązania. Ponadto opakowanie ma dostęp jedynie do publicznych składowych klasy bibliotecznej.


<< Poprzedni slajd | Spis treści | Następny slajd >>