Reactions about software design patterns

In software development, there are a lot of common issues that usually arise in different parts of the process, not only in development, but also when we are working with interfaces design, for instance. Software design patterns form the basis to look for specific solutions to common problems.

Thus, a design pattern should be seen as a workaround for a design issue. These solutions must fulfill some characteristics such as a tested effectiveness, as well as be reusable in order to apply them to multiple applications and environments, under different circumstances.

These are some of the goals of software design patterns:

• Provide reusable components to software systems design.
• Avoid unnecessary searches about known problems which have been already solved and tested before. 
• Establish a common way to solve problems among software developers.
• Set an standard design model.
• Make learning easier for rookie designers by taking in advantage the existing knowledge.

There are three main shorts of software design patterns:

- Creational patterns: focused on facing object creation in different situations.This pattern avoids possible design issues or an unnecessary complexity increasing.

- Structural patterns: Wikipedia defines structural patters as design patters that "ease the design by identifying a simple way to realize relationships between entities".

- Behavioral patterns: This kind of patters are related to the interactions between the objects in order to avoid dependencies and hard-coding. In contrast, we can get a more flexible communication between objects.

I am particularly interested in lazy evaluation, that is not recognized as an "official" design pattern. In fact, the design pattern is the lazy initialization, and according to Wikipedia, lazy evaluation is a "general treatment" of the lazy initialization.
Lazy evaluation is especially used in functional programming languages. It basically provide a mechanism that delays the evaluation of an expression until its value is needed, avoiding repeated evaluations. Thanks to lazy evaluation, the execution time of certain functions can be strongly reduced, as well as memory usage in some cases.

Eager evaluation (also called strict evaluation) is the opposite of lazy evaluation. This is the common evaluation way in most programming languages (operators such as +, -, *, /). However, there are expressions in eager languages that are evaluated in a lazy way; a simple if clause for instance (if X then Y, else Z).

For example, to implement lazy evaluation on Boolean expressions (also called "short-circuit evaluation") using Java, we can use these syntax: &&, ||, instead of the eager operators (&,|):

public boolean isTrue() {
    return exprA() || exprB();
}

The second expression (exprB()) will not be called if the first is true. The OR operation has the same behavior as the AND:

public boolean isTrue() {
    return exprA() && exprB();
}

The second expression (exprB()) will not be called if the first is false. So, it is clear that we can reduce the execution time by applying lazy evaluation whenever it is possible. But, there are also some disadvantages, because lazy evaluation can make a code difficult to understand when we have troubles or exceptions. It also makes debugging tasks more difficult to deal.