Design Patterns
239 pág.

Design Patterns


DisciplinaEngenharia de Software I4.631 materiais51.704 seguidores
Pré-visualização50 páginas
where each multiton instance in the pool may exist having its own state. In this
manner, the pattern advocates indexed storage of essential objects for the system (such as would be provided by an
LDAP system, for example). However, a multiton is limited to wide use by a single system rather than a myriad of
distributed systems.
Drawbacks
This pattern, like the Singleton pattern, makes unit testing far more difficult[2], as it introduces global state into an
application.
With garbage collected languages it may become a source of memory leaks as it introduces global strong references
to the objects.
References
[1] http:/ / stackoverflow. com/ questions/ 2346091/ c-templated-class-implementation-of-the-multiton-pattern
[2] http:/ / googletesting. blogspot. com/ 2008/ 11/ clean-code-talks-global-state-and. html
External links
\u2022 Multiton implementation in Ruby language (http:/ / raa. ruby-lang. org/ project/ multiton/ )
\u2022 Multiton usage in PureMVC Framework for ActionScript 3 (http:/ / trac. puremvc. org/
PureMVC_AS3_MultiCore/ browser/ tags/ 1. 0. 4/ src/ org/ puremvc/ as3/ multicore/ patterns/ facade/ Facade. as)
\u2022 Article with a C# Multiton implementation, example of use, and discussion of memory issues (http:/ / gen5. info/
q/ 2008/ 07/ 25/ the-multiton-design-pattern/ )
Object pool pattern 57
Object pool pattern
For the article about a general pool see Pool (Computer science)
The object pool pattern is a software creational design pattern that uses a set of initialised objects kept ready to use,
rather than allocating and destroying them on demand. A client of the pool will request an object from the pool and
perform operations on the returned object. When the client has finished, it returns the object, which is a specific type
of factory object, to the pool rather than destroying it.
Object pooling can offer a significant performance boost in situations where the cost of initializing a class instance is
high, the rate of instantiation of a class is high, and the number of instances in use at any one time is low. The pooled
object is obtained in predictable time when creation of the new objects (especially over network) may take variable
time.
However these benefits are mostly true for objects that are expensive with respect to time, such as database
connections, socket connections, threads and large graphic objects like fonts or bitmaps. In certain situations, simple
object pooling (that hold no external resources, but only occupy memory) may not be efficient and could decrease
performance[1].
Handling of empty pools
Object pools employ one of three strategies to handle a request when there are no spare objects in the pool.
1.1. Fail to provide an object (and return an error to the client).
2. Allocate a new object, thus increasing the size of the pool. Pools that do this usually allow you to set the high
water mark (the maximum number of objects ever used).
3. In a multithreaded environment, a pool may block the client until another thread returns an object to the pool.
Pitfalls
When writing an object pool, the programmer has to be careful to make sure the state of the objects returned to the
pool is reset back to a sensible state for the next use of the object. If this is not observed, the object will often be in
some state that was unexpected by the client program and may cause the client program to fail. The pool is
responsible for resetting the objects, not the clients. Object pools full of objects with dangerously stale state are
sometimes called object cesspools and regarded as an anti-pattern.
The presence of stale state is not always an issue; it becomes dangerous when the presence of stale state causes the
object to behave differently. For example, an object that represents authentication details may break if the
"successfully authenticated" flag is not reset before it is passed out, since it will indicate that a user is correctly
authenticated (possibly as someone else) when they haven't yet attempted to authenticate. However, it will work just
fine if you fail to reset some value only used for debugging, such as the identity of the last authentication server
used.
Inadequate resetting of objects may also cause an information leak. If an object contains confidential data (e.g. a
user's credit card numbers) that isn't cleared before the object is passed to a new client, a malicious or buggy client
may disclose the data to an unauthorized party.
If the pool is used by multiple threads, it may need means to prevent parallel threads from grabbing and trying to
reuse the same object in parallel. This is not necessary if the pooled objects are immutable or otherwise thread-safe.
Object pool pattern 58
Criticism
Some publications do not recommend using object pooling with certain languages, such as Java, especially for
objects that only use memory and hold no external resources.[2] Opponents usually say that object allocation is
relatively fast in modern languages with garbage collectors; while the operator new needs only ten instructions, the
classic new - delete pair found in pooling designs requires hundreds of them as it does more complex work.
Also, most garbage collectors scan "live" object references, and not the memory that these objects use for their
content. This means that any number of "dead" objects without references can be discarded with little cost. In
contrast, keeping a large number of "live" but unused objects increases the duration of garbage collection[1]. In some
cases, programs that use garbage collection instead of directly managing memory may run faster.
Examples
In the .NET Base Class Library there are a few objects that implement this pattern.
System.Threading.ThreadPool is configured to have a predefined number of threads to allocate. When the
threads are returned, they are available for another computation. Thus, one can use threads without paying the cost of
creation and disposal of threads.
Java supports thread pooling via java.util.concurrent.ExecutorService and other related classes.
The executor service has a certain number of "basic" threads that are never discarded. If all threads are busy, the
service allocates the allowed number of extra threads that are later discarded if not used for the certain expiration
time. If no more threads are allowed, the tasks can be placed in the queue. Finally, if this queue may get too long, it
can be configured to suspend the requesting thread.
References
[1] Goetz, Brian (2005-09-27). "Java theory and practice: Urban performance legends, revisited" (http:/ / www. ibm. com/ developerworks/ java/
library/ j-jtp09275/ index. html). IBM developerWorks. Archived from the original (http:/ / www. ibm. com/ ) on 2005-09-27. . Retrieved
2012-08-28.
[2] Goetz, Brian (2005-09-27). "Java theory and practice: Garbage collection in the HotSpot JVM" (http:/ / www. ibm. com/ developerworks/
java/ library/ j-jtp11253/ ). IBM developerWorks. Archived from the original (http:/ / www. ibm. com/ ) on 2003-11-25. . Retrieved
2012-08-28.
\u2022 Kircher, Michael; Prashant Jain; (2002-07-04). "Pooling Pattern" (http:/ / www. kircher-schwanninger. de/
michael/ publications/ Pooling. pdf). EuroPLoP 2002. Germany. Retrieved 2007-06-09.
External links
\u2022 OODesign article (http:/ / www. oodesign. com/ object-pool-pattern. html)
\u2022 Improving Performance with Object Pooling (Microsoft Developer Network ) (http:/ / msdn2. microsoft. com/
en-us/ library/ ms682822. aspx)
\u2022 Developer.com article (http:/ / www. developer. com/ tech/ article. php/ 626171/ Pattern-Summaries-Object-Pool.
htm)
\u2022 Portland Pattern Repository entry (http:/ / c2. com/ cgi-bin/ wiki?ObjectPoolPattern)
\u2022 Apache Commons Pool: A mini-framework to correctly implement object pooling in Java (http:/ / commons.
apache. org/ pool/ )
\u2022 Game Programming Patterns: Object Pool (http:/ / gameprogrammingpatterns. com/ object-pool.