Design Patterns Interview Questions - Part 03

Design Patterns Interview Questions and Answers - Part 03

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:

Click Here To Watch Our Videos

Please read the complete C# Interview Questions and Answers article series here.

Introduction

This is the 3rd 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 and Principles Interview Questions and Answers -  Part 01

Design Patterns and Principles Interview Questions and Answers -  Part 02

Design Patterns Interview Questions - Part 03

Q18. What are the different Object-Oriented Design Principles?

Design Principles are a set of generalized pieces of advice or proven good coding practices that are used as rules of thumb when making design choices. Design Principles are more abstract and generalized. 

Software design principles represent a set of guidelines that helps us to avoid bad software design. The design principles are gathered by Robert Martin in the book "Agile Software Development: Principles, Patterns, and Practices". 

According to Robert Martin, there are 3 important characteristics of a bad design that should be avoided:

• Rigidity because rigid applications are hard to change as every change affects too many other parts of the system.  
• Fragility because when you make a change, unexpected parts of the system break.
• Immobility because it is difficult to reuse in other applications

The design principles will help you to create a clean and modular design, which would be easy to test, debug, and maintain in the future.

Types of Object-Oriented Design Principles:

There are different categories of design principles.

1. SOLID Principles:

SOLID Principles are the First Five Principles of Object-Oriented Design.  These SOLID Principles expose the Dependency Management aspects of Object-Oriented Design (OOD).

The SOLID Design Principles were first introduced by the famous Computer Scientist Robert Cecil Martin (Uncle Bob) in his paper "Design Principles and Design Patterns" in the year 2000. 

There are five SOLID Principles i.e Single Responsibility Principle, Open-Closed Principle, Liskov's Substitution Principle,  Interface Segregation Principle, Dependency Inversion Principle.

2. Package Cohesion Principle:

The next six principles are about packages. A package is a binary deliverable (JAR or DLL file). The first three package principles are about package cohesion. They tell us what to put inside packages:

• The Release Reuse Equivalency Principle (REP): The granule of reuse is the granule of release.
• The Common Closure Principle (CCP): Classes that change together are packaged together.
• The Common Reuse Principle (CRP): Classes that are used together are packaged together.

3. Package Coupling Principle:

The last three package principles are about the couplings between packages. They talk about metrics that evaluate the package structure of a system:

• The Acyclic Dependencies Principle (ADP): The dependency graph of packages must have no cycles.
• The Stable Dependencies Principle(SDP): Depend in the direction of stability.
• The Stable Abstractions Principle(SAP): Abstractness increases with stability.

4. DRY Principles:

DRY stands for "Don’t Repeat Yourself". This principle says that don’t write duplicate code, instead use Abstraction to abstract common things in one place. It will help to maintain the code.

5. Favor Composition over Inheritance:

There are two general ways to reuse the code you have already written, Inheritance and Composition, both have their own advantage and disadvantages, but, in general, you should always favor composition over inheritance, if possible.

Composition allows changing the behavior of a class at run-time by setting property during run-time and by using Interfaces to compose a class we use polymorphism which provides flexibility to replace with better implementation any time.

Please watch the Composition vs Inheritance video here for more details.

6. Programming for Interface not Implementation:

A programmer should always program for the interface and not for implementation this will lead to flexible code which can work with any new implementation of the interface. 

You should use interface type on variables, return types of a method, or argument type of methods like using SuperClass type to store object rather using SubClass.

7.  Delegation Principles:

This principle says that don’t do all stuff by yourself, delegate it to the respective class. The key benefit of this design principle is no duplication of code and pretty easy to modify behavior. Event delegation is an example of this principle, where an event is delegated to handlers for handling.

8. Encapsulate What Changes:

This principle says that encapsulate the code you expect or suspect to be changed in the future. It’s easy to test and maintain proper encapsulated code.

9. GRASP Principles:

The GRASP stands for General Responsibility Assignment Software Principles.   It is a set of nine fundamental principles in object design and responsibility assignment first published by Craig Larman in his 1997 book Applying UML and Patterns.

They are Information Expert, Creator, Controller, Low Coupling, High Cohesion, Indirection, Polymorphism, Pure Fabrication, and Protected Variations.

Q19. What are the SOLID Design Principles?

SOLID Principles are the First Five Principles of Object-Oriented Design.  These SOLID Principles expose the Dependency Management aspects of Object-Oriented Design (OOD).

The SOLID Design Principles were first introduced by the famous Computer Scientist Robert Cecil Martin (Uncle Bob) in his paper "Design Principles and Design Patterns" in the year 2000. But the SOLID acronym was introduced later around 2004 by Michael Feathers.

These SOLID Principles are used to create understandable, readable, and testable code that many developers can collaboratively work on. These SOLID Principles help to reduce the tight coupling between software components.

So SOLID is nothing but a mnemonic acronym of five broadly categorized principles. These are the Single Responsibility Principle, Open-Closed Principle, Liskov's Substitution Principle,  Interface Segregation Principle, Dependency Inversion Principle.

Please read the complete SOLID Principle article here for more details.

Q20. What is the Single Responsibility Principle (SRP)?

In the SOLID acronym, the first letter "S" represents the "Single Responsibility Principle" of Object-Oriented Design (OOD). The Single Responsibility Principle focuses on the responsibility or role of any function or module.

The Single Responsibility Principle is based on one class one responsibility, and one reason for the change. The Single Responsibility Principle states that a class should do only one thing and therefore it should have only one reason to change. 

According to Robert C. Martin, the Single-responsibility Principle (SRP) states that: "A class or module should have one, and only one, reason to be changed."

In other words: "There should never be more than one reason for a class to change"

  

The Single Responsibility Principle also dictates that "Gather together the things that change for the same reasons. Separate those things that change for different reasons".

Please read the complete Single Responsibility Principle here for more details.

Q21. What is the Open-Closed Principle (OCP)?

In the SOLID acronym, the second letter "O" represents the "Open Closed Principle". The Open-Closed Principle focuses on the behavior of a class or module in case of modification and extension. The Open-Closed Principle is the second SOLID Design Principle. 

The Open-Closed Principle said that classes should be open for extension and closed to modification. Here modification means changing the code of an existing class, and extension means adding new functionality.

According to Bertrand Meyer, the Open-Closed Principle states that: "Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification."

In other words: "Class should be extendable without modifying the class itself."

Please read the complete Open Closed Principle here for more details.

Q22. What is Liskov Substitution Principle (LSP)?

In the SOLID acronym, the third letter "L" represents the "Liskov Substitution Principle". The Liskov Substitution Principle focuses on the behavioral relationship between parent class and child class object. The Liskov Substitution Principle is applicable when there’s a supertype-subtype inheritance relationship by either extending a class or implementing an interface. 

Liskov's Substitution Principle is the third SOLID Design Principle. This principle is based on the "Design by Contract (DbC)" approach of software designing. This principle extends the Open-Closed Principle by focusing on the behavior of a SuperClass and its SubTypes.   The Liskov Substitution Principle states that subclasses should be substitutable for their base classes.

According to Barbara Liskov, this principle states: "Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T."

In other words: "If S is a subtype of type T, then objects of type T may be replaced with objects of type S without any breaking change."

This means that every subclass or derived class should be substitutable for their base or parent class.

Please read the complete Liskov Substitution Principle here for more details.

Q23. What is Interface Segregation Principle (ISP)?

In the SOLID acronym, the fourth letter "I" represents the "Interface Segregation Principle". Segregation means keeping things separated, and the Interface Segregation Principle is about separating the interfaces. This principle is related to the Single Responsibility Principle in that even interfaces also should have a single purpose.

The Interface Segregation Principle is the fourth SOLID Design Principle. The Interface Segregation Principle was first used and formulated by Robert C. Martin while consulting for Xerox to help them build the software for their new printer systems. 

Interface Segregation Principle splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. 

According to Robert C. Martin: "Clients should not be forced to depend upon interfaces that they do not use."

In other words: "Many client-specific interfaces are better than one general-purpose interface." 

The Interface Segregation Principle states that no client should be forced to depend on methods that it does not use. Therefore:

• No class should be forced to implement any method(s) of an interface they don’t use or are not related.
• Instead of creating large or fat interfaces create multiple smaller interfaces so that the clients (class) should only think about the methods that are of interest to them (related).

Please read the complete Interface Segregation Principle here for more details.

Q24. What is the Dependency Inversion Principle (DIP)? 

In the SOLID acronym, the 5th letter "D" represents the "Dependency Inversion Principle". In the object-oriented design, the Dependency Inversion Principle is a specific form of loosely coupled software modules. 

The Dependency Inversion Principle is the fifth and last SOLID Design Principle. The principle of Dependency Inversion refers to the decoupling of software modules.  The dependency inversion principle states that we need to rely on abstractions rather than concrete implementations.

The Dependency Inversion Principle (DIP) was introduced by Robert C. Martin. DIP suggests that high-level modules should not depend on low-level modules, both should depend on abstraction.  The Dependency Inversion Principle states that our classes should depend upon interfaces or abstract classes instead of concrete classes and functions. 

According to the Dependency Inversion Principle: "Depend upon abstractions, not concretions i.e Entities must depend on abstractions, not on concretions."

In other words: "The high-level module must not depend on the low-level module, both should depend on abstractions."

Robert C. Martin’s Dependency Inversion Principle consists of two parts:

• High-level modules should not depend on low-level modules. Both should depend on the same abstractions (interface).
• Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

Please read the complete Dependency Inversion Principle here for more details.

To Be Continued Part-04...

Recommended Articles

Static Class Interview Questions and Answers

Sealed Class Interview Questions and Answers

Sealed Method Interview Questions and Answers

C# Coding Interview Questions and Answers

Abstract Class vs Interface Interview Question

IDisposable Interface vs Finalizer in .Net

Singleton Design Pattern

SOLID Design Principles

Liskov Substitution Principle of SOLID

Dependency Inversion Principle of SOLID

Covariance vs Contravariance Feature of .Net Framework

Types of Constructors in C#

Static Class and Static Methods

Partial Class and Partial Methods

Abstract Class and Methods

Sealed Class and Sealed Methods

Static Polymorphism and Method Overloading

Dynamic Polymorphism and Method Overriding

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.