4.1 Builder
Builder е генеративен шаблон за проектиране, който предоставя начин за създаване на съставен обект.
Разделя конструкцията на сложен обект от неговото представяне, така че един и същ процес на конструиране може да доведе до различни представяния.
Силни страни:
- ви позволява да промените вътрешното представяне на продукта;
- изолира codeа, който реализира конструкцията и представянето;
- дава по-фин контрол върху процеса на проектиране.
Слаби страни:
- алгоритъмът за създаване на сложен обект не трябва да зависи от това от Howви части се състои обектът и How се съчетават;
- процесът на изграждане трябва да осигурява различни представяния на обекта, който се изгражда.
Добър пример е класът HttpRequest, който има подклас HttpRequest.Builder, който може да се използва за създаване на екземпляри на класа HttpRequest и гарантиране, че са валидни.
4.2 Мързелива инициализация
Мързеливата инициализация е техника на програмиране, когато няHowва ресурсоемка операция (създаване на обект, изчисляване на стойност) се изпълнява непосредствено преди нейният резултат да бъде използван.
По този начин инициализацията се извършва „при поискване“, а не предварително. Подобна идея намира приложение в различни области: например компилация в движение и логистична концепция Just-in-Time.
Специален случай на мързелива инициализация - създаване на обект в момента на достъп до него - е един от генеративните дизайнерски модели. Обикновено се използва във връзка с модели като Factory Method, Loner и Proxy.
Силни страни:
- Инициализацията се извършва само когато наистина е необходимо;
- Първоначалната инициализация на приложението се ускорява: всичко, което може да бъде отложено, се отлага.
Слаби страни:
- Не е възможно изрично да се зададе редът, в който обектите се инициализират;
- Има забавяне при първия достъп до обекта, което може да бъде критично, когато паралелно се изпълнява друга ресурсоемка операция. Поради това е необходимо внимателно да се обмисли целесъобразността на използването на мързелива инициализация в многонишкови софтуерни системи.
Помните ли How, когато пишете web.xml, можете да посочите началния ред на сървлетите там? Точно това е резултат от мързеливото зареждане. Tomcat ще създаде сървлет обекти при първия достъп до тях.
4.3 Обектен пул
Обектният пул е родителски шаблон за проектиране, набор от инициализирани и готови за използване обекти. Когато системата се нуждае от обект, той не се създава, а се взема от пула. Когато даден обект вече не е необходим, той не се унищожава, а се връща в пула.
Обединяването на обекти се използва за подобряване на производителността, когато създаването на обект в началото на заданието и унищожаването му в края е скъпо. Подобряването на производителността е особено забележимо, когато обектите се създават и унищожават често, но само малък брой от тях съществуват едновременно.
Обектният пул е полезен, когато даден обект притежава ресурси, различни от памет, като мрежови сокети. Или ако колекцията от обекти заема значителна част от паметта на компютъра и се създава много "боклук".
Както си спомняте, Tomcat изпълнява всяка заявка в отделна нишка. Но нишките не се създават всеки път наново, а се съхраняват в пула с нишки. Това позволява по-бързо изпълнение на заявки: когато е необходима нишка, тя просто се взема от пула. Между другото, въпросът е: How бихте поставor текущата нишка в пула и How бихте го взели от пула?