DEV Community: Majid Abarghooei

A seemingly simple question: what are design patterns?

Majid Abarghooei — Sat, 18 Feb 2023 17:28:31 +0000

In the software industry, there are a range of topics you hear debates about in almost every company. I believe the
design patterns story is one of them. You can find countless posts, articles, and Quora/Stackoverflow answers acting
for or against them. For instance, the other day, I came across this old Quora question:

"Why do programmers talk less about design patterns now? Which patterns (if any) are still valuable?"

The author meant object-oriented design patterns, or the 23 patterns introduced in the Gang of Four book,
and most of the people who answered the question assumed that this was the case. However, 'the design pattern' is a term
that some people use instead of 'object-oriented design patterns'-so don't get shocked when you come across the strange
statement: "design patterns are dead".

In this article, we're going to answer a seemingly simple question: what is a design pattern? Answering this could help
us determine what we're talking about while we're discussing or applying a particular design pattern.

What do design patterns mean to you?

Let's put all the clichés aside and focus on what comes to your mind when thinking about the design pattern concept.
Is it a rule that shouldn't be broken? Is it a wordy academic recommendation? Is it another design constraint? Or is it
something you only need to know to pass job interviews?

To me, it's like a whispering sound in my head preventing me from reinventing the wheel. You may have experienced the
urge to start the design/build process immediately after facing a problem and created your own solution-if so,
welcome to the club. But in this scenario, if a solution already exists, creating another one just takes up unnecessary
time and effort. Although the urge to jump straight into creating your own solution might settle over time, I believe
that one of the crucial tools to help us overcome this urge is the design pattern concept.

A design pattern reminds me that many software engineers have already faced the same problem before and solved it in a
particular way for several reasons. There's probably a rationale behind it and it gives us the ability to see the
problem from a different perspective, even if we don't intend to follow that pattern.

Let's look at a paragraph from the GoF famous book's introduction:

"We all know the value of design experience. How many times have you had design déjà vu-that feeling that you've
solved a problem before but not knowing exactly where or how? If you could remember the details of the previous
problem and how you solved it, then you could reuse the experience instead of rediscovering it."

More or less, we have experienced something similar: solving a common design problem several times when we couldn't
remember the previous solution. Through reusing solutions to solve recurring problems, design patterns save time and
effort, both of which can be directed elsewhere.

Now let's dive into some fundamental concepts and definitions.

What do patterns mean?

What is a pattern? The pattern concept is not something specific to our industry. Other disciplines and industries such
as architecture, economics, etc. also apply this concept. Let's see the pattern definitions by Christopher Alexander,
a leading authority in architecture:

"Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution." (Alexander, 1979)

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." (Alexander, 1977)

Now let's see what patterns mean in the software industry:

"A pattern for software architecture describes a particular recurring design problem that arises in specific design
contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing
its constituent components, their responsibilities and relationships, and the ways in which they collaborate."
(BMRSS, 96)

Based on the above definitions, we can consider a pattern as a triad of context, problem, and solution combined with
the relationship among them. However, it's a broad concept and can be applied to different scales and abstraction
levels, from designing a whole software system, to solving a design problem belonging to a particular programming language.

The different pattern categories

Patterns are classified based on their scale and abstraction level:

Architectural patterns
Design patterns
Idioms

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2af9n68tns2b5gvzmxix.jpeg)

Architectural patterns focus on a whole software system structure, its subsystems, the different broad components and
how they fit together. These patterns are at a high level of abstraction. For instance, they don't care what the
programming language is or what framework is being used.

"An architectural pattern expresses a fundamental structural organisation schema for software systems. It provides a
set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organising the
relationships between them." (BMRSS, 96)

On the other hand, we have some patterns in the lowest level of abstraction called idioms which address both design and
implementation. Idioms are language-specific meaning that an idiom in language A is irrelevant in language B.

"An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular
aspects of components or the relationships between them using the features of the given language." (BMRSS, 96)

However, there are still some other patterns that occur between those mentioned above regarding the scale and
abstraction level, that's where design patterns come in.

A closer look at design patterns

So let's review the definition of the remaining category:

"A design pattern provides a scheme for refining the subsystems or components of a software system, or the
relationships between them. It describes a commonly-recurring structure of communicating components that solves a
general design problem within a particular context." (BMRSS, 96)

Design patterns are medium-scale, meaning they're neither highly abstract like architectural patterns, nor coupled to
programming languages, like idioms. Applying design patterns doesn't affect the software system structure, but it does
impact the subsystems' architecture and its smaller components.

Now, let's discuss the following statement (extracted from the same reference)
containing a crucial fact about design patterns:

"They tend to be independent of a particular programming language or programming paradigm." (BMRSS, 96)

According to the pattern category we previously addressed in this article, we'd better rephrase it like this:

"They are independent of a particular programming language but often (not always) dependent on a programming paradigm."

The first part of the statement is clear: if a pattern is dependent on a specific programming language, it would be in
the idioms category. Regarding the second part, design patterns are attempts to solve common problems that occur in
programming paradigms. They're likely responses to the deficiencies of paradigms. For instance, there are 23
object-oriented design patterns described in the GoF book, most of which are not genuine concerns in the functional
programming paradigm. But the opposite is also true as the design patterns have different contexts.

As you can see in the following image,
different paradigms could share design patterns, but we're not going to address this topic as it's beyond the scope of
this article.

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u299fc7tzxysuvjmw7u1.jpeg)

Analysing a famous statement

With the previous sections in mind, let's have a quick look at a statement you may encounter when you simply google
design patterns:

Functional languages don't need design patterns.

You can find a sample here. This statement is wrong as it implies design patterns only belong to the object-oriented
paradigm. However, design patterns are a concept that can be present in both functional programming paradigm and
object-oriented paradigm. The design patterns may just be specific to the problems and demands of the host paradigm.
For instance, the functional programming paradigm has design patterns specific to its context.

Moreover, as we discussed in the previous sections, different paradigms have different contexts and consequently
encounter different problems. We should not expect the design patterns of paradigm B to solve the problems of paradigm A.

A quick recap

Design patterns, similar to other pattern types, try to solve recurring problems of a particular context.

They're language-independent but mostly paradigm coupled.
Being medium-scale, they are not as abstract as architectural patterns.
Their application doesn't affect the fundamental architecture of the software system but influences the subsystems' architecture.
Last but not least, they're (all types of patterns) means of preventing us from reinventing the wheel.

From my perspective, design patterns are not strict laws to constrain our design. They're neither fixed nor flawless as
they could evolve and get better or even fade away, but the pattern concept still exists. To follow patterns is like a
mindset that helps us figure out that there could be a better solution.

How to Make Your Reviewer Cry Using Java Optional

Majid Abarghooei — Fri, 25 Dec 2020 15:10:01 +0000

I think code review is one of the best sources of inspiration. I see it as an opportunity to learn new things from other software developers sending pull/merge requests. Moreover, sometimes you may need to study a specific subject with more details regarding the under review code. Usually, this process leads to a more profound knowledge of that domain. However, there's still another fact about code review: after a while, you face some common mistakes. Recently, I reviewed a feature in which I saw an Optional pitfall. Honestly, I had seen that issue several times in different merge requests sent by several developers (from beginners to experienced ones).

I know that there are tonnes of articles regarding Java Optional some of which are quite useful like this one (although I have arguments against some of the cases mentioned in the article) by Anghel Leonard, the author of Java Coding Problems. I don't want to repeat all of the contents you can simply find by googling. I intend to talk about some of the most common and less addressed pitfalls regarding Optional usage.

What is Optional?

Before diving into the main subject, let’s review some definitions and see what Optional is. As a Java developer, you should have encountered the infamous NullPointerException that occurs when you're going to access a null reference. With a quick search, you can find thousands of memes and jokes about null references in Java (and other languages as well). Optional came in to play in Java 8 to help programmers get rid of all of the problems caused by null references. Have a look at this article, from Oracle technical resources, to read more about the motivation of Optional existence in Java.

Now we are going to have a look at Optional’s JavaDoc and check the provided definition.

A container object which may or may not contain a non-null value.

Following this introduction, as an API note, there is an answer to the first question that may come to mind: “when should we use Optional?”

Optional is primarily intended for use as a method return type where there is a clear need to represent "no result," and where using null is likely to cause errors. A variable whose type is Optional should never itself be null; it should always point to an Optional instance.

So we can extract the following points from the JavaDoc descriptions:

Optional is a container object.
It may not contain a non-null value.
It is mainly used as a return type when using null is troublesome.
The variable with the Optional type should not be null.

Keeping in mind these subtle points, you can simply spot most of the Optional related code smells. Now, it’s time to go through the four most common Optional pitfalls.

Old Fashioned Exception Handling

One of the most common mistakes I usually face in code reviews is using an if/else block to handle the circumstances that the Optional variable doesn't contain a non-null value (as previously mentioned in the Optional
definition). Check this out:

Optional<User> userOptional = userDao.findByCellNumber(cellNumber);

if (!userOptional.isPresent()) {
    throw new UserNotFoundException("...");
} else {
    User user = userOptional.get();
    //...
}

Suppose that you intend to find a user by a specific cell number from the database. Then you receive an Optional variable from the corresponding DAO class. Now, you want to check if there's a user with the cell number you have provided. What's wrong with the above code? Doesn't work? Honestly, it works like a charm. However, it's not elegant; it's something like twisting wood screws with a wrench. Now, check the following code snippet:

User user = userDao.findByCellNumber(cellNumber).orElseThrow(UserNotFoundException::new);

Using the orElseThrow, you can do the same thing more oncisely and elegantly without any need to get method.
You can also use its no-argument version of orElseThrow introduced in Java 10.

orElse and orElseGet Misuse

The second common pitfall may emerge while using orElse or orElseGet. It seems these methods do the same thing; however, there is a significant difference not that fancy like the previous one. Let’s have a look at their signatures and corresponding Javadoc:

public T orElse(T other)
//If a value is present, returns the value, otherwise returns other.
//Parameters:
//other - the value to be returned, if no value is present. May be null.
//Returns:
//the value, if present, otherwise other

public T orElseGet(Supplier<? extends T> supplier)
//If a value is present, returns the value, otherwise returns the result produced by the supplying function.
//Parameters:
//supplier - the supplying function that produces a value to be returned
//Returns:
//the value, if present, otherwise the result produced by the supplying function
//Throws:
//NullPointerException - if no value is present and the supplying function is null

Regarding the above signatures, the first difference is crystal clear: orElse accepts a generic object as an argument; however, orElseGet accepts a supplier function that produces a value. So what? You are right; it may seem negligible. However, it's not that easy. Let’s check the following sample:

Optional<Integer> number = Optional.of(10);
System.out.println("The number is: " + number.orElseGet(() -> alternativeNumber()));

private static Integer alternativeNumber() {
    int number = 747;
    System.out.println("The alternative number is: " + number);
    return number;
}

What's the output of the above code snippet? As you see, the number is an Optional variable initiated with the value of 10. So we don't expect orElseGet to do something. Here's the output:

The number is: 10

That's super easy, right? Now check this one:

Optional<Integer> number = Optional.of(10);
System.out.println("The number is: " + number.orElse(alternativeNumber()));

private static Integer alternativeNumber() {
    int number = 747;
    System.out.println("The alternative number is: " + number);
    return number;
}

Everything is the same as the previous example except the second line in which we have used orElse instead of orElseGet. We don't expect the orElse to do something yet because our number has a value. Just stop here and guess the output! Same as the previous one? No! The output is:

The alternative number is: 747
The number is: 10

The orElse’s parameter always gets evaluated; even if the Optional variable contains a value. However, the supplier method passed to the orElseGet only gets evaluated when the Optional variable is empty. That’s why the second output is different. Note that this could affect the performance drastically in cases you use orElse and pass it a complex method.

Using orElse(null)

The other common mistake I usually encounter in code reviews is somehow philosophical; that's using orElse(null). What’s wrong with it? To find the answer, let's review the motivation of Optional existence. As I previously mentioned, Optional exists to help you not to face the problems caused by null references such as NullPointerException. We also talked about the orElse method in the previous section. Now, put these two parts together. Does it make any sense to ask our Optional object to return null if it’s empty and doesn’t contain a value?

The orElse method is a proper way to return an alternative value in the cases the Optional object is empty. Returning null, questions the usage of Optional. You may prefer to use a null reference instead of Optional; it's ok, although I never recommend it. However, mixing these two ideas is somehow misleading. At the first glance, the code seems null safe; however, you may face null reference issues, sooner or later.

Returning null in a method with Optional return type

Before describing the last and weirdest case, let’s see how it happens. Let’s get back to the previous example. Suppose that the findByCellNumber is something like this:

public Optional<User> findByCellNumber(String cellNumber) {
    //some code here
    if (someCondition) {
        return null;
    }
    //some code here
}

As you see, this method returns null in a specific condition. Suppose that the database is down and the author handles the exception and returns null in this situation (BAD PRACTICE, don’t try this at home). So, there are some circumstances where you try to get the Optional value but you encounter a NullPointerException. Look at this:

User user = userDao.findByCellNumber(cellNumber).orElseThrow(UserNotFoundException::new);

We expect the method to return an Optional then we use orElseThrow; however, it returns null. So, our try leads to an exception. How to avoid this issue? This is the point: as previously mentioned, an Optional MUST not be null.

Quick Recap

Each explicit call to get method of an Optional variable could be a code smell.
orElse and orElseGet are not equivalent.
Optional was added to Java to help developers avoid null references. So each return null or orElse(null) presence in your code using Optional variables is a code smell.

Keeping in mind these points, you can prevent most of the common pitfalls while using Optional.

Sluggish Spring Boot Tests Riddle

Majid Abarghooei — Fri, 23 Oct 2020 20:02:45 +0000

Most of us have faced beliefs that go unquestioned. Such ideas can vary from small daily matters such as grocery shopping to something as serious as religious matters. In my case, it was a professional belief, specifically whether or not integration tests are too slow.

There was a belief in our squad (and our chapter as well) that integration tests were slow and this belief made us not put this issue in our technical debts backlog and we all accepted it as a fact. It continued until the build time in some microservices exceeded 10 minutes and teammates started complaining about them. The first reaction was avoiding integration tests as much as possible and using unit tests instead. I know that it is not a wise decision against which there are many arguments, but It was the decision that the team made. In this post, we will see how this issue got resolved and the build time in our microservices decreased to half.

Finally, over a weekend, I decided to follow this issue and find an answer to the question: Why are our integration tests that slow? I started with writing down all the things I was skeptical about but my mind was just obsessed with @SpringBootTest.

Following the first suspicion

Whenever our tests were running, I saw the Spring logo showing up several times. I thought that @SpringBootTest loaded the full application context per each test class. After a ten-minute search, I realized that all my assumptions were wrong. I found the point in the Spring docs:

Once the TestContext framework loads an ApplicationContext (or WebApplicationContext) for a test, that context will be cached and reused for all subsequent tests that declare the same unique context configuration within the same test suite.

So why did it still load the context per each test class? Actually, it did not. I got this by counting the context loads by a specific piece of text in the log (which is repeating every time the Spring loads the application context). Something like this:

mvn clean install > build-log.txt

grep "The following profiles are active: test" log.txt| wc -l

The result was 16 while we had 46 integration test classes in the codebase. It means that it did not load the context per each test class but why only 16 times?

Digging into the test classes

After getting this weird result from counting the context loads, I checked all of the test classes one by one to find a clue. I realized that all of the integration test classes were annotated by @TestPropertySource to load one or more specific property files. I also had another strange finding in this investigation: MockBean and SpyBean annotations in integration tests. Not only I had philosophical issues with using these annotations in integration tests but was it screaming that: "Hey dude, there’s a code smell here".

I started the second round of searching and the same as the previous one, I managed to find tonnes of useful articles and blog posts related to the context and some clues after about only ten minutes. I found this helpful blog post by José Carlos Valero Sánchez about optimizing Spring boot integration tests and this one that its author has had the same journey as mine.

By reading these articles and the same ones, I realized that there are some pitfalls in integration tests that prevent the Spring from reusing the loaded application context in integration tests. Here are the most important ones:

Using @MockBean and @SpyBean
Using @DirtiesContext
Careless use of profiles in integration tests
Careless use of @TestPropertySource

I will review all of these items in a separate blog post in detail. Now, let’s see how I boosted up our integration tests by two minor actions.

Optimizing the integration tests

As I previously mentioned, there were two pitfalls in our integration test classes. The first one was annotating all of the integration tests with @TestPropertySource. I took a quick look at them and found out there were different combinations of property files used for each class. For example:

@TestPropertySource({
    "classpath:x.properties",
    "classpath:y.properties"
})
public class TestOne{
    //...
}

@TestPropertySource({
    "classpath:z.properties",
    "classpath:y.properties"
})
public class TestTwo{
    //...
}

@TestPropertySource({
    "classpath:x.properties",
    "classpath:z.properties"
})
public class TestThree{
    //...
}

@TestPropertySource({
    "classpath:x.properties",
    "classpath:z.properties"
})
public class TestFour{
    //...
}

In this situation, Spring loads the context per each unique combination of property files. For instance, in the previous sample, it loads the context three times because x and z got repeated two times so the Spring can reuse the context for both of them.

So I decided to eliminate the TestPropertySource annotation from all of the integration test classes and aggregate them in an abstract class that all of them extend. Here is the new style of the test classes:

@TestPropertySource({
    "classpath:x.properties",
    "classpath:y.properties",
    "classpath:z.properties"
})
public abstract class AbstractTes{
    //...
}

public class TestX extends AbstractTest{
    //...
}

Now, in this sample, it only loads the context once. I did something like this in the codebase and counted the context loads again. The result was promising: the number of context loads decreased to 2 (from 16). Note that, for example, if you have a property called database.url both in x.properties and z.properties, the second one overrides the first one.

I got through the remaining test classes. Guess what? All of them contained either @MockBean or @SpyBean. As I previously mentioned, in a separate blog post I will address the usage of these fancy annotations and the issues they may cause in integration tests.

Lesson Learned

The whole process took about 3 to 4 hours. Consequently, the build time decreased from 10 to 4 minutes on Jenkins. It means that sometimes we could save plenty of time by investing some hours on following such issues that waste considerable amounts of time in the long term.

I will address the performance issues in integration tests in a separate blog post soon. I would be grateful if you share your comments.