Design Patterns Interview Questions and Answers - Part 06
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 6th 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 06
Q41. What is Repository Pattern? What is the difference between the Repository Pattern and Entity Framework?
Repository Pattern is an abstraction of the Data Access Layer. It hides the details of how exactly the data is saved or retrieved from the underlying data source. The details of how the data is stored and retrieved are in the respective repository.
The Repository Pattern become most popular as it was first introduced as a part of Domain-Driven Design in 2004. A repository performs the tasks of an intermediary between the domain model layers and data mapping, acting in a similar way to a set of domain objects in memory. Client objects declaratively build queries and send them to the repositories for answers.
Repositories are classes or components that encapsulate the logic required to access data sources. They centralize common data access functionality, providing better maintainability and decoupling the infrastructure or technology used to access databases from the domain model layer. The Repository pattern is a well-documented way of working with a data source.
A repository encapsulates a set of objects stored in the database and operations that can be performed on them, providing a way that is closer to the persistence layer. A repository allows you to populate data in memory that comes from the database in the form of domain entities. Once the entities are in memory, they can be changed and then persisted back to the database through transactions.
The Repository Pattern, as well as the Unit of Work Pattern, allows creating an abstraction layer between the data access layer and the business logic layer of an application. The purpose of creating this layer is to isolate the data access layer so that the changes we may operate cannot affect the business logic layer directly.
Repository Pattern Interface specifies what operations (i.e methods) are supported by the repository and what data is required for each of the operations. The Repository Pattern allows us to create an abstraction layer between the data access layer and the business logic layer of an application. It offers a more loosely coupled approach to data access.
Repository Pattern vs Entity Framework:
EF is an implementation of the Repository Pattern and Unit of Work pattern itself. Entity Framework already implements a repository pattern. DbContext is your UoW and each DbSet is the repository. So what is the use of a repository pattern in an Entity Framework project?
In large systems, where you have data coming from different sources (database/XML/web service), it is good to have an abstraction layer. The Repository pattern works well in this scenario. I do not think that the Entity Framework is enough abstraction to hide what goes on behind the scenes.
Another advantage of abstracting the DbContext with a Repository is unit-testability. You can have your IRepository interface which has 2 implementations, one (the real Repository) which uses DbContext to talk to the database, and the second, FakeRepository which can return in-memory objects/mocked data. This makes your IRepository unit testable, thus other parts of code which use IRepository.
Q42. What is the difference between the Repository Pattern and the legacy Data Access Class (DAL) Pattern?
A data access object directly performs data access and persistence operations against storage. A repository marks the data with the operations you want to perform in the memory of a unit of work object (as in EF when using the DbContext class), but these updates aren't performed immediately to the database.
A unit of work is referred to as a single transaction that involves multiple inserts, updates, or delete operations. For a specific user action, such as registration on a website, all the insert, update, and delete operations are handled in a single transaction. This is more efficient than handling multiple database transactions in a chattier way.
These multiple persistence operations are performed later in a single action when your code from the application layer commands it. The decision about applying the in-memory changes to the actual database storage is typically based on the Unit of Work pattern. In EF, the Unit of Work pattern is implemented as the DbContext.
Q43. What is Service Locator Pattern (SLP)? When service locator pattern is used?
The Service Locator Pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator", which on request returns the information necessary to perform a certain task.
The SLP is a relatively old pattern that was very popular with Java2E. The main purpose of this pattern is to improve the modularity of the application by removing the dependency between the client and the implementation of an interface.
The purpose of the Service Locator pattern is to return the service instances on demand. The ServiceLocator is responsible for returning instances of services when they are requested by the service consumers or the service clients. This is useful for decoupling service consumers from concrete classes.
SLP acts as a central registry that provides implementations of different interfaces. By doing that, your component that uses an interface no longer needs to know the class that implements the interface. Instead of instantiating that class itself, it gets an implementation from the service locator.
Components of SLP:
Client: A client object is a service consumer which is responsible for invoking the request from the service locator.
Service Locator: Service Locator acts as a simple run-time linker. This allows code to be added at run-time without recompiling the application, and in some cases without having to even restart it. It is a communication entry point for returning the services from the cache as well.
Cache: It is an object for storing service references to reuse them later.
Initializer: It creates and registers references to services in the cache.
Service: The Service component represents the original services or their implementation
The original service object is looked up by the locator and returned on demand.
Q44. What is Intercepting Filter Pattern (IFP) or Intercepting Pattern (IP)? When can you use the Intercepting Pattern?
Intercepting Filter is a Java2E pattern that creates pluggable filters to process common services in a standard manner without requiring changes to core request processing code. Intercepting Pattern improved reusability and flexibility.
The filters intercept incoming requests and outgoing responses, allowing preprocessing and post-processing, and these filters can be added or removed unobtrusively without changing existing code. This pattern applies reusable processing transparently before and after the actual request execution by the front and page controllers.
An Intercepting Filter Pattern is useful if you want to intercept and manipulate a request and response before and after the request is processed. It provides central control with loosely coupled handlers. It improves reusability.
The Intercepting Filter design pattern is used when we want to do some pre-processing or post-processing with requests or responses of the application. Filters are defined and applied to the request before passing the request to the actual target application.
Components of Intercepting Filter Pattern:
Filter: It performs certain tasks prior to or after the execution of a request by the request handler.
Filter Chain: The filter Chain carries multiple filters and helps to execute them in a defined order on target.
Target: Target object is the request handler.
Filter Manager: The Filter Manager manages the filters and Filter Chain.
Client: The client is the object who sends requests to the Target object.
Q45. What is UML (Unified Modeling Language)?
UML is a modeling language in the field of software engineering which aims to set standard ways to visualize the design of a system. UML guides the creation of multiple types of diagrams such as interaction, structure, and behavior diagrams. A sequence diagram is the most commonly used interaction diagram.
Interaction Diagram: An interaction diagram is used to show the interactive behavior of a system. Since visualizing the interactions in a system can be a cumbersome task, we use different types of interaction diagrams to capture various features and aspects of interaction in a system.
Sequence Diagrams: A sequence diagram simply depicts the interaction between objects in sequential order. It is also known as event diagrams or event scenarios. Sequence diagrams describe how and in what order the objects in a system function. These diagrams are widely used by businessmen and software developers to document and understand requirements for new and existing systems.
Behavioural Diagram: The behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a system. Behavioral Diagrams depict the elements of a system that are dependent on time and that convey the dynamic concepts of the system and how they relate to each other.
Q46. What are ERD and ERM? What is the difference between UML and ERD diagrams?
ERD stands for Entity Relationship Diagram. ERD is a diagram that displays the relationship of entity sets stored in a database. It helps to explain the logical structure of databases.
ER diagrams are created based on three basic concepts: entities, attributes, and relationships. ERD is not the same as a flowchart. The purpose of ER Diagram is to represent the entity framework infrastructure.
ER Diagrams contain different symbols that use rectangles to represent entities, ovals to define attributes, and diamond shapes to represent relationships.
ER Model stands for Entity-Relationship Model is a high-level conceptual data model diagram. ER model helps to systematically analyze data requirements to produce a well-designed database. The ER Model represents real-world entities and the relationships between them. Creating an ER Model in DBMS is considered a best practice before implementing your actual database.
UML vs ERD:
- UML stands for Unified Modelling Language while ER Diagram stands for Entity Relationship Diagram.
- UML is a modeling language that visually represents a software system. On the other hand, ER diagram is a pictorial representation of the real-world entities and their relationships with each other.
- UML is the parent of an ER diagram while ERD is a subset or child of UML.
- UML is used to design the entire software while ERD is used to design only the databases.
- UML has use cases and workflows while URD has entities, attributes, and relationships.
- UML involves a final and an initial state but URD has no state representation.
- UML uses circles, rectangles with round corners, arrow heads, diamonds, rectangular bars, etc while URD uses only 3 shapes i.e oval, rectangle, and diamond.
Q47. What is a Design Smell or Code Smell?
In computer programming, a code smell is a characteristic in the source code of a program that possibly indicates a deeper problem. "Smells are certain structures in the code that indicate a violation of fundamental design principles and negatively impact design quality.
The term was popularised by Kent Beck on WardsWiki in the late 1990s. Usage of the term increased after it was featured in the 1999 book Refactoring: Improving the Design of Existing Code by Martin Fowler. It is also a term used by agile programmers.
Code smells are usually not bugs; they are not technically incorrect and do not prevent the program from functioning. Instead, they indicate weaknesses in design that may slow down development or increase the risk of bugs or failures in the future. Bad code smells can be an indicator of factors that contribute to technical debt.
Types of Code Smell: There are different types of smell that involve both code smell and design smell.
1. Application-Level Smells:
Mysterious Name: functions, modules, variables, or classes that are named in a way that does not communicate what they do or how to use them.
Duplicated Code: identical or very similar code that exists in more than one location.
Shotgun Surgery: a single change that needs to be applied to multiple classes at the same time.
2. Class-Level Smells:
God Class: a class that has grown too large.
Feature Envy: a class that uses methods of another class excessively.
Inappropriate Intimacy: a class that has dependencies on implementation details of another class.
Refused Bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class. See Liskov substitution principle.
Excessive use of Literals: these should be coded as named constants, to improve readability and to avoid programming errors.
Orphan Variable or Constant Class: a class that typically has a collection of constants that belong elsewhere where those constants should be owned by one of the other member classes.
3. Method-Level Smells:
Parameter Abusing: a long list of parameters is hard to read, and makes calling and testing the function complicated.
Long Method: a method, function, or procedure that has grown too large.
Excessively Long Identifiers: in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture.
Excessively Short Identifiers: the name of a variable should reflect its function unless the function is obvious.
Excessive Return of Data: a function or method that returns more than what each of its caller's needs.
Excessive Comments: a class, function, or method has irrelevant or trivial comments. A comment on an attribute setter/getter is a good example.[citation needed]
God Code Line: A line of code that is too long, making the code difficult to read, understand, debug, refactor, or even identify possibilities of software reuse.
Q48. What is a code rot problem or software rot?
According to the wiki- "Software rot, also known as bit rot, code rot, software erosion, software decay, or software entropy is either a slow deterioration of software quality over time or its diminishing responsiveness that will eventually lead to software becoming faulty, unusable, or in need of an upgrade. This is not a physical phenomenon: the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides."
Data rot is easy to understand. This concept refers to data degradation, which corrupts information and makes it unusable. The data rot will happen over time. It is a natural process that cannot be avoided. The same thing happens to the software as well.
There are different reasons for the code rot problem like environmental change, unused code, rarely updated code, onceability, etc.
To Be Continued Part-07...
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.