9 Unusual Design Patterns Interview Questions (with Answers)
Tags: designpatterns, fullstack, interview, questions
Published: 2018-07-17 14:38:42

---
title: 9 Unusual Design Patterns Interview Questions (with Answers)
published: true
description: 9 Unusual Design Patterns Interview Questions (with Answers)
tags: design patterns, fullstack, interview, questions
canonical_url: https://www.fullstack.cafe/blog/9-unusual-design-patterns-interview-questions
---
![9 Unusual Design Patterns Interview Questions and Answers](https://images.pexels.com/photos/678117/pexels-photo-678117.jpeg?auto=compress&cs=tinysrgb&dpr=2&h=350)
In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

> Originally published on [FullStack.Cafe - Never Fail Your Tech Interview Again](https://www.fullstack.cafe)

### Q1: What is Design Patterns and why anyone should use them?
> Topic: **Design Patterns**<br/>Difficulty: ⭐

Design patterns are a well-described solution to the most commonly encountered problems which occur during software development. 

Design pattern represents the best practices evolved over a period of time by experienced software developers. They promote reusability which leads to a more robust and maintainable code.

🔗**Source:** [www.educba.com](https://www.educba.com/design-pattern-interview-questions/)
### Q2: What is Filter pattern?
> Topic: **Design Patterns**<br/>Difficulty: ⭐⭐

**Filter pattern** or **Criteria pattern** is a design pattern that enables developers to filter a set of objects using different criteria and chaining them in a decoupled way through logical operations. This type of design pattern comes under *structural* pattern as this pattern combines multiple criteria to obtain single criteria.

**Filter design pattern** is useful where you want to add filters dynamically or you are implementing multiple functionalities and most of them require different filter criteria to filter something. In that case instead of hard coding the filters inside the functionalities, you can create filter criteria and re-use it wherever required.

Consider:
```js
List<Laptop> laptops = LaptopFactory.manufactureInBulk();
AndCriteria searchCriteria = new AndCriteria(
  new HardDisk250GBFilter(), 
  new MacintoshFilter(), 
  new I5ProcessorFilter());
List<Laptop> filteredLaptops = searchCriteria.meets(laptops);
```

🔗**Source:** [tutorialspoint.com](https://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm)
### Q3: What is Strategy pattern?
> Topic: **Design Patterns**<br/>Difficulty: ⭐⭐

In **Strategy pattern**, a class behavior or its algorithm can be changed at run time. This type of design pattern comes under _behavior_ pattern.

In Strategy pattern, we create objects which represent various strategies and a context object whose behavior varies as per its strategy object. The strategy object changes the executing algorithm of the context object.

<div class="text-center">
<img src="https://upload.wikimedia.org/wikipedia/commons/4/45/W3sDesign_Strategy_Design_Pattern_UML.jpg" class="img-fluid"/>
</div>



🔗**Source:** [tutorialspoint.com](https://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm)
### Q4: What is Observer pattern?
> Topic: **Design Patterns**<br/>Difficulty: ⭐⭐⭐

**Observer pattern**  (also known as *Publish-Subscribe Pattern*) is used when there is one-to-many relationship between objects such as if one object is modified, its dependent objects are to be notified automatically. Observer pattern falls under _behavioral_ pattern category.

An object with a one-to-many relationship with other objects who are interested in its state is called the _subject_ or _publisher_. The _observers_ are notified whenever the state of the _subject_ changes and can act accordingly. The _subject_ can have any number of dependent _observers_ which it notifies, and any number of _observers_ can subscribe to the _subject_ to receive such notifications.

Observer pattern uses two actor classes:
* The Observer (os Subscriber) abstract class provides an `update()` method which will be called by the subject to notify it of the subject’s state change. 
* The Subject (or Publisher) class is also an abstract class and defines four primary methods: `attach()`, `detach()`, `setState()`, and `notify()`



<div class="text-center">
<img src="https://upload.wikimedia.org/wikipedia/commons/0/01/W3sDesign_Observer_Design_Pattern_UML.jpg" class="img-fluid"/>
</div>

🔗**Source:** [sitepoint.com](https://www.sitepoint.com/understanding-the-observer-pattern/)
### Q5: Why would I ever use a Chain of Responsibility over a Decorator?
> Topic: **Design Patterns**<br/>Difficulty: ⭐⭐⭐⭐

The key difference is that a **Decorator** adds new behaviour that in effect widens the original interface. It is similar to how normal extension can add methods except the "subclass" is only coupled by a reference which means that any "superclass" can be used.

The **Chain of Responsibility** pattern can modify an existing behaviour which is similar to overriding an existing method using inheritance. You can choose to call `super.xxx()` to continue up the "chain" or handle the message yourself.

🔗**Source:** [stackoverflow.com](https://stackoverflow.com/questions/747913/why-would-i-ever-use-a-chain-of-responsibility-over-a-decorator)
### Q6: When would you use the Builder Pattern? Why not just use a Factory Pattern?
> Topic: **Design Patterns**<br/>Difficulty: ⭐⭐⭐⭐

The *builder pattern* is a good choice when designing classes whose constructors or static factories would have more than a handful of parameters.

Consider a restaurant. The creation of "today's meal" is a factory pattern, because you tell the kitchen "get me today's meal" and the kitchen (factory) decides what object to generate, based on hidden criteria.

The builder appears if you order a custom pizza. In this case, the waiter tells the chef (builder) "I need a pizza; add cheese, onions and bacon to it!" Thus, the builder exposes the attributes the generated object should have, but hides how to set them.

🔗**Source:** [stackoverflow.com](https://stackoverflow.com/questions/328496/when-would-you-use-the-builder-pattern)
### Q7: How is Bridge pattern is different from Adapter pattern?
> Topic: **Design Patterns**<br/>Difficulty: ⭐⭐⭐⭐

The intent of the *Adapter pattern* is to make one or more classes' interfaces look the same as that of a particular class. 

The *Bridge pattern* is designed to separate a class's interface from its implementation so you can vary or replace the implementation without changing the client code.

🔗**Source:** [tutorialspoint.com](https://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm)
### Q8: What's the difference between the Dependency Injection and Service Locator patterns?
> Topic: **Design Patterns**<br/>Difficulty: ⭐⭐⭐⭐⭐

* With the **ServiceLocator**, the class is still responsible for creating its dependencies. It just uses the service locator to do it. 

* **Service locators** hide dependencies - you can't tell by looking at an object whether it hits a database or not (for example) when it obtains connections from a locator. 

* With **DI**, the class is given it's dependencies. It neither knows, nor cares where they come from. 

One important result of this is that the DI example is much easier to unit test -- because you can pass it mock implementations of its dependent objects. You could combine the two -- and inject the service locator (or a factory), if you wanted.

🔗**Source:** [stackoverflow.com](https://stackoverflow.com/questions/1557781/whats-the-difference-between-the-dependency-injection-and-service-locator-patte)
### Q9: Explain difference between the Facade, Proxy, Adapter and Decorator design patterns?
> Topic: **Design Patterns**<br/>Difficulty: ⭐⭐⭐⭐⭐

* **Adapter** adapts a given class/object to a new interface. In the case of the former, multiple inheritance is typically employed. In the latter case, the object is wrapped by a conforming adapter object and passed around. The problem we are solving here is that of non-compatible interfaces.
* **Facade** is more like a simple gateway to a complicated set of functionality. You make a black-box for your clients to worry less i.e. make interfaces simpler.
* **Proxy** provides the same interface as the proxied-for class and typically does some housekeeping stuff on its own. (So instead of making multiple copies of a heavy object X you make copies of a lightweight proxy P which in turn manages X and translates your calls as required.) You are solving the problem of the client from having to manage a heavy and/or complex object.
* **Decorator** is used to add more gunpowder to your objects (note the term objects -- you typically decorate objects dynamically at runtime). You do not hide/impair the existing interfaces of the object but simply extend it at runtime

🔗**Source:** [stackoverflow.com](https://stackoverflow.com/questions/3489131/difference-between-the-facade-proxy-adapter-and-decorator-design-patterns)

> *Thanks 🙌 for reading and good luck on your interview!* <br/>*Check more FullStack Interview Questions & Answers on 👉 [www.fullstack.cafe](https://www.fullstack.cafe)*