Java Reference
In-Depth Information
Such a diagram is followed by an implementation in Java showing
the simplest implementation. An example of the singleton pattern,
which will be described in later chapters, is shown in Figure 1-2.
Singleton
- instance: Singleton
And here is an example of its simplest implementation.
- Singleton ()
+ getInstance () : Singleton
public enum MySingletonEnum {
INSTANCE;
public void doSomethingInteresting(){}
}
FIGURE 1-2: The singleton
pattern class diagram
How Patterns Were Discovered and Why We Need Them
Design patterns have been a hot topic since the famous Gang of Four (GoF, made up of Erich Gamma,
Richard Helm, Ralph Johnson, and John Vlissides) wrote the topic Design Patterns: Elements of
Reusable Object‐Oriented Software , 1 i nally giving developers around the world tried and tested solu-
tions to the commonest software engineering problems. This important book describes various devel-
opment techniques and their pitfalls and provides 23 object‐oriented programming design patterns.
These patterns are divided into three categories: creational, structural, and behavioral.
But why? Why did we suddenly realize we needed design patterns so much?
The decision was not that sudden. Object‐oriented programming emerged in the 1980s, and several
languages that built on this new idea shortly followed. Smalltalk, C++, and Objective C are some of
the few languages that are still prevalent today. They have brought their own problems, though, and
unlike the development of procedural programming, this time the shift was too fast to see what was
working and what was not.
Although design patterns have solved many issues (such as spaghetti code) that software engineers
have with procedural programming languages like C and COBOL, object‐oriented languages have
introduced their own set of issues. C++ has advanced quickly, and because of its complexity, it has
driven many developers into i elds of bugs such as memory leaks, poor object design, unsafe use of
memory, and unmaintainable legacy code.
However, most of the problems developers have experienced have followed the same patterns,
and it's not beyond reason to suggest that someone somewhere has already solved the issues. Back
when object‐oriented programming emerged, it was still a pre‐Internet world, and it was hard to
share experiences with the masses. That's why it took a while until the GoF formed a collection of
patterns to well‐known recurring problems.
Patterns in the Real World
Design patterns are ini nitely useful and proven solutions to problems you will inevitably face. Not
only do they impart years of collective knowledge and experience, design patterns offer a good
vocabulary between developers and shine a light on many problems.
However, design patterns are not a magic wand; they do not offer an out‐of‐the‐box implementa-
tion like a framework or a tool set. Unnecessary use of design patterns, just because they sound cool
or you want to impress your boss, can result in a sophisticated and overly engineered system that
 
Search WWH ::




Custom Search