Continuing with our programming course this time we will introduce patterns arise from the need to always have available a good design that we can extend its functionality without having to change everything we did or having to put things violate our basic design rules .
Christopher Alexander known for his work A Pattern Language. Towns, Buildings, Construction said in 1977 that:
Each pattern describes a problem that recurs again and again in our environment, and describes the core of the solution to this problem, so that this solution can be used millions of times, but always slightly differently.
That is, it raises a number of patterns that serve to solve some specific problems . We must be clear that:
- A software pattern provides a general outline.
- It is we who must implement it, usually the language does not give us a prototype for use.
- The patterns used on certain occasions, that the software works and is efficient not have to be based on one or more patterns. Never should stick patterns "to shoehorn" or use them to solve trivial problems.
Employers can cater to different classifications among which are:
- Architectural.
- Design.
- Focused on the code or deployment patterns (unique to a programming language).
We we will focus on design patterns , namely design patterns linked to static languages such as Java. We are interested in these types of patterns that are at an intermediate point between the architectural and implementation, gives us more variety of languages and a degree of flexibility to migrate from one platform to another.
For all this we talked we will base all our items in the book Design Patterns or GoF (Gang of Four, alluding to his four authors). It is the classic book par excellence of design patterns. In can see a catalog of 23 patterns divided into three areas: creation, structural and behavioral .
Our first pattern
The first pattern, not for its use unless its simplicity is the Singleton pattern . Imagine that we want to ensure that a class has only one instance, namely, how could guarantee that such class exists only a single object? Imagine that we have a Logger class that can display trace messages in an application.
- We must avoid that it can call new from outside the class. Private (or protected) the class constructor do.public class Logger {
private Logger () { // ... }
} - Who creates this single instance? necessarily have to be from within the class.public class Logger {
private static final Logger instance = new Logger (); private Logger () { // ... }
} - How to access the single instance from outside the class? You have to provide an access point to that single instance.public class Logger {
private static final Logger instance = new Logger (); private Logger () { // ... } public static Logger getInstance () { return instance; }
}
This we have done is the Singleton pattern. We must be clear that:
- Being able to access them from anywhere in the application behave as global variables.
- They are singletons does not mean we have to get the only instance necessarily through its static method getInstance () . We can also pass them as parameters to client classes that need it , as would any other object.
So far today's article, ? what if we want two types of Logger introduce a first variant: now comes the need we have two types of logger (console and fchero), maintaining the same restriction that only one single object. How can we fix it?
0 comments:
Post a Comment