4.1 Konstruktor
Builder to generatywny wzorzec projektowy, który umożliwia tworzenie obiektów złożonych.
Oddziela konstrukcję złożonego obiektu od jego reprezentacji, dzięki czemu ten sam proces konstrukcyjny może skutkować różnymi reprezentacjami.
Silne strony:
- pozwala na zmianę wewnętrznej reprezentacji produktu;
- izoluje kod implementujący konstrukcję i prezentację;
- zapewnia lepszą kontrolę nad procesem projektowania.
Słabe strony:
- algorytm tworzenia złożonego obiektu nie powinien zależeć od tego, z jakich części składa się obiekt i jak do siebie pasują;
- proces konstrukcyjny musi zapewniać różne reprezentacje konstruowanego obiektu.
Dobrym przykładem jest klasa HttpRequest, która ma podklasę HttpRequest.Builder, której można użyć do tworzenia instancji klasy HttpRequest i sprawdzania, czy są one poprawne.
4.2 Leniwa inicjalizacja
Leniwa inicjalizacja to technika programowania polegająca na wykonywaniu jakiejś operacji wymagającej dużej ilości zasobów (tworzenie obiektu, obliczanie wartości) bezpośrednio przed użyciem jej wyniku.
W ten sposób inicjalizacja jest wykonywana „na żądanie”, a nie z wyprzedzeniem. Podobny pomysł znajduje zastosowanie w różnych obszarach: na przykład kompilacja w locie i koncepcja logistyki Just-in-Time.
Szczególnym przypadkiem leniwej inicjalizacji - tworzenia obiektu w momencie uzyskiwania do niego dostępu - jest jeden z generatywnych wzorców projektowych. Zwykle jest używany w połączeniu z wzorcami, takimi jak Metoda fabryczna, Loner i Proxy.
Silne strony:
- Inicjalizacja jest wykonywana tylko wtedy, gdy jest naprawdę potrzebna;
- Początkowa inicjalizacja aplikacji jest przyspieszona: wszystko, co można odłożyć, jest odroczone.
Słabe strony:
- Nie jest możliwe jawne ustawienie kolejności, w jakiej obiekty są inicjowane;
- Przy pierwszym dostępie do obiektu występuje opóźnienie, które może mieć krytyczne znaczenie, gdy równolegle wykonywana jest inna operacja intensywnie korzystająca z zasobów. Z tego powodu konieczne jest dokładne rozważenie zasadności stosowania leniwej inicjalizacji w wielowątkowych systemach oprogramowania.
Pamiętasz, jak podczas pisania pliku web.xml można było określić w nim kolejność początkową serwletów? To jest właśnie wynik leniwego ładowania. Tomcat utworzy obiekty serwletu przy pierwszym dostępie do nich.
4.3 Pula obiektów
Pula obiektów to nadrzędny wzorzec projektowy, zestaw zainicjowanych i gotowych do użycia obiektów. Kiedy system potrzebuje obiektu, nie jest on tworzony, ale pobierany z puli. Kiedy obiekt nie jest już potrzebny, nie jest niszczony, ale zwracany do puli.
Pule obiektów służą do poprawy wydajności, gdy tworzenie obiektu na początku zadania i niszczenie go na końcu jest kosztowne. Poprawa wydajności jest szczególnie zauważalna, gdy obiekty są często tworzone i niszczone, ale jednocześnie istnieje tylko niewielka ich liczba.
Pula obiektów jest przydatna, gdy obiekt posiada zasoby inne niż pamięć, takie jak gniazda sieciowe. Lub jeśli kolekcja obiektów zajmuje znaczną część pamięci komputera i powstaje dużo „śmieci”.
Jak pamiętasz, Tomcat wykonuje każde żądanie w osobnym wątku. Ale wątki nie są tworzone za każdym razem od nowa, ale są przechowywane w puli wątków. Pozwala to na szybsze wykonywanie żądań: gdy potrzebny jest wątek, jest on po prostu pobierany z puli. Nawiasem mówiąc, pytanie brzmi: w jaki sposób umieściłbyś działający wątek w puli i zabrałbyś go z puli?