DEV Community: Barış Ayten

Design Patterns | Fundamentals

Barış Ayten — Sat, 13 May 2023 09:10:03 +0000

Hello Folks! 🖖🏼

I've decided to embark on a new article series, and I'm going to tackle Design Patterns. Combining the notes I've taken from the articles I've read and watched while learning Design Patterns, I've decided to create a perpetual resource on my blog.

I'm planning to divide this article series into four parts, where I'll delve into each category and pattern in detail, accompanied by examples. Throughout the examples, I'll be using Java as the programming language.

The article series will progress in the following order, as I anticipate:

Design Pattern Fundamentals
Creational Design Patterns
Structural Design Patterns
Behavioral Design Patterns

We'll start with this article to provide a nice introduction and gain a general overview and understanding of Design Pattern concepts. In the subsequent articles, we'll meticulously delve into each remaining part separately.

Without further ado, let's dive into our first topic! 🤘🏼

Design Patterns, in the realm of software development, hold a significant place as the cool-sounding name for a set of standardized software designs that developers employ to tackle recurring problems, create more flexible, sustainable, and reusable code in their projects.

These designs, comprising numerous different patterns, are categorized into three distinct groups based on their usage and purposes, as outlined below.

Let's now roughly delve into the realm of Creational Design Patterns, which will be one of the pillars of our article series, and try to grasp what they are all about.🎉

Creational Design Patterns

Creational Design Patterns encompass a category of design patterns that revolve around the process of creating new objects. In this category, the patterns focus on how an object can be created in a flexible and reusable manner.

“In software engineering, creational design patterns are design patterns that deal with **object creation mechanisms, trying to create objects in a manner suitable to the situation.* The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.”* (1)

We've covered it quite extensively in the previous lines, but if we were to highlight them in bullet points, these design patterns address the following concerns:

How objects are created.
Managing the processes involved in creating large and complex objects.
Defining the requirements during the creation of objects.
Determining which objects to use in the object's creation.

Within this category, we'll explore 6 different patterns. Now, let's take a quick peek at them.🧐

Singleton Pattern: It is used to design a class with only one instance.
Factory Method Pattern: It allows subclasses to use the interface of the parent class to create objects.
Abstract Factory Pattern: It enables the creation of objects in a group that are related to each other.
Builder Pattern: It allows the step-by-step construction of complex objects.
Prototype Pattern: It is used to create copies of objects.

As mentioned at the beginning of the article, we briefly covered each pattern. Now, let's take a look at our next category, Structural Design Patterns. 🐱‍🏍

Structural Design Patterns

The patterns within this category determine how the different components of software will:

How came together,
How be organized, and
How interact with each other.

These design patterns are in line with the principles of object-oriented programming (OOP) and help optimize the interaction between the various components of the software.

Structural design patterns explain **how to assemble objects and classes into larger structures, while keeping these structures flexible and efficient.** (2)

Structural Design Patterns allow for easier understanding and more convenient maintenance of the code and the resulting structure. These design patterns, especially during the development of large and complex software, provide developers with opportunities to better organize and reuse their code.

Within the Structural Pattern category, there are 7 different design patterns.

These include:

Adapter Pattern: It is a structural design pattern that enables two classes with different interfaces to work together harmoniously.
Bridge Pattern: It is a design pattern that separates the abstraction and implementation, allowing them to vary independently.
Composite Pattern: It is a design pattern that creates objects in a hierarchical structure, enabling operations to be performed on the entire structure instead of individually handling each object.
Decorator Pattern: It is a structural design pattern that dynamically adds new features to an existing object.
Facade Pattern: It is a design pattern that simplifies a complex system by providing an interface for clients to interact with, making it easier for clients to use the system.
Flyweight Pattern: It is a design pattern that prevents the repeated creation of similar objects, thereby improving system performance.
Proxy Pattern: It is a design pattern that acts as a substitute for an object and controls access to that object.

Up until now, we have gained some understanding about two different categories and the 12 design patterns within them. At least now we're not completely clueless! 😁

Now, let's take a look at our final guest of this article, Behavioral Design Patterns.

Behavioral Design Patterns

Our friends in this design pattern category actually have similar goals. They assist in organizing interactions and responsibilities among objects.

Let's dive into the various Behavioral Design Patterns and explore their roles.

Behavioral design patterns are concerned with algorithms and the assignment of responsibilities between objects. (3)

These patterns help make object behaviors more flexible and cohesive. They are used to facilitate easier maintenance and development of software.

Here are some important Behavioral Design Patterns:

Observer Pattern: Establishes a relationship between objects, enabling automatic updates to dependent objects when one object changes.
Command Pattern: Encapsulates a command-containing class, allowing separation of objects responsible for executing and parameterizing the command. This enables different ways of invoking and undoing the command.
Iterator Pattern: Provides an interface for accessing elements of a collection sequentially, ensuring the access method remains consistent even if the collection's structure changes.
Template Method Pattern: Defines the steps of a process and allows subclasses to implement these steps as desired.
Strategy Pattern: Encapsulates a class containing an algorithm, enabling different objects to apply the algorithm. This allows the algorithm to be applied in different ways and changed at runtime.
Chain of Responsibility Pattern: Creates a chain of objects where each object is responsible for handling a specific request. The request is passed along the chain until it is handled.
State Pattern: Used to manage an object's state and change its behavior based on the current state.
Interpreter Pattern: Provides an object structure for interpreting a specific part of a language and interpreting the data accordingly.
Mediator Pattern: Instead of direct communication between objects, it uses a mediator object to facilitate communication and maintain independence among objects.
Visitor Pattern: Provides an interface for accessing elements in an object structure and allows different objects to perform different operations on these elements.

These patterns contribute to creating more flexible and maintainable software systems by defining clear interactions and responsibilities among objects.

So far, let's summarize it. We have three different categories of patterns at our disposal. These are:

Creational
Structural
Behavioral

And each of these categories focuses on a different mechanism.

Creational Patterns deal with the creation of objects.
Structural Patterns address how objects will come together and be organized once they are created.
Behavioral Patterns allow us to make adjustments regarding interactions and responsibilities among objects.

Thank you for taking the time to read through it. If you notice any missing or incorrect points, please feel free to let me know, and I'll be happy to make the necessary corrections. I hope that the notes I have gathered here will be of some use to you and contribute to your work, even if it's in a small way

Thank you for taking the time to read this far. ♥

Happy Coding 🖖🏼

References

Design Patterns. https://sourcemaking.com/design_patterns (1),(2)
Tasarım Desenleri, https://yusufyilmazfr.gitbook.io/tasarim-desenleri-turkce-kaynak/tasarim-desenleri/tasarim-deseni-nedir

Method Overriding and Overloading in Java

Barış Ayten — Wed, 05 Apr 2023 00:00:00 +0000

Hello everyone 🤘🏼

In this article, we'll be taking a look at the concepts of method overloading and overriding in Java, which I believe are often forgotten and confused by beginners (at least I was 😁).

Before delving into these two concepts in detail, I'd like to briefly mention them. Method overriding is simply changing the functionality of a method without changing its signature, while method overloading is redefining a method with a different signature.

These two definitions may not make much sense yet because I have only mentioned them briefly and in a simplistic manner. Although this section consists of only two sentences that may seem meaningless for now, by the end of the article, they will have the power to summarize the entire article. 🙂

Before we dive into the topic fully, there is one tiny concept we need to learn and understand: The Method Signature. Method signatures consist of the name of a method and its method parameters. As shown in the image below, the signature of the method named justFun consists of its name "justFun" and its parameters int num1, int num2.

I believe we have clarified this simple and short concept. Now, let's dive into the main concepts of this article. 🚀

Method Overriding

Method overriding, in simple terms, refers to methods that have the same signature but perform different tasks. How does this situation arise?

Let's assume that we have a class named Animal with a method named eat(). Now, I have created another class named Dog, and I want it to inherit from the Animal class. When we perform the inheritance process, we would like to use the eat() method inherited from the super class in a way that is suitable for our subclass. Therefore, we change its functionality. In other words, we override the eat() method.🙂

Let's give an example!

class Animal{  
  public void eat(){System.out.println("eating...");}  
}  

//Overriding way
class Dog extends Animal{  
  public void eat(){System.out.println("eating bread...");}  
}

class Cat extends Animal{  
  public void eat(){System.out.println("eating fish...");}  
}

As we saw in the example, I did not touch the method signatures in any way. I did not change the method name or send a new parameter to that method... I just played with the internal dynamics of the method and added a completely different functionality.

Well, you may have a question like this in your mind🤔:

"What about the access modifiers of the methods we override? Do they have to be the same?"

Our answer to this question will be no. They do not have to be the same, but
the access modifier of the overriding method must be the same or less restrictive than the original method.

According to the restriction diagram in the image, if a protected method is to be overridden, its access modifier cannot be default or private. It can either remain protected or be made public. In short, when overriding a method, the access modifier in the subclass must be the same as or less restrictive than that in the superclass.

Another question that might come up is❓,

"Do the return types of the methods we override have to be the same? Can't I specify a different return type?"

Our answer to this question will be No 🙂. When overriding a method, the return type of the method must remain the same, along with the method signature. This is primarily based on Java's principle of type safety.

If a subclass could use a different return type while overriding methods of the superclass, it could lead to errors in places where the superclass is used.

However, there is an exception to this rule where the return type of the overridden method can be a co-variant return type. For example, suppose the return type of a superclass is Animal, and the return type of the subclass is Cat. While overriding the superclass method, the subclass can specify the return type as Cat. This way, the object returned by the subclass will not be of type Animal, but of a more specific subtype, which is Cat.

Another question that could arise is,

"Can I override every method?"

It may be the most fundamental question to ask. 🙂

Our answer to this question, unfortunately, will still be No. 😁

If the method to be overridden is:

final
static
private

then we cannot override these methods. This is because the nature of the override operation is based on inheritance. Methods with these three keywords cannot be inherited, so they cannot be overridden either.

However, sometimes a subclass can redefine a static method of the superclass. Some of us might have seen this situation before. This is not an override but is called Method Hiding.

If we summarize the process of overriding;

After the override process, the method signature remains the same (method name and parameters must stay the same), only the functionality of the method changes.
The return type of the overridden method should not change or it should be a co-variant return type.
The access modifier of the overridden method should be the same or less restrictive than the original method.
private, static, final methods cannot be overridden.

Now that we have gained a general understanding and logic about overriding, let's take a look at the concept of overloading.

Method Overloading

Method Overloading is the redefinition of a method with the same name but different parameters. This means that the parameter section of the method signature is changed. This allows for the creation of different methods that perform the same task but with different parameter types, which can be called independently.

Let's try to clarify the situation with some short code examples,

public class Calculator {

    public int summation(int num1, int num2) {
        return num1 + num2;
    }

    public int summation(int num1, int num2, int num3) {
        return num1 + num2 + num3;
    }

    public static void main(String[] args) {
        Calculator calc = new Calculator();
        int result1 = calc.summation(2, 3);
        int result2 = calc.summation(2, 3, 4);

        System.out.println("Summation of 2 and 3: " + result1);
        System.out.println("Summation of 2, 3 and 4:  " + result2);
    }
}

In the example above, we defined two different methods with the name summation() inside the Calculator class, where the first method takes two integer parameters, and the second method takes three integer parameters. In the main method, we call both methods with different parameters and print the result to the screen.

Let's take a look at another example to reinforce our understanding.

public class HelloWorld {

    public void greet() {
        System.out.println("Hello, world!");
    }

    public void greet(String name) {
        System.out.println("Hello, " + name + "!");
    }

    public static void main(String[] args) {
        HelloWorld helloWorld = new HelloWorld();
        helloWorld.greet();
        helloWorld.greet("John");
    }
}

In the example above, the HelloWorld class defines two different methods named greet().

The first method is a simple greeting method that takes no parameters and prints the message "Hello, world!". The second method takes a parameter of type String and uses it to create a customized greeting message. Both methods are called in the main method and their results are printed to the console.

Okey, now that we have gone through the examples, I think we have some understanding about method overloading. Let's delve into some details about overloading using the same questions we used for understanding override.

Then our first question is as follows🎇

"When overriding a method, we had to carefully choose the Access Modifier. That is, we had to either use the same Access Modifier as the previous method or a less restrictive one. Is this also true for Overloading?"

Our answer should be no 🙂

The logic here is different from overriding. Access modifier selection was important for overriding because inheritance played a leading role. However, in overloading, we have no constraints and we are completely free to choose any modifier we want.

As in the example below,

public int sum(int a, int b, int c) {
        return a + b + c;
    }

protected void sum() {
        System.out.print("Nothing to sum");
    }

And for our another question,

"The return types of the methods we override must be the same or a co-variant type. How does this work in Overloading?"

Actually, we have already demonstrated this situation in the example we provided earlier. The return type is not important in Overloading. It can be the same or different.

"Can I overload every method?"

The answer to this question should be yes 🙂 There is no problem with overloading a method that is private, static, or final.

Let's reinforce this situation with the example below.

public class Example {
    public static void doSomething(int x) {
        System.out.println("doSomething with int: " + x);
    }

    public static void doSomething(double x) {
        System.out.println("doSomething with double: " + x);
    }

    public final void doSomething(String x) {
        System.out.println("doSomething with String: " + x);
    }
}

If we summarize the overloading process in short points;

After the overloading process, the method signature changes (method name remains the same, method parameters change).
The return type of the overloaded method can remain the same or be different.
The access modifier of the overloaded method can remain the same or be different.
private, static, final methods can also be overloaded, there is no restriction.

If we've made it this far understanding, I believe we have an idea about the concepts of Overloading and Overriding. This has been a compilation of what I've learned and researched about Override and Overload. Thank you for taking the time to read this far.

Happy Coding! 🤞🏼

Mutable and Immutable in Java

Barış Ayten — Mon, 03 Apr 2023 11:25:26 +0000

Hello Folks 🖖🏼,

The topic of this article will be about the concept of Mutablity and Immutablity in Java. I will try to answer questions such as "What does Mutable & Immutable mean?", "What is the logic behind this functionality?", "How are Mutable or Immutable classes created?", "What are the advantages and disadvantages?".

Let's dive right in and explore these fascinating concepts together. 🚀

1. Mutable Classes

Mutable objects are objects that can be modified after they are initialized. In some cases, these types of classes can be preferred over immutable classes due to their flexibility and mutable fields.

Examples of these classes include StringBuffer, StringBuilder, and the Date class found in the Java util package. To further clarify what I mean, let me provide a short code example.

// Initialize variable called myString
StringBuilder myString = new StringBuilder("Hello");

//and manipulate it
myString.append(" Word");

System.out.println(myString); // Hello World

In fact, those who are not familiar with the topic may be a little surprised. They might say, 'I can already do this in any variable I want, can't I?' Our friends will be able to grasp the underlying logic more clearly when we delve into the details of the topic and the immutable part 🙂

When a change is made in mutable classes, the change is made on the same field without creating a new space in memory (the situation is the opposite in immutables 🙂). In fact, the logic behind mutable classes is that they have a set() method that we call a setter.

However, being changeable is not always a good thing for us, as it can cause some side effects...

For example, using mutable classes in threaded operations can sometimes cause problems for us. When two execution threads try to access and change a mutable value at the same time, a situation may arise where one overrides the other. Therefore, we should be careful when using mutable classes.

We mentioned that there are mutable classes that already come with Java. So how would we create our own if we wanted to?

I'll try to explain this with a short code.

public class MutableClass {

   private int mutableField1;
   private String mutableField2;

   public MutableClass(int fld1, String fld2) {
      this.mutableField1 = fld1;
      this.mutableField2 = fld2;
   }

   public int getMutableField1() {
      return mutableField1;
   }

   public void setMutableField1(int mutableField1) {
      this.mutableField1 = mutableField1;
   }

   public String getMutableField2() {
      return mutableField2;
   }

   public void setMutableField2(String mutableField2) {
      this.mutableField2 = mutableField2;
   }
}

In this example, we defined the class fields as mutable. Additionally, we created two setter methods, setMutableField1() and setMutableField2(), for each field to enable us to change their values. This way, the fields of this class can be modified as desired after the initial use.

🌟In summary,

Mutable objects are ones that can be changed without creating a new object in memory.
They have a setter method in their class.
They may cause disadvantages in threaded operations due to race conditions.

2.Immutable

In fact, in this concept, the opposite of the situations explained above is present. Once an immutable object is initialized, we cannot change its value. Examples of these objects include primitive types, Wrapper Classes, Legacy classes (what!?), and the String class. As an example, readers can refer to my blog post "String, StringBuilder, and StringBuffer in Java" where I discussed the implications of being mutable or immutable for these three
classes.

In immutable classes, unlike mutable classes, only Getter methods are present. When a change is desired in these classes, a new area is created in memory and the manipulated version of the variable is stored in this new area. This creates unnecessary memory usage as a new area is constantly created for each manipulation, making immutable classes slower in terms of performance compared to mutable classes.

Another difference from mutable classes is that they are safer in threaded processes since they are immutable and cannot be changed.

So, what should we do if we want to create an immutable class? Let's take a look:

We can define the class as final.
We can define the variables that will be used in the class as final and assign their initial values through the constructor method. Therefore, since these fields are final and have initial values, they will give an error if they are attempted to be changed.
We do not use the Setter method.

Let's now show all that has been explained in the code. In fact, let's try to make the "MutableClass" that we created above immutable now.

public final class ImmutableClass {

   private final int immutableField1;
   private final String immutableField2;

   public ImmutableClass(int fld1, String fld2) {
      this.immutableField1 = fld1;
      this.immutableField2 = fld2;
   }

   public int getImmutableField1() {
      return immutableField1;
   }

   public String getImmutableField2() {
      return immutableField2;
   }
}

In the code I wrote above, we declared the fields of the class as final and assigned their initial values in the constructor, making it immutable. Additionally, since we do not have any setter methods, the fields of this class cannot be accessed and assigned any value.

To summarize the whole topic and make a comparative analysis, we can create a table as follows, from start to finish.

Mutable	Immutable
We can change the value of mutable objects after initialization.	Once an immutable object is initiated; We can not change its values.
The state can be changed.	The state can not be changed.
In mutable objects, no new objects are formed.	In immutable objects, a new object is formed when the value of the object is altered.
It provides methods to change the object.	It does not provide any method to change the object value.
It supports get() and set() methods to dela with the object.	It only supports get() method to pass the value of the object.
Mutable classes are may or may not be thread-safe.	Immutable classes are thread-safe.
The essentials for creating a mutable class are methods for modifying fields, getters and setters.	The essentials for creating an immutable class are final class, private fields, final mutable objects.

In conclusion🌟,

the use of Mutable and Immutable classes in Java is important for software developers to improve code quality, minimize errors, and optimize performance. While the use of Mutable classes can be advantageous in terms of flexibility and customization, their misuse can lead to program errors.

The use of Immutable classes is ideal for writing safe and shareable code, but in some cases, they may be disadvantaged in terms of performance. By choosing the right class types according to the needs of the application, programmers can improve code quality and create more secure, scalable, and performant applications.

If you have taken the time to read this far, thank you very much. If you notice any mistakes, please feel free to contact me via email.

Happy coding! 🎉

⭐For the original article -> https://bayten.dev/posts/mutable-and-immutable-in-java/

String, StringBuilder, and StringBuffer in Java

Barış Ayten — Mon, 03 Apr 2023 11:21:35 +0000

Hello!🖖🏼

This article will be about the String class that we frequently use in Java and its alternatives, StringBuilder and StringBuffer. There may be points that I missed, skipped, or inadvertently conveyed incorrectly. If you give me feedback via email in such a situation, I would be very happy.

Now, let’s get started🚀

1.String

First, let’s look at the String class. As we all know, the String class is one of the complex data types in Java that represents character arrays. This class stores an array of characters and provides multiple functions for manipulating these characters. When we want to use it, we define it as shown below and assign a value.

   String str= "Merhaba";

So far, there is no problem here. However, as we know, in Java, the String class is "immutable" meaning it cannot be changed. But of course, some of you might say, "Oh no, I have changed and assigned many times and performed the operations I wanted!"

This is where situations arise that prompted me to write this article.

In fact, when we manipulate a String variable, the value that the variable points to does not change 🙂. In such an operation, a new space is opened in the Heap, and the manipulated value is placed there, and our reference points to this new address.

    String str = "Merhaba";
    str.concat("Dünya");

When we define as shown above and then perform the "concat" operation, as mentioned, a new space is created in memory, and our "str" variable now references the address where the "MerhabaDünya" variable is located.

So, a new space is being constantly opened in memory every time the variable is manipulated. And of course, this is not something we would want because it causes both performance and time loss. 🙂

At this point, the StringBuilder class comes to our help.

2.StringBuilder

The role of StringBuilder is also the same as String. It represents character strings. However, the difference from String is that it is a "mutable" or changeable class. Therefore, it is a better choice than the String class for efficient text manipulation.

For example, if we want to convert all the words in a text file to uppercase, the StringBuilder class can easily do this without recreating the entire text in memory (String was creating a new space in memory for this new value).

Or a very simple example like the one below.

    StringBuilder sentence = new StringBuilder("This is a sentence.");
    sentence.append("Added word.");
    System.out.println(sentence.toString()); //This is a sentence.Added word.

However, there is an important drawback to this class that has not yet been mentioned, which is its lack of a thread-safe structure. If a process involving threads is to be used, the StringBuilder class is not suitable in this scenario. This limitation can be explained with the following code snippet:

    StringBuilder sb = new StringBuilder();

    Thread t1 = new Thread(() -> {
        for(int i=0; i<10000; i++){
            sb.append("A");
        }
    });

    Thread t2 = new Thread(() -> {
        for(int i=0; i<10000; i++){
            sb.append("B");
        }
    });

    t1.start();
    t2.start();

    t1.join();
    t2.join();

    System.out.println(sb.toString());

In this example, two distinct threads, t1 and t2, access the StringBuilder object concurrently and append the characters "A" and "B" 10,000 times each in a sequential manner. However, due to the lack of synchronization in the StringBuilder object, the resulting output is indeterminate and can yield varying results on each execution. In essence, a data race condition is introduced.

To address this issue, we can use the StringBuffer class instead.

3.StringBuffer

I won't repeat the same information with StringBuffer here, if you have read this far, you can already guess that the only difference of this class is its "thread-safe" or synchronized structure. It has the same methods and logic as StringBuilder.

However, this great feature also brings some drawbacks. Its synchronized structure causes it to work slower than StringBuilder.

If we try to explain this with a small code snippet,

    public class StringBufferVsStringBuilder {
        public static void main(String[] args) {
            int N = 1000000;
            long startTime, endTime, duration;

            // StringBuffer performance test
            StringBuffer buffer = new StringBuffer();
            startTime = System.nanoTime();
            for (int i = 0; i < N; i++) buffer.append("hello");

            endTime = System.nanoTime();
            duration = (endTime - startTime);
            System.out.println("Time taken by StringBuffer: " + duration + " nanoseconds");
            //Time taken by StringBuffer: 19494000 nanoseconds

            // StringBuilder performance test
            StringBuilder builder = new StringBuilder();
            startTime = System.nanoTime();
            for (int i = 0; i < N; i++) builder.append("hello");

            endTime = System.nanoTime();
            duration = (endTime - startTime);
            System.out.println("Time taken by StringBuilder: " + duration + " nanoseconds");
            //Time taken by StringBuilder: 17145000 nanoseconds
        }
    }

This code calculates the elapsed time for StringBuilder and StringBuffer to append the word "hello" one million times. When we run this code, we can easily observe that StringBuffer works slower due to its synchronized structure. We can make this difference more prominent by increasing the value of N.

As a summary, I am adding the features of both classes in the table below,

Features	StringBuilder	StringBuffer
Thread-Safe	No	Yes
Performance	Faster	Slower
Memory Usage	Less	More
Mutable	Yes	Yes

Finally,

There is no harm in using the String class, but we should keep in mind that it is immutable, and every time we try to modify it, a new memory space is created.
StringBuilder, on the other hand, performs all operations without the need for creating new memory spaces, but it may provide incorrect results in thread-containing applications since it does not have a synchronized structure.
We can solve the problem of StringBuilder by using StringBuffer, which operates in a synchronized structure, but this class may cause some performance loss compared to StringBuilder.

If you have taken the time to read this far, thank you very much. If you notice any mistakes, please feel free to contact me via email.

⭐For the original article -> https://bayten.dev/posts/string-stringbuilder-and-stringbuffer-in-java/

Happy coding! 🎉