Singleton Pattern
"In software engineering, the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object (an implementation of the mathematical concept of singleton). This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects (say, five). Some consider it an anti-pattern, judging that it is overused, introduces unnecessary limitations in situations where a sole instance of a class is not actually required, and introduces global state into an application."
public class Singleton {
// Private constructor that prevents automatic creation of a public
private Singleton() {}
private static class SingletonHolder {
private static Singleton instance = new Singleton();
}public static Singleton getInstance() {
return SingletonHolder.instance;
}
}
______________________________________________
Facade Pattern
The facade pattern is a software engineering design pattern commonly used with Object-oriented programming. (The name is by analogy to an architectural facade.)
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can:
- make a software library easier to use and understand, since the facade has convenient methods for common tasks;
- make code that uses the library more readable, for the same reason;
- reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system;
- wrap a poorly-designed collection of APIs with a single well-designed API (as per task needs).
An Adapter is used when the wrapper must respect a particular interface and must support a polymorphic behavior. On the other hand, a facade is used when one wants an easier or simpler interface to work with.
______________________________________________
Mediator Pattern
(Example in the link)
- Partition a system into pieces or small objects.
- Centralize control to manipulate participating objects(a.k.a colleagues)
- Clarify the complex relationship by providing a board committee.
- Limit subclasses.
- Improve objects reusabilities.
- Simplify object protocols.
- The relationship between the control class and other participating classes is multidirectional.
Ingen kommentarer:
Send en kommentar