Changed the absolute links in README to relative links for issue #180
This commit is contained in:
Narendra Pathai
parent
2aa9681b91
commit
fba92e281d
106
README.md
106
README.md
@ -116,7 +116,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="abstract-factory">Abstract Factory</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Abstract Factory pattern when
|
||||
* a system should be independent of how its products are created, composed and represented
|
||||
@ -130,7 +130,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="builder">Builder</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Separate the construction of a complex object from its representation so that the same construction process can create different representations.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Builder pattern when
|
||||
* the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled
|
||||
@ -143,7 +143,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="factory-method">Factory Method</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Factory Method pattern when
|
||||
* a class can't anticipate the class of objects it must create
|
||||
@ -153,7 +153,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="prototype">Prototype</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Prototype pattern when a system should be independent of how its products are created, composed and represented; and
|
||||
* when the classes to instantiate are specified at run-time, for example, by dynamic loading; or
|
||||
@ -166,7 +166,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="singleton">Singleton</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Ensure a class only has one instance, and provide a global point of access to it.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Singleton pattern when
|
||||
* there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point
|
||||
@ -183,7 +183,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="adapter">Adapter</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Convert the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Adapter pattern when
|
||||
* you want to use an existing class, and its interface does not match the one you need
|
||||
@ -197,7 +197,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
**Intent:** Decouple an abstraction from its implementation so that the two can vary independently.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Bridge pattern when
|
||||
* you want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time.
|
||||
@ -209,7 +209,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="composite">Composite</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Composite pattern when
|
||||
* you want to represent part-whole hierarchies of objects
|
||||
@ -222,7 +222,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="decorator">Decorator</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use Decorator
|
||||
* to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects
|
||||
@ -232,7 +232,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="facade">Facade</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Facade pattern when
|
||||
* you want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade.
|
||||
@ -242,7 +242,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="flyweight">Flyweight</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Use sharing to support large numbers of fine-grained objects efficiently.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** The Flyweight pattern's effectiveness depends heavily on how and where it's used. Apply the Flyweight pattern when all of the following are true
|
||||
* an application uses a large number of objects
|
||||
@ -257,7 +257,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="proxy">Proxy</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Provide a surrogate or placeholder for another object to control access to it.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Proxy is applicable whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer. Here are several common situations in which the Proxy pattern is applicable
|
||||
|
||||
@ -280,7 +280,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="service-locator">Service Locator</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Encapsulate the processes involved in obtaining a service with a strong abstraction layer.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** The service locator pattern is applicable whenever we want to locate/fetch various services using JNDI which, typically, is a redundant and expensive lookup. The service Locator pattern addresses this expensive lookup by making use of caching techniques ie. for the very first time a particular service is requested, the service Locator looks up in JNDI, fetched the relavant service and then finally caches this service object. Now, further lookups of the same service via Service Locator is done in its cache which improves the performance of application to great extent.
|
||||
|
||||
@ -293,7 +293,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="chain-of-responsibility">Chain of responsibility</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use Chain of Responsibility when
|
||||
* more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically
|
||||
@ -307,7 +307,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="command">Command</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Command pattern when you want to
|
||||
|
||||
@ -329,7 +329,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="interpreter">Interpreter</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Interpreter pattern when there is a language to interpret, and you can represent statements in the language as abstract syntax trees. The Interpreter pattern works best when
|
||||
* the grammar is simple. For complex grammars, the class hierarchy for the grammar becomes large and unmanageable. Tools such as parser generators are a better alternative in such cases. They can interpret expressions without building abstract syntax trees, which can save space and possibly time
|
||||
@ -338,7 +338,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="iterator">Iterator</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Iterator pattern
|
||||
* to access an aggregate object's contents without exposing its internal representation
|
||||
@ -351,7 +351,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="mediator">Mediator</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Mediator pattern when
|
||||
* a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand
|
||||
@ -361,7 +361,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="memento">Memento</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Memento pattern when
|
||||
* a snapshot of an object's state must be saved so that it can be restored to that state later, and
|
||||
@ -373,7 +373,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="observer">Observer</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Observer pattern in any of the following situations
|
||||
|
||||
@ -391,7 +391,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="state">State</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the State pattern in either of the following cases
|
||||
* an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
|
||||
@ -400,7 +400,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="strategy">Strategy</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Strategy pattern when
|
||||
* many related classes differ only in their behavior. Strategies provide a way to configure a class either one of many behaviors
|
||||
@ -411,7 +411,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="template-method">Template method</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** The Template Method pattern should be used
|
||||
* to implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary
|
||||
@ -421,7 +421,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="visitor">Visitor</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Visitor pattern when
|
||||
* an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes
|
||||
@ -434,7 +434,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="model-view-presenter">Model-View-Presenter</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Apply a "Separation of Concerns" principle in a way that allows developers to build and test user interfaces.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Model-View-Presenter in any of the following situations
|
||||
* when you want to improve the "Separation of Concerns" principle in presentation logic
|
||||
@ -443,7 +443,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="dao">Data Access Object</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Object provides an abstract interface to some type of database or other persistence mechanism.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Data Access Object in any of the following situations
|
||||
* when you want to consolidate how the data layer is accessed
|
||||
@ -452,7 +452,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="double-checked-locking">Double Checked Locking</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Reduce the overhead of acquiring a lock by first testing the locking criterion (the "lock hint") without actually acquiring the lock. Only if the locking criterion check indicates that locking is required does the actual locking logic proceed.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Double Checked Locking pattern when
|
||||
* there is a concurrent access in object creation, e.g. singleton, where you want to create single instance of the same class and checking if it's null or not maybe not be enough when there are two or more threads that checks if instance is null or not.
|
||||
@ -461,7 +461,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="servant">Servant</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Servant is used for providing some behavior to a group of classes. Instead of defining that behavior in each class - or when we cannot factor out this behavior in the common parent class - it is defined once in the Servant.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Servant pattern when
|
||||
* When we want some objects to perform a common action and don't want to define this action as a method in every class.
|
||||
@ -469,7 +469,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="null-object">Null Object</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** In most object-oriented languages, such as Java or C#, references may be null. These references need to be checked to ensure they are not null before invoking any methods, because methods typically cannot be invoked on null references. Instead of using a null reference to convey absence of an object (for instance, a non-existent customer), one uses an object which implements the expected interface, but whose method body is empty. The advantage of this approach over a working default implementation is that a Null Object is very predictable and has no side effects: it does nothing.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Null Object pattern when
|
||||
* You want to avoid explicit null checks and keep the algorithm elegant and easy to read.
|
||||
@ -477,7 +477,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="event-aggregator">Event Aggregator</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** A system with lots of objects can lead to complexities when a client wants to subscribe to events. The client has to find and register for each object individually, if each object has multiple events then each event requires a separate subscription. An Event Aggregator acts as a single source of events for many objects. It registers for all the events of the many objects allowing clients to register with just the aggregator.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Event Aggregator pattern when
|
||||
* Event Aggregator is a good choice when you have lots of objects that are potential event sources. Rather than have the observer deal with registering with them all, you can centralize the registration logic to the Event Aggregator. As well as simplifying registration, a Event Aggregator also simplifies the memory management issues in using observers.
|
||||
@ -485,7 +485,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="callback">Callback</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Callback is a piece of executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at some convenient time.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Callback pattern when
|
||||
* When some arbitrary synchronous or asynchronous action must be performed after execution of some defined activity.
|
||||
@ -496,7 +496,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="intercepting-filter">Intercepting Filter</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Provide pluggable filters to conduct necessary pre-processing and post-processing to requests from a client to a target
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Intercepting Filter pattern when
|
||||
* a system uses pre-processing or post-processing requests
|
||||
@ -506,7 +506,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="execute-around">Execute Around</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Execute Around idiom frees the user from certain actions that should always be executed before and after the business method. A good example of this is resource allocation and deallocation leaving the user to specify only what to do with the resource.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Execute Around idiom when
|
||||
* You use an API that requires methods to be called in pairs such as open/close or allocate/deallocate.
|
||||
@ -514,7 +514,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="property">Property</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Create hierarchy of objects and new objects using already existing objects as parents.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Property pattern when
|
||||
* when you like to have objects with dynamic set of fields and prototype inheritance
|
||||
@ -525,7 +525,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="poison-pill">Poison Pill</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Poison Pill is known predefined data item that allows to provide graceful shutdown for separate distributed consumption process.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Poison Pill idiom when
|
||||
* need to send signal from one thread/process to another to terminate
|
||||
@ -536,7 +536,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
## <a name="lazy-loading">Lazy Loading</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Lazy loading is a design pattern commonly used to defer initialization of an object until the point at which it is needed. It can contribute to efficiency in the program's operation if properly and appropriately used.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Lazy Loading idiom when
|
||||
* eager loading is expensive or the object to be loaded might not be needed at all
|
||||
@ -548,7 +548,7 @@ A programming idiom is a means of expressing a recurring construct in one or mor
|
||||
**Intent:** Service Layer is an abstraction over domain logic. Typically applications require multiple kinds of interfaces to the data
|
||||
they store and logic they implement: data loaders, user interfaces, integration gateways, and others. Despite their different purposes, these interfaces often need common interactions with the application to access and manipulate its data and invoke its business logic. The Service Layer fulfills this role.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Service Layer pattern when
|
||||
* you want to encapsulate domain logic under API
|
||||
@ -559,7 +559,7 @@ they store and logic they implement: data loaders, user interfaces, integration
|
||||
candidate object that it is matched against. As well as its usefulness in selection, it is also valuable for
|
||||
validation and for building to order
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Specification pattern when
|
||||
* You need to select a subset of objects based on some criteria, and to refresh the selection at various times
|
||||
@ -568,7 +568,7 @@ validation and for building to order
|
||||
## <a name="tolerant-reader">Tolerant Reader</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Tolerant Reader is an integration pattern that helps creating robust communication systems. The idea is to be as tolerant as possible when reading data from another service. This way, when the communication schema changes, the readers must not break.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Tolerant Reader pattern when
|
||||
* The communication schema can evolve and change and yet the receiving side should not break
|
||||
@ -576,7 +576,7 @@ validation and for building to order
|
||||
## <a name="model-view-controller">Model-View-Controller</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Separate the user interface into three interconnected components: the model, the view and the controller. Let the model manage the data, the view display the data and the controller mediate updating the data and redrawing the display.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Model-View-Controller pattern when
|
||||
* you want to clearly separate the domain data from its user interface representation
|
||||
@ -584,7 +584,7 @@ validation and for building to order
|
||||
## <a name="flux">Flux</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Flux eschews MVC in favor of a unidirectional data flow. When a user interacts with a view, the view propagates an action through a central dispatcher, to the various stores that hold the application's data and business logic, which updates all of the views that are affected.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Flux pattern when
|
||||
* You want to focus on creating explicit and understandable update paths for your application's data, which makes tracing changes during development simpler and makes bugs easier to track down and fix.
|
||||
@ -592,7 +592,7 @@ validation and for building to order
|
||||
## <a name="double-dispatch">Double Dispatch</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Double Dispatch pattern is a way to create maintainable dynamic behavior based on receiver and parameter types.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Double Dispatch pattern when
|
||||
* The dynamic behavior is not defined only based on receiving object's type but also on the receiving method's parameter type.
|
||||
@ -603,7 +603,7 @@ validation and for building to order
|
||||
## <a name="multiton">Multiton</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Ensure a class only has limited number of instances, and provide a global point of access to them.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Multiton pattern when
|
||||
* there must be specific number of instances of a class, and they must be accessible to clients from a well-known access point
|
||||
@ -611,7 +611,7 @@ validation and for building to order
|
||||
## <a name="resource-acquisition-is-initialization">Resource Acquisition Is Initialization</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Resource Acquisition Is Initialization pattern can be used to implement exception safe resource management.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Resource Acquisition Is Initialization pattern when
|
||||
* You have resources that must be closed in every condition
|
||||
@ -619,7 +619,7 @@ validation and for building to order
|
||||
## <a name="thread-pool">Thread Pool</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** It is often the case that tasks to be executed are short-lived and the number of tasks is large. Creating a new thread for each task would make the system spend more time creating and destroying the threads than executing the actual tasks. Thread Pool solves this problem by reusing existing threads and eliminating the latency of creating new threads.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Thread Pool pattern when
|
||||
* You have a large number of short-lived tasks to be executed in parallel
|
||||
@ -627,7 +627,7 @@ validation and for building to order
|
||||
## <a name="async-method-invocation">Async Method Invocation</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Asynchronous method invocation is pattern where the calling thread is not blocked while waiting results of tasks. The pattern provides parallel processing of multiple independent tasks and retrieving the results via callbacks or waiting until everything is done.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use async method invocation pattern when
|
||||
* You have multiple independent tasks that can run in parallel
|
||||
@ -641,7 +641,7 @@ validation and for building to order
|
||||
## <a name="private-class-data">Private Class Data</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Private Class Data design pattern seeks to reduce exposure of attributes by limiting their visibility. It reduces the number of class attributes by encapsulating them in single Data object.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Private Class Data pattern when
|
||||
* You want to prevent write access to class data members
|
||||
@ -649,7 +649,7 @@ validation and for building to order
|
||||
## <a name="object-pool">Object Pool</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** When objects are expensive to create and they are needed only for short periods of time it is advantageous to utilize the Object Pool pattern. The Object Pool provides a cache for instantiated objects tracking which ones are in use and which are available.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Object Pool pattern when
|
||||
* The objects are expensive to create (allocation cost)
|
||||
@ -658,7 +658,7 @@ validation and for building to order
|
||||
## <a name="dependency-injection">Dependency Injection</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Dependency Injection is a software design pattern in which one or more dependencies (or services) are injected, or passed by reference, into a dependent object (or client) and are made part of the client's state. The pattern separates the creation of a client's dependencies from its own behavior, which allows program designs to be loosely coupled and to follow the inversion of control and single responsibility principles.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Dependency Injection pattern when
|
||||
* When you need to remove knowledge of concrete implementation from object
|
||||
@ -667,7 +667,7 @@ validation and for building to order
|
||||
## <a name="naked-objects">Naked Objects</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** The Naked Objects architectural pattern is well suited for rapid prototyping. Using the pattern, you only need to write the domain objects, everything else is autogenerated by the framework.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Naked Objects pattern when
|
||||
* You are prototyping and need fast development cycle
|
||||
@ -680,7 +680,7 @@ validation and for building to order
|
||||
## <a name="front-controller">Front Controller</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Introduce a common handler for all requests for a web site. This way we can encapsulate common functionality such as security, internationalization, routing and logging in a single place.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Front Controller pattern when
|
||||
* you want to encapsulate common request handling functionality in single place
|
||||
@ -693,7 +693,7 @@ validation and for building to order
|
||||
## <a name="repository">Repository</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** Repository layer is added between the domain and data mapping layers to isolate domain objects from details of the database access code and to minimize scattering and duplication of query code. The Repository pattern is especially useful in systems where number of domain classes is large or heavy querying is utilized.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Repository pattern when
|
||||
* the number of domain objects is large
|
||||
@ -707,7 +707,7 @@ validation and for building to order
|
||||
## <a name="business-delegate">Business Delegate</a> [↑](#list-of-design-patterns)
|
||||
**Intent:** The Business Delegate pattern adds an abstraction layer between presentation and business tiers. By using the pattern we gain loose coupling between the tiers and encapsulate knowledge about how to locate, connect to, and interact with the business objects that make up the application.
|
||||
|
||||
|
||||
|
||||
|
||||
**Applicability:** Use the Business Delegate pattern when
|
||||
* you want loose couping between presentation and business tiers
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user