Tech Point Fundamentals

Friday, March 25, 2022

Design Patterns Interview Questions - Part 04

Design Patterns Interview Questions and Answers - Part 04

design-pattern-interview-questions



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 4th part of this Design Patterns and Principles Interview Questions and Answers article series. Each part contains eight 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 04


Q25. What is Inversion of Control (IoC)? What is the difference between the Dependency Inversion Principle and IoC?

In Software Engineering, IoC is a programming technique that allows run-time object coupling binding to occur by a framework where the binding is otherwise not known at compile time using static analysis. 

Inversion of Control is a pattern in which the control of the flow in the application is reversed. With IoC, the flow of the control is transferred to an external framework or container. 

The IoC principle helps in designing loosely coupled classes that make them more testable, maintainable, extensible, and modular. It is used to invert different kinds of controls in object-oriented design to achieve loose coupling.

The term was used by Michael Mattsson in a thesis, taken from there by Stefano Mazzocchi and popularized by him in 1999 in a defunct Apache Software Foundation project, Avalon, then further popularized in 2004 by Robert C. Martin and Martin Fowler.



There are multiple IoC implementation techniques like Dependency Injection, Service Locator Pattern, Strategy Design Pattern, etc. Please read more here.

Ioc


Both Inversion of Control (IoC) and Dependency Inversion Principle (DIP) are the high-level Inversion Principles. So the ultimate goal of both IoC and DIP is the same i.e decoupling. In 2004, Martin Fowler published an article on Dependency Injection (DI) and Inversion of Control (IoC).

The Dependency Inversion Principle (DIP) is neither Dependency Injection (DI) nor Inversion of Control (IoC). Dependency Inversion is about the shape of the object upon which the code depends. 

The Inversion of Control (IoC) is about who initiates the call. If your code initiates a call, it is not IoC, if the container/system/library calls back into code that you provided it, is it IoC.




Q26. What is the IoC Container? What is the difference between IoC and IoC containers? 

IoC Container is a framework that provides the Dependency Injection features. The IoC container is used to manage automatic dependency injection throughout the application so that we as programmers do not need to put more time and effort into it.

There are various IoC containers available such as Unity, Autofac, Ninject, Castle Windsor, StructureMap, DryIoc, etc. These IoC containers create an object of the specified class and inject all the dependent objects at run time and also dispose them at the appropriate time.  



These IoC containers make the developers' life easy so that they don't have to create and manage objects manually. Each and every IoC container manages the scope and lifetime of objects of all the dependencies as well that it resolves using lifetime managers. For example Transient, Singleton, PerInstance, etc.

IoC-Container

We cannot achieve loosely coupled classes by using IoC alone. Along with IoC, we also need to use DIP, DI, and IoC containers. Please read more here.




Q27. What is Dependency Injection (DI)? What problems does Dependency Injection solve? How the DI is different from Inversion of Control?

Dependency Injection (DI) is a design pattern used to implement IoC.  Dependency Injection (DI) is a way that implements the IoC principle to invert the creation of dependent objects. Dependency Injection is about how one object knows about another, dependent object. 

Dependency Injection (DI) is about how one object acquires a dependency. When a dependency is provided externally, then the system is using DI. Please read more here.



It allows the creation of dependent objects outside of a class and provides those objects to a class through different ways.  By using DI, we move the creation and binding of the dependent objects outside of the class that depends on them. So DI is just a way to achieve IoC.

DI

There are different ways of injecting the dependency (DI) like Constructor Dependency Injection, Interface Dependency Injection, Method  Parameter Dependency Injection, Setter Property  Dependency Injection. 

The Dependency Injection Pattern involves 3 different types of classes. A Client Class (Dependent Class) which depends on the service class, a Service Class (dependency) that provides service to the client class, and an Injector Class that injects the service class object into the client class.



Q28. What is the difference between the Dependency Injection (DI) and Service Locator Patterns (SLP)?

Both DI and Service Locator Pattern implementations provide the fundamental decoupling. In both cases application code is independent of the concrete implementation of the service interface. The important difference between the two patterns is about how that implementation is provided to the application class.

With service locator, the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.



The key difference is that with a Service Locator every user of a service has a dependency to the locator. The locator can hide dependencies to other implementations, but you do need to see the locator. So the decision between locator and injector depends on whether that dependency is a problem.

Service locator is also a design pattern wherein there will be a central place where we will be having all of the required dependencies dumped and whatever classes want dependencies can ask the service locator to give those dependencies to them.

Dependency injection is nothing but injecting the dependencies to the class needed. Giving the class all of its dependencies somehow so that the class which requires those dependencies does not have to worry about those.



Q29. What is GOD Class or GOD Object and why should we avoid it?

In object-oriented programming, a God object is an object that references a large number of distinct types, has too many unrelated or uncategorized methods, or has some combination of both. A God Object or God Class is a data structure that does too many things and knows too much. 

The God object is an example of an anti-pattern and a code smell. The main problem with a God Object is its multiple functionalities or responsibilities concentrated in a single object or class.

Due to its size, this leads us to software difficult to maintain, extend, use, test, and integrate with other parts of our system. The Single Responsibility Principle or SRP can help us to avoid this anti-pattern from our design or code base.



Problems of GOD Object:

  1. God Class and God objects create tight coupling between unrelated code which becomes difficult to enhance and maintain in the future.
  2. The SRP principle is not followed by the GOD Class.
  3. The GOD class and objects lack the modularization concept which hinders code reusability.
  4. Since different independent code logics are intertwined in God classes and God objects testing of each functionality separately becomes difficult.
  5. The size of the code of the GOD class increases which makes it unnecessarily complex. 



Q30. What is Anti-Pattern? Can you give me some pattern names that are considered anti-pattern?

The term anti-pattern coined in 1995 by computer programmer Andrew Koenig, was inspired by the book Design Patterns, which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective.

The term was popularized three years later by the book AntiPatterns, which extended its use beyond the field of software design to refer informally to any commonly reinvented but bad solution to a problem.

In software, an anti-pattern is a term that describes how NOT to solve recurring problems in your code. Anti-patterns are considered bad software design and are usually ineffective or obscure fixes.  They generally also add "technical debt" - which is code you have to come back and fix properly later.



An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences. An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. Following are the most common anti-patterns:

  1. Singleton Pattern
  2. God Object
  3. ORM Pattern
  4. Service Locator Pattern
  5. Call Super (Requiring subclasses to call a superclass's overridden method)
  6. Circular Dependency
  7. Circle–Ellipse Problem



Q31. What is Pseudocode? Why to use Pseudocode in the software industry?

In computer science, pseudocode is a plain language description of the steps in an algorithm or another system. Pseudocode often uses structural conventions of a normal programming language but is intended for human reading rather than machine reading. Pseudocode is an artificial and informal language that helps programmers develop algorithms. Pseudocode is a "text-based" algorithmic design tool. 

In the initial state of solving a problem, it helps a lot if we could eliminate the hassle of having to be bound by the syntax rules of a specific programming language when we are designing or validating an algorithm. Pseudocode is often used in all various fields of programming, whether it be app development, data science, or web development. Pseudocode is a technique used to describe the distinct steps of an algorithm in a manner that is easy to understand for anyone with basic programming knowledge.



Although pseudocode is a syntax-free description of an algorithm, it must provide a full description of the algorithm’s logic so that moving from it to implementation should be merely a task of translating each line into code using the syntax of any programming language.

Why Pseudocode?

  1. Better readability. 
  2. Act as a start point for documentation. 
  3. A good middle point between flowchart and code. 
  4. Ease up code construction.
  5. Easier bug detection and fixing.



Components of a Pseudocode:

SEQUENCE:  It represents linear tasks sequentially performed one after the other.

WHILE: It is a loop with a condition at its beginning.

REPEAT-UNTIL: It is a loop with a condition at the bottom.

FOR: It is another way of looping.

IF-THEN-ELSE: It is a conditional statement changing the flow of the algorithm.

CASE: It is the generalization form of IF-THEN-ELSE.




Q32. What is Data Access Object (DAO) Pattern? 

Data Access Object Pattern or DAO pattern is used to separate low-level data accessing API or operations from high-level business services. 

DAO provides an abstract interface to some type of database or other persistence mechanisms. It separates what data access the application needs, in terms of domain-specific objects and data types (the public interface of the DAO), from how these needs can be satisfied with a specific DBMS, database schema, etc. (the implementation of the DAO).

The Data Access Object (DAO) pattern is a structural pattern that allows us to isolate the application or business layer from the persistence layer (Database or another persistent layer) using an abstract API. 



The API hides all the complexity of performing CRUD operations in the underlying storage mechanism. This permits both layers to evolve separately without knowing anything about each other.

The Data Access Object Pattern involves three things:

DAO Interface: This interface defines the standard operations to be performed on a model object(s).

DAO Concrete Class: This class implements the above DAO interface. This class is responsible to get data from a data source which can be a database / XML or any other storage mechanism.

DAO Model Object: This object is a simple POJO containing get/set methods to store data retrieved using DAO class.


To Be Continued Part-05...


Recommended Articles






Thanks for visiting this page. Please follow and join us on LinkedInFacebookTelegramQuoraYouTubeTwitterPinterestTumblerVK, and WhatsApp for regular updates.

    

No comments:

Post a Comment

Please do not enter any HTML. JavaScript or spam link in the comment box.