4.1 Builder
Builder is a generative design pattern that provides a way to create a composite object.
Separates the construction of a complex object from its representation so that the same construction process can result in different representations.
Strengths:
- allows you to change the internal representation of the product;
- isolates the code that implements construction and presentation;
- gives finer control over the design process.
Weak sides:
- the algorithm for creating a complex object should not depend on what parts the object consists of and how they fit together;
- the construction process must provide different representations of the object being constructed.
A good example is the HttpRequest class, which has a subclass HttpRequest.Builder that can be used to create instances of the HttpRequest class and ensure they are valid.
4.2 Lazy initialization
Lazy initialization is a programming technique when some resource-intensive operation (object creation, value calculation) is performed immediately before its result is used.
Thus, initialization is performed “on demand”, and not in advance. A similar idea finds application in a variety of areas: for example, on-the-fly compilation and the Just-in-Time logistics concept.
A special case of lazy initialization - creating an object at the time of accessing it - is one of the generative design patterns. It is typically used in conjunction with patterns such as Factory Method, Loner, and Proxy.
Strengths:
- Initialization is performed only when it is really needed;
- The initial initialization of the application is accelerated: everything that can be postponed is postponed.
Weak sides:
- It is not possible to explicitly set the order in which objects are initialized;
- There is a delay at the first access to the object, which can be critical when another resource-intensive operation is performed in parallel. Because of this, it is necessary to carefully consider the appropriateness of using lazy initialization in multithreaded software systems.
Remember how when writing web.xml you could specify the start order of servlets there? This is exactly the result of lazy loading. Tomcat will create servlet objects the first time they are accessed.
4.3 Object pool
An object pool is a parent design pattern, a set of initialized and ready-to-use objects. When the system needs an object, it is not created, but taken from the pool. When an object is no longer needed, it is not destroyed but returned to the pool.
Object pooling is used to improve performance when creating an object at the start of a job and destroying it at the end is expensive. The performance improvement is especially noticeable when objects are created and destroyed frequently, but only a small number of them exist at the same time.
An object pool is useful when an object owns resources other than memory, such as network sockets. Or if the collection of objects takes up a significant part of the computer's memory and a lot of "garbage" is created.
As you remember, Tomcat executes each request in a separate thread. But threads are not created each time anew, but are stored in the thread pool. This allows faster execution of requests: when a thread is needed, it is simply taken from the pool. By the way, the question is: how would you put the running thread into the pool and take it from the pool?