Java Design Pattern Interview Questions and Answers

Factors that one should consider before using the flyweight pattern are: 

• The curation of objects might take a lot of time and memory. 
• Both intrinsic and extrinsic features can be categorized as attributes. 
• The extrinsic characteristics of the Object should be made clear by the client software. 
• The application should create a large number of objects. 

A staple in Java Design Pattern Interview Questions for experienced, be prepared to answer this one.

When there is a one-to-many relationship between items, such as when a modified object needs to automatically notify dependent objects, the observer pattern is employed. The behavioral pattern category includes observer patterns.

The implementations of the Observer Design Pattern are as follows:

• javax.servlet.http.HttpSessionAttributeListener
• java.util.EventListener in Swing
• javax.servlet.http.HttpSessionBindingListener

When an object alters its behavior based on its internal state, the state design pattern is applied. If we need to alter an object's behavior based on its state, we may save the state as a variable in the object and use an if-else condition block to take various actions according to the state. 

Through the implementation of Context and State, the State pattern offers a methodical and decoupled way to accomplish this. 

Example:

class AlertStateContext{ 
private MobileAlertState currentState; 
public AlertStateContext() 
{ 
CurrentState = newVibration(); 
} 
public void setState(MobileAlertState state) 
{ 
 currentState = state; 
} 
public void alert() 
{ 
currentState.alert(this); 
  }} 
class Vibration implements MobileAlertState 
{ 
public void alert(AlertStateContext ct) 
{ 
System.out_printin(“vibration state."); 
} 
 } 
class Silent implements MobileAlertState  
{ 
public void alert(AlertStateContext ct) 
{ 
System.out.printin(“silent state."); 
} 
class StatePattern{ 
public static void main(String{] args){ 
AlertStateContext stateContext = new AlertStateContext(); 
stateContext.alert(); 
stateContext.setState(new Silent()); 
StateContext.alert(); } 

Output:

Behavioral Design Patterns include the Command Pattern. Under the request-response model, it is utilized to implement loose coupling. The request is delivered to the invoker in this process, who then passes it on to the command Object. The command object then sends the request to the receiver's appropriate method. Additionally, the receiver carries out the designated action.

The Base Component, Leaf, and Composite are the various Objects of the Composite Design Pattern. 

1. The interface that all Objects in the composition used is called Base Composite. This component is preferred by the client software for use with the composition's objects. 
2. Leaf contributes to the composition's behavior definition. There is no reference to any other components included with this object. It implements fundamental elements and serves as a foundational element for the composition. 
3. The process is carried out in the base component by the composite, which also carries leaf elements. 

Algorithms and design patterns both outline typical solutions to a variety of issues. The major distinction, though, is that while a design pattern offers a high-level description of any solution, an algorithm specifies a precise set of steps for achieving a goal.

Even though two separate problems may use the same design pattern, the implementation logic will vary depending on the needs.

A builder pattern is a type of creational design pattern that enables you to build complex objects piece by piece. Through the same logic of construction, the pattern enables you to create many representations of an item. 

It facilitates the development of immutable classes with several characteristics. If the object has multiple properties, you run into these issues in both the Factory and Abstract Factory Design Patterns: 

1. When the client passes too many arguments to the Factory Class in a specific order, the application becomes more prone to errors. When the types are the same, it becomes challenging to maintain the order of these arguments. 
2. The intricacy of this class will become confusing when an object's creation becomes complicated due to numerous characteristics. 
3. The object may have optional attributes. And yet, you can be forced to send Null values for all of the optional properties and parameters. 

This pattern provides a technique to construct an object in a step-by-step approach and return the finished object through another method, helping to tackle the problem of a large number of optional characteristics and the inconsistent condition. 

Implementation of builder pattern is shown below: 

• Copy all of the arguments from the outer class into a static nested class: the builder class will be this nested class. The builder class's name must adhere to a proper naming convention. For instance, the builder will be called SampleBuilder if the class is called Sample. 
• The public constructor for the builder class must be public and accept all of the characteristics as input. 
• Additionally, the builder class ought to provide methods for setting optional arguments and returning the builder object after doing so. 
• To return the object needed by the client, the construct() method must be present inside the builder class. 

The distinction between JDO and VO is that the former is a persistent technology that challenges entity beans in the creation of corporate applications. You can produce POJOs (plain old Java objects) and persist them to the database using this tool.

Value objects, or VOs, are an abstract design pattern that may be utilized with entity beans, jdbc, and possibly even JDO to solve typical isolation and transactional issues in corporate apps.

Use Setter injection to supply an object's optional dependencies, and Constructor injection to offer an object's mandatory dependence, without which it will not function.

This inquiry also relates to the Dependency Injection design pattern and is frequently posed in relation to the Spring framework, which has now established itself as the de facto tool of choice for creating Java applications.

Since Spring offers an IOC container, you have the option to declare dependencies using constructors or setter methods.

The Java concurrency design pattern known as Producer-Consumer can be implemented in a variety of ways. If you're using Java 5, it's preferable to implement the producer-consumer pattern using concurrency rather than Java's default wait and notify method. 

import java.util.concurrent.BlockingQueue; 
import java.util.concurrent.LinkedBlockingQueue; 
import java.util.logging.Level; 
import java.util.logging.Logger; 
public class ProducerConsumerPattern {
public static void main(String args[]){ 
     //Creating shared object 
 BlockingQueue sharedQueue = new LinkedBlockingQueue(); 
 //Creating Producer and Consumer Thread 
 Thread prodThread = new Thread(new Producer(sharedQueue)); 
 Thread consThread = new Thread(new Consumer(sharedQueue));   
     //Starting producer and Consumer thread 
 prodThread.start(); 
 consThread.start(); 
}   
}  
//Producer Class in java 
class Producer implements Runnable { 
private final BlockingQueue sharedQueue;  
public Producer(BlockingQueue sharedQueue) { 
    this.sharedQueue = sharedQueue; 
}  
@Override 
public void run() { 
    for(int i=0; i<10; i++){ 
        try { 
            System.out.println("Produced: " + i); 
            sharedQueue.put(i); 
        } catch (InterruptedException ex) { 
            Logger.getLogger(Producer.class.getName()).log(Level.SEVERE, null, ex); 
        } 
    } 
}  
} 
//Consumer Class in Java 
class Consumer implements Runnable{ 
private final BlockingQueue sharedQueue; 
public Consumer (BlockingQueue sharedQueue) { 
    this.sharedQueue = sharedQueue; 
} 
@Override 
public void run() { 
    while(true){ 
        try { 
            System.out.println("Consumed: "+ sharedQueue.take()); 
        } catch (InterruptedException ex) { 
            Logger.getLogger(Consumer.class.getName()).log(Level.SEVERE, null, ex); 
        } 
    } 
}  
} 

Another common core Java design pattern interview question is about the Template pattern. It has frequently appeared in actual projects, in my experience. The template pattern allows the subclass to implement specific steps while outlining an algorithm in the form of a template method.

When addressing this query, it is crucial to emphasize that the template method should be final in order to prevent subclasses from overriding and altering the algorithm's phases. Individual steps should be abstract, nonetheless, so that child classes can carry them out.

In such a scenario, we can leverage the object-oriented design pattern in Java. While developing code for the Smartphone class we need to ensure that it is both flexible and stable. 

The object-oriented design pattern features a pattern of fixed class structure and messaging that can be readily used multiple times. It appears as a useful and elegant programming idiom. 

It must be flexible to facilitate the creation of derived classes in the future while the stability will ensure that any required changes to the existing classes can be made without any issues. 

If you’re involved in financial services development, then you should know how to add market data to your Java program effortlessly and efficiently. 

One way to implement the aforementioned scenario is to develop an interface that can be called MarketAnalysis, MarketData, or something like that. It will have methods like getBid() and getPrice(). 

Moreover, the interface must be able to add market data provided by different vendors and thus have a MarketDataProvider method implemented using DI. Doing so will allow the client to change market data sources - Reuters, Bloomberg, or S&P Global Market Intelligence - without any hassle. 

Java is immensely popular for its platform-agnostic operation. Java Memory Model is the collection of certain guidelines and rules that facilitate the creation of Java programs that perform reliably and as intended across different operating systems, CPUs, hardware configurations, and memory architecture. It is the most useful when aiming for multi-threading. 

Java Memory Model allows setting the changes made by a thread that must be visible for others. Let’s take the example of the happens-before relationship. 

It ensures that if X happens before Y, and Y happens before Z, then X happens before Z. This guarantees transitivity. Other things ensured by a happens-before relationship are volatile variable rule, program order rule, and monitor lock rule. 

When two or more threads (or processes) in Java wait for each other’s resources then we can say that a deadlock has occurred. Usually, it happens when different threads need the same locks but get them in different orders.

Deadlock is a major issue when achieving multithreading in Java. Livelock is a special case of resource starvation. The state of a thread doesn’t change in a deadlock. Compared to a deadlock, the states of the threads or processes involved change continuously with respect to one another in a livelock.

The Chain of Responsibility pattern is a type of behavior where a number of objects are chained together in a specific order and given a responsibility (or request) to complete. If an object in the group can handle the specific request, it does so and sends back the appropriate response. If not, it sends the request to the next object in the group.

It passes the invoker object a request that is contained within an object in the form of a command. The invoker object searches for the proper object that can handle the command and passes the command to the appropriate object, which then executes it. Action or Transaction are other names for it. 

Advantage: 

• It distinguishes between the object that calls for the action and the object that executes it.

Example: This example shows a straightforward command execution cycle where the user must demonstrate turning on and off various electronic equipment in his home, such as a lightbulb and a stereo. He issues the command using a straightforward remote control as the invoker object.

//Command 
package CommandDesignPattern; 
  
interface Command { 
       public void execute(); 
} 
 
//Bulb 
package CommandDesignPattern; 
  
class Bulb { 
       public void on() { 
             System.out.println("Bulb is on"); 
       } 
public void off() { 
       System.out.println("Bulb is off"); 
       } 
} 
 
//nCommand 
package CommandDesignPattern; 
  
class nCommand implements Command { 
         Bulb light; 
         public nCommand(Bulb light) { 
                 this.light = light; 
         } 
         public void execute() { 
                 light.on(); 
         } 
} 
 
//OffCommand 
package CommandDesignPattern; 
  
class OffCommand implements Command { 
       Bulb light; 
       public OffCommand(Bulb light) { 
              this.light = light; 
       } 
       public void execute() { 
              light.off(); 
       } 
} 
 
//Stereo 
package CommandDesignPattern; 
  
class Stereo { 
       public void on() { 
              System.out.println("Stereo is on"); 
       } 
       public void off() { 
              System.out.println("Stereo is off"); 
       } 
       public void setCD() { 
              System.out.println("Stereo is set " + "for CD input"); 
       } 
       public void setDVD() { 
             System.out.println("Stereo is set" + " for DVD input"); 
       } 
       public void setRadio() { 
             System.out.println("Stereo is set" + " for Radio"); 
       } 
       public void setVolume(int volume) { 
             System.out.println("Stereo volume set" + " to " + volume); 
       } 
} 
 
//StereoOffCommand 
package CommandDesignPattern; 
  
class StereoOffCommand implements Command { 
      Stereo stereo; 
      public StereoOffCommand(Stereo stereo) { 
             this.stereo = stereo; 
      } 
      public void execute() { 
             stereo.off(); 
      } 
} 
 
//StereoOnWithCDCommand 
package CommandDesignPattern; 
  
class StereoOnWithCDCommand implements Command { 
         Stereo stereo; 
         public StereoOnWithCDCommand(Stereo stereo) { 
               this.stereo = stereo; 
         } 
         public void execute() { 
               stereo.on(); 
               stereo.setCD(); 
               stereo.setVolume(11); 
         } 
} 
 
//SimpleRemoteControl 
package CommandDesignPattern; 
  
class SimpleRemoteControl { 
       Command slot; 
       public SimpleRemoteControl() { 
       } 
       public void setCommand(Command command) { 
               slot = command; 
       } 
       public void buttonWasPressed() { 
               slot.execute(); 
       } 
} 
 
//RemoteControlTest 
package CommandDesignPattern; 
  
class RemoteControlTest { 
        public static void main(String[] args) { 
               SimpleRemoteControl remote = new SimpleRemoteControl(); 
               Bulb light = new Bulb(); 
               Stereo stereo = new Stereo(); 
               remote.setCommand(new nCommand(light)); 
               remote.buttonWasPressed(); 
               remote.setCommand(new StereoOnWithCDCommand(stereo)); 
               remote.buttonWasPressed(); 
               remote.setCommand(new StereoOffCommand(stereo)); 
               remote.buttonWasPressed(); 
       } 
} 

Output: 

Bulb is on 
Stereo is on 
Stereo is set for CD input 
Stereo volume set to 11 
Stereo is off 

A design pattern known as the null object replaces the NULL check for instance variables. Null Object reflects a do-nothing relationship rather than putting a check for a null value. When data is not accessible, it can also be used to offer default behavior.

The decorator pattern, commonly referred to as a structural pattern, is used to dynamically add new functionality to a given object. The decorator object is wrapped around the original item.

When purchasing a burger, for instance, you may choose to add more filling and sauces; but, the cost of these additions must now be factored into the final price. Customer to customer and shop to shop, personalization will vary.

There will be numerous classes created if different classes of hamburgers are created with various fillings. This issue is resolved by Decorator by dynamically expanding the functionality of a single Burger class in response to user requests.

1. Various Java IO classes use the decorator design pattern.
2. Run-time use of the singleton pattern.
3. The calendar and different classes.
4. The factory pattern, which is utilized in conjunction with a number of immutable classes, including Boolean. For example, function valueOf().
5. Swing and numerous event listener frameworks use the observer design.

This along with similar questions on Java Design Pattern interviews is a regular feature in Java Design Pattern Interviews, be ready to have a complete explanation.

The MVC (Model View Controller) design pattern is described as follows: 

Models serve as the application's blueprints for all the objects that will be used in it. Views are used to represent how the data and information included in the models are presented.

Both the Models and the Views are controlled by and acted upon by the Controllers. They act as a bridge connecting the Models and Views. Models can be created, updated, and deleted by controllers. They fill them up with data and then transmit it to the views so the user can see it.

Advantages: 

• For a model, it supports numerous views. 
• To set and print the student data, for instance, we'll use the MVC Design Pattern. 

//MVC pattern 
package MVCDesignPattern;   
public class MVCPattern { 
public static void main(String[] args){ 
              Student model = retriveStudentFromDatabase(); 
              StudentView view = new StudentView(); 
              StudentController controller = new StudentController(model, view); 
              controller.updateView(); 
              controller.setStudentName("Rajat Shukla"); 
              controller.updateView(); 
       } 
       private static Student retriveStudentFromDatabase(){ 
              Student student = new Student(); 
              student.setName("Ram Kumar"); 
              student.setRollNo("21CSE987"); 
              return student; 
       } 
} 
 
//Student 
package MVCDesignPattern; 
public class Student { 
      private String rNo; 
      private String name; 
      public String getRollNo(){ 
            return rollNo; 
      } 
      public void setRollNo(String rollNo){ 
            this.rollNo = rollNo; 
      } 
      public String getName(){ 
            return name; 
      } 
      public void setName(String name){ 
           this.name = name; 
      } 
} 
  
//StudentController 
  
package MVCDesignPattern; 
  
public class StudentController { 
       private Student model; 
       private StudentView view; 
       public StudentController(Student model, StudentView view){ 
              this.model = model; 
              this.view = view; 
       } 
       public void setStudentName(String name){ 
              model.setName(name); 
       } 
       public String getStudentName(){ 
              return model.getName(); 
       } 
       public void setStudentRollNo(String rollNo){ 
             model.setRollNo(rollNo); 
       } 
       public String getStudentRollNo(){ 
             return model.getRollNo(); 
       } 
       public void updateView(){ 
             view.printStudentDetails(model.getName(), model.getRollNo()); 
       } 
} 
 
//StudentView 
package MVCDesignPattern; 
  
public class StudentView { 
        public void printStudentDetails(String studentName, String studentRollNo){ 
               System.out.println("Student: "); 
               System.out.println("Name: " + studentName); 
               System.out.println("Roll No: " + studentRollNo); 
        } 
} 

Output: 

Student: 
Name: Ram Kumar 
Roll No: 21CSE987 
Student: 
Name: Rajat Shukla 
Roll No: 21CSE988

Transfer object is a straightforward Java class that only has fields and no business logic. They have accessor methods (getter and setters) to access fields and are serializable POJO classes. These classes don't have to match business objects; they just transport data between levels. Transfer objects often group arguments for method calls.

This is one of the most frequently asked Java Design Pattern Interview questions for experienced professionals.

Often, Java developers might be caught in the dilemma to choose between an abstract class and an interface. For such scenarios, you must know the basic differences between the two so that you can choose the one perfect for your requirements. These points are: 

• Java supports extending a single class only, whereas a single class can implement multiple interfaces. Interfaces are defined in the form of adjectives. That’s because they represent behavior. If an abstract class represents behavior, it can’t behave in two ways, i.e., an abstract class can never be Runnable and Serializable at the same time. 
• An abstract class is faster than an interface. 
• When common behavior across the inheritance hierarchy can be optimized, i.e., coded better than the abstract class is the ideal choice. In certain scenarios, both an abstract class and an interface can be used together. Here, the function is defined in the interface, and the default functionality is in the abstract class. 

In concurrent Java applications, FutureTask represents a cancellable asynchronous computation. FutureTask provides a base implementation for the Future interface. It is a pre-defined Java class that contains various methods for: 

• Starting and canceling computations. 
• Queries to check the status of the computations. 
• Retrieving the results of the computations. 

You can wrap a Callable or Runnable object using a FutureTask object. It can be submitted to an Executor because FutureTask also implements Runnable. 

Note that it is only possible to retrieve the result of a computation that is completed. Trying to fetch the result of an uncompleted computation results in blocking of the get methods. 

Java being a multi-threaded programming language facilitates concurrent design or concurrent programming. While designing a concurrent system, it is important to ensure immutability, using local variables, and thread-safety. Instance or static variables must be avoided. 

A single class can execute multiple threads, so it’s suitable that every thread has its own data to work with so that it doesn’t interfere with other data and has minimal synchronization at the start of the pipeline. 

This is one of the trickiest software design pattern interview questions that might also require coding. Therefore, you need to understand important aspects of concurrency, including atomicity, deadlock, memory interference, race condition, and ThreadLocal variables.

Both concurrent and synchronized collections are ideal for concurrent and multi-threaded access. The difference is that the concurrent collection is more scalable. 

Releases prior to Java 1.5 had only synchronized collection. It worked fine and also provided thread-safety. However, when multiple threads accessed it, the scalability of the system goes down greatly. 

Concurrent collections like ConcurrentHashMap were introduced in Java 5. These collections not only provide thread-safety but also improved scalability by leveraging techniques like partitioning internal tables and lock stripping. 

Stack is integral to threads. Hence, it is important to learn how stack works to better understand concurrency and multi-threading. Both stack and heap are specific types of memories. 

Every thread has its own stack that stores call stack, local variables, and method parameters. Variables stored in the stack of one thread are not visible to one another. Unlike a thread, a heap is a common memory space shared by all the threads. 

Objects are created inside the heap. Thread cache values from the heap into their stack for improving performance. However, if the variable is modified by many threads, issues can arise. This issue is resolved by the introduction of volatile variables. They make the threads read the value of the variable from main memory. 

Deadlock occurs when two threads start waiting for each other to perform something and then they do nothing. This makes the program execution halt and the software hangs. To understand how to prevent a deadlock in Java, you need to understand four conditions that must be true for a deadlock to occur, which are: 

1. Circular Wait - A process waits for a resource that is being held by another process, which is waiting for it to release its resource. 
2. Hold and Wait - A process is holding at least one resource and is requesting one or more resources held by another process(es). 
3. Mutual Exclusion - At least one resource must be held in a non-shareable mode and only a single process can use the resource at a given time. 
4. No Preemption - The OS must not deallocate resources after allocation. They must be released voluntarily by the processes. 

The best way to avoid a deadlock is to prevent Circular Wait. One way to do this is by acquiring locks in a particular order and then releasing them in the reverse order. 

We create a thread-safe singleton class to facilitate object initialization when multiple threads are available. We can do so in many ways. Let’s learn about some of them: 

• Static field initialization 

The Classloader guarantees the initialization of instances at the time of class loading. Thus, another way to create a thread-safe singleton class is to develop the instance during class loading. For this, you need to use static fields. 

Example: 

public class ThreadSafeSingleton{ 
      private static final ThreadSafeSingleton INSTANCE = new ThreadSafeSingleton(); 
      private ThreadSafeSingleton(){ } 
      public static ThreadSafeSingleton getInstance(){ 
          return INSTANCE; 
      } 
      public void display(){ 
          System.out.println("Thread-safe Singleton"); 
      } 
   } 
   ThreadSafeSingleton.getInstance().display(); 

Note: The instance is invisible during the creation. 

• Synchronized Keyword 

Another way to implement Singleton design patterns in Java is by using the synchronized keyword. We can use the synchronized keyword with the getInstance method. 

Example: 

public class ThreadSafeSingleton 
   { 
    // Creating private instance to make it accessible only by getInstance() method 
    private static ThreadSafeSingleton instance; 
    private ThreadSafeSingleton() 
    { 
      // Making constructor private so that objects cant be initialized outside the class 
    } 
    //synchronized getInstance method 
    synchronized public static ThreadSafeSingleton getInstance(){ 
      if (this.instance == null) 
      { 
        // if instance is null, initialize 
        this.instance = new ThreadSafeSingleton(); 
      } 
      return this.instance; 
    } 
   } 

You achieve lazy initialization in this method and the object initialization is thread-safe due to the use of the synchronized keyword. Because of the same reason, the performance can get affected in case of multiple threads. 

• Enums 

Enums are finalized by default. Thus, they help in avoiding many initializations during serialization in Java. This is the easiest way to implement a thread-safe singleton class in Java since the object-oriented programming language provides internal synchronization support. 

Example: 

public enum ThreadSafeSingleton{ 
TSSINGLETON_INSTANCE; 
public void display(){ 
System.out.println("Thread-safe singleton is ready"); 
} 
} 

To invoke the methods of the singleton class, we can use: 

ThreadSafeSingleton.TSSINGLETON_INSTANCE.show(); 

To generate the pyramid pattern on the screen, we need to leverage the concept of looping and define a class PyramidPattern:

public class PyramidPattern 
{ 
  public static void printPyramid (int n) 
  { 
    for (int i = 0; i < n; i++) 
      {// for number of rows  
for (int j = n - i; j > 1; j--) 
  { 
    System.out.print (" ");//print space 
  } 
//for number of columns 
for (int j = 0; j <= i; j++) 
  { 
    System.out.print ("* ");// print star 
  } 
//end-line after every row 
System.out.println (); 
      } 
  } 
  public static void main (String args[]) 
  { 
    printPyramid (5);//Print Pyramid stars of 5 rows 
  } 
} 

The output of the Java program will be:

*

* *

* * *

* * * *

* * * * *