Design Patterns Interview Questions and Answers - Part 11
In Software Industry the Design Patterns and Principles are always followed. So this is the most common topic for the interview. In this article, we will see the most frequently asked 90+ Design Patterns and Principles Interview Questions with Answers.
Please visit our YouTube Channel for Interviews and other videos by below link:
Please read the complete C# Interview Questions and Answers article series here.
Introduction
This is the 11th part of this Design Patterns and Principles Interview Questions and Answers article series. Each part contains five Design Pattern Interview Questions. Please read all the Design Patterns and Principles Interview Questions list here.
I will highly recommend to please read the previous parts over here before continuing the current part:
Design Patterns Interview Questions - Part 11
Q82. What is Strategy Design Pattern (SDP) or Policy Pattern? When to use the Strategy Design Pattern?
The strategy pattern is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.
A strategy pattern is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable. The Strategy design pattern defines a family of algorithms, encapsulate each one, and make them interchangeable. This pattern lets the algorithm vary independently from clients that use it.
The Strategy pattern suggests that you take a class that does something specific in a lot of different ways and extract all of these algorithms into separate classes called strategies.
The original class, called context, must have a field for storing a reference to one of the strategies. The context delegates the work to a linked strategy object instead of executing it on its own.
The context isn’t responsible for selecting an appropriate algorithm for the job. Instead, the client passes the desired strategy to the context. The context doesn’t know much about strategies. It works with all strategies through the same generic interface, which only exposes a single method for triggering the algorithm encapsulated within the selected strategy.
Use the Strategy pattern when you want to use different variants of an algorithm within an object and be able to switch from one algorithm to another during runtime. Use this pattern to isolate the business logic of a class from the implementation details of algorithms that may not be as important in the context of that logic. Use strategy pattern when your class has a massive conditional operator that switches between different variants of the same algorithm.
Q83. What is Visitor Design Pattern (VDP)?
The visitor is a behavioral design pattern that lets you separate algorithms from the objects on which they operate. The Visitor design pattern represents an operation to be performed on the elements of an object structure. This pattern lets you define a new operation without changing the classes of the elements on which it operates. This is one of the classic techniques for recovering lost type information.
In OOPS the visitor design pattern is a way of separating an algorithm from an object structure on which it operates. The visitor allows adding new virtual functions to a family of classes, without modifying the classes. A visitor class is created that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input and implements the goal through double dispatch.
The Visitor pattern suggests that you place the new behavior into a separate class called visitor, instead of trying to integrate it into existing classes. The original object that had to perform the behavior is now passed to one of the visitor’s methods as an argument, providing the method access to all necessary data contained within the object.
Use the Visitor to clean up the business logic of auxiliary behaviors i.e use the pattern when a behavior makes sense only in some classes of a class hierarchy, but not in others.
Q84. What is Template Design Pattern (TDP)?
Template Method is a behavioral design pattern that defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure. It defines the skeleton of an algorithm in an operation, which defers some steps to client subclasses. The Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
The template method is a method in a superclass, usually an abstract superclass, and defines the skeleton of an operation in terms of a number of high-level steps. These steps are themselves implemented by additional helper methods in the same class as the template method. The intent of the template method is to define the overall structure of the operation while allowing subclasses to refine, or redefine certain steps.
The Template Method pattern suggests that you break down an algorithm into a series of steps, turn these steps into methods, and put a series of calls to these methods inside a single template method. The steps may either be abstract or have some default implementation. To use the algorithm, the client is supposed to provide its own subclass, implement all abstract steps, and override some of the optional ones if needed.
Use the pattern when you have several classes that contain almost identical algorithms with some minor differences. The Template pattern is used when you want to let clients extend only particular steps of an algorithm, but not the whole algorithm or its structure.
Q85. What is Chain of Responsibility Design Pattern (CoR) or Chain of Command Pattern?
Chain of Responsibility is a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain. The Chain of Responsibility design pattern avoids coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. This pattern chains the receiving objects and passes the request along the chain until an object handles it.
This pattern promotes the idea of loose coupling. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.
The Chain of Responsibility relies on transforming particular behaviors into stand-alone objects called handlers. The pattern suggests that you link these handlers into a chain. Each linked handler has a field for storing a reference to the next handler in the chain. In addition to processing a request, handlers pass the request further along the chain. The request travels along the chain until all handlers have had a chance to process it.
The chain-of-responsibility pattern is structurally nearly identical to the decorator pattern, the difference being that for the decorator, all classes handle the request, while for the chain of responsibility, exactly one of the classes in the chain handles the request.
Q86. What is the Null Object Pattern?
The Null object pattern is a design pattern that simplifies the use of dependencies that can be undefined. This is achieved by using instances of a concrete class that implements a known interface, instead of null references.
In the Null Object pattern, we create an abstract class specifying various operations to be done, concrete classes extending this class and a null object class providing do-nothing implementation of this class and will be used seamlessly where we need to check null value.
We create an abstract class specifying various operations to be done, concrete classes extending this class and a null object class providing do-nothing implementation of this class and will be used seamlessly where we need to check null value.
In the Null Object pattern, a null object replaces the check of a NULL object instance. Instead of putting the if check for a null value, Null Object reflects a do-nothing relationship. Such Null objects can also be used to provide default behavior in case data is not available.
Q87. What is Circular Dependency and how can you resolve this issue?
In software engineering, a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly. Such modules are also known as mutually recursive. In software design, circular dependencies between larger software modules are considered an anti-pattern because of their negative effects.
Circular dependency is a situation where "Library-A” references "Library-B" and "Library-B" is trying to reference “Library-A”. If you ever try to reference class libraries with each other, Visual Studio throws the below exception.
Circular dependencies can cause many unwanted effects in software programs. Most problematic from a software design point of view is the tight coupling of the mutually dependent modules which reduces or makes impossible the separate re-use of a single module.
Circular dependencies can cause a domino effect when a small local change in one module spreads into other modules and has unwanted global effects. Circular dependencies can also result in infinite recursions or other unexpected failures.
Circular dependencies can be introduced when implementing callback functionality. The circular dependency problem can be overcome by using interfaces or events. This can be avoided by applying design patterns like the observer pattern.
Q88. What is the difference between Sprint and Scrum?
A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches. Sprints are fixed-length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints help teams follow the agile principle of "delivering working software frequently," as well as live the agile value of "responding to change over following a plan."
Sprint planning is a collaborative event where the team answers two basic questions: What work can get done in this sprint and how will the chosen work get done? In sprint planning, user stories and tasks are decided and assigned to the associates. It involves quality or technical debt and QA as well.
Choosing the right work items for a sprint is a collaborative effort between the product owner, scrum master, and development team. The product owner discusses the objective that Sprint should achieve and the product backlog items that, upon completion, would achieve the sprint goal.
During a sprint, the team checks in during the daily scrum, or standup, about how the work is progressing. The goal of this meeting is to surface any blockers and challenges that would impact the team's ability to deliver the sprint goal.
After a sprint, the team demonstrates what they’ve completed during the sprint review. This is your team’s opportunity to showcase their work to stakeholders and teammates before it hits production.
To Be Continued Part-12...
Recommended Articles
Thanks for visiting this page. Please follow and join us on LinkedIn, Facebook, Telegram, Quora, YouTube, Twitter, Pinterest, Tumbler, VK, and WhatsApp for regular updates.
Posts
No comments:
Post a Comment
Please do not enter any HTML. JavaScript or spam link in the comment box.