classcontinue;Guitarif (searchSpec...

getType() != guitarSpec.getType())
Gui-
tar()
continue;
}
if (searchSpec.getBackWood() != guitarSpec.getBackWood())
continue;
Guitar.java
if (searchSpec.getTopWood() != guitarSpec.getTopWood())
continue;
matchingGuitars.add(guitar);
}
class
return matchingGuitars;
Inven-
tory {
}
Search()}
Inventory.java
jesteś tutaj 
71
Staraj się, by fragmenty aplikacji można było wielokrotnie używać
Zagadka projektowa
Sama wiedza, że w aplikacji Ryśka coś szwankuje, to zdecydowanie za mało. Nie wystarczy także świadomość, że konieczne jest ponowne zastosowanie hermetyzacji. Teraz musisz wymyślić, jak należy poprawić tę aplikację, by łatwiej można było wielokrotnie stosować jej fragmenty oraz by jej rozszerzanie nie przysparzało tylu problemów.
Problem:
Dodanie nowej właściwości do klasy GuitarSpec zmusza nas do wprowadzenia zmian także w kodzie klas Guitar oraz Inventory. Strukturę aplikacji należy zmienić w taki sposób, by dodawanie nowych właściwości do klasy GuitarSpec nie powodowało konieczności
modyfikacji innych klas.
Twoje zadanie:
1 Dodaj właściwość numStrings oraz metodę getNumStrings() do klasy GuitarSpec.
2 Zmodyfikuj kod klasy Guitar w taki sposób, by właściwości obiektu GuitarSpec zostały Nie wiesz, co —
usunięte z konstruktora tej klasy.
w tym kontekście
— oznacza
„delegowanie”
3 Zmień metodę search() w klasie Inventory w taki sposób, by porównywanie dwóch
— sprawdź…
obiektów GuitarSpec zostało delegowane do klasy GuitarSpec, a nie było realizowane bezpośrednio w tej metodzie.
4 Zmodyfikuj kod klasy FindGuitarTester, by działała ona poprawnie ze zmienionymi klasami Guitar, GuitarSpec i Inventory, a następnie upewnij się, że wyszukiwanie gitar działa poprawnie.
5 Porównaj odpowiedzi, które podałeś, z naszymi odpowiedziami zamieszczonymi na stronie 74; następnie przygotuj się na kolejny test, który pozwoli Ci przekonać się, czy wreszcie zakończyłeś prace nad aplikacją Ryśka.
Jedyna zmiana, jaką
wprowadzić
będziesz musiał
w tym miejscu,
kodu tworzącego
dotyczy
testową
magazynu
zawartość
i polega
nowego
na zastosowaniu
konstruktora klasy Guitar.
72
Rozdział 1.
Dobrze zaprojektowane aplikacje są super
Nie ma
niemądrych pytań
P.: Napisaliście, że powinienem „delegować”
P.: A niby w jaki sposób to delegowanie ma ułatwiać
porównywanie do klasy GuitarSpec. Co to jest
możliwości wielokrotnego wykonywania kodu?
delegowanie?
O.:
O.: Dzięki delegowaniu każdy obiekt może sam zajmować
O delegowaniu mówimy w sytuacji, gdy obiekt, który musi
się porównywaniem z innymi obiektami (lub wykonywaniem
wykonać pewną czynność, zamiast wykonać ją samemu, prosi o jej
jakiejkolwiek innej operacji). To z kolei oznacza, że obiekty mogą
wykonanie (w całości lub częściowo) inny obiekt.
być bardziej niezależne albo luźniej powiązane. Takie luźniej
A zatem, w swojej zagadce projektowej nie chcesz, by metoda
powiązane obiekty łatwiej jest zastosować w innej aplikacji, gdyż
search() klasy Inventory porównywała dwie specyfikacje
nie są one ściśle uzależnione od kodu innych obiektów.
GuitarSpec bezpośrednio w swoim kodzie. Zamiast tego chcesz,
by poprosiła obiekt GuitarSpec o określenie, czy specyfikacje
P.:
te odpowiadają sobie. A zatem metoda search() deleguje
Jeszcze raz — co oznacza „luźne powiązanie”?
porównanie do obiektu GuitarSpec.
O.:
P.:
Luźne powiązanie oznacza, że każdy z obiektów używanych
A dlaczego używamy takiego rozwiązania?
w aplikacji wykonuje tylko i wyłączenie swoje zadania. A zatem
cała funkcjonalność aplikacji jest rozdzielona i zaimplementowana
O.:
w dobrze zdefiniowanych obiektach, z których każdy w doskonały
Delegowanie ułatwia wielokrotne wykorzystywanie kodu
sposób realizuje przypisane mu zadania.
aplikacji. Oprócz tego pozwala ono, by każdy obiekt koncentrował
się wyłącznie na swoich możliwościach funkcjonalnych i chroni
przed umieszczaniem zachowań związanych z jednym obiektem
P.: A dlaczego to jest dobre rozwiązanie?
w różnych miejscach kodu aplikacji.
Jednym z najczęściej spotykanych przykładów delegowania
O.:
w języku Java jest metoda equals(). Metoda ta nie stara
Aplikacje tworzone przez luźno powiązane obiekty zazwyczaj
się samodzielnie sprawdzać, czy dwa obiekty są sobie równe,
są bardziej elastyczne i łatwiej można wprowadzać w nich
lecz zamiast tego wywołuje metodę equals() jednego
modyfikacje. Ponieważ poszczególne obiekty nie są zwykle w żaden
z porównywanych obiektów i przekazuje w jej wywołaniu drugi
sposób zależne od innych obiektów, zatem możemy zmienić
obiekt. Następnie pobiera jedynie wartość true lub false zwróconą
zachowanie jednego z obiektów bez konieczności wprowadzania
przez wywołanie metody equals().
modyfikacji w innych. Dzięki temu dodawanie nowych właściwości
lub możliwości funkcjonalnych staje się znacznie prostsze.
Kącik naukowy
delegowanie — proces polegający na tym, iż jeden
obiekt zleca wykonanie pewnej operacji innemu, który
wykonuje ją w imieniu pierwszego obiektu.
jesteś tutaj  73
Jeszcze więcej hermetyzacji
Zagadka projektowa — Rozwiązanie
Sama wiedza, że w aplikacji Ryśka coś szwankuje, to zdecydowanie za mało. Nie wystarczy także świadomość, że konieczne jest ponowne zastosowanie hermetyzacji. Teraz musisz wymyślić, jak należy poprawić tę aplikację, by łatwiej można było wielokrotnie stosować jej fragmenty oraz by jej rozszerzanie nie przysparzało tylu problemów.
Problem:
Dodanie nowej właściwości do klasy GuitarSpec zmusza nas do wprowadzenia zmian także w kodzie klas Guitar oraz Inventory. Strukturę aplikacji należy zmienić w taki sposób, by dodawanie nowych właściwości do klasy GuitarSpec nie powodowało konieczności modyfikacji innych klas.
Twoje zadanie:
1 Dodaj właściwość numStrings oraz metodę getNumStrings() do klasy GuitarSpec.
public class GuitarSpec {
Nie zapomnij zmodyfikować
// inne właściwości
konstruktora klasy
GuitarSpec.
private int numStrings;
To było
public GuitarSpec(Builder builder, String model, Type type,
naprawdę
łatwe…
int numStrings, Wood backWood, Wood topWood) {
this.builder = builder;
this.model = model;
this.type = type;
this.numStrings = numStrings;
this.backWood = backWood;
this.topWood = topWood;
}
// inne metody