Tech Point Fundamentals

Friday, May 20, 2022

Design Patterns Interview Questions - Part 12

Design Patterns Interview Questions and Answers - Part 12

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 12th 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 12


Q89. What are the GRAPS Principles? 

GRASP stands for General Responsibility Assignment Software Patterns.  Apart from SOLID Principles,  there is another, less well-known set of rules regarding object-oriented programming called GRASP.  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.

Following is the list of 9 GRASP Principles that answers the fundamental programming questions.

1. Information Expert: 

What is a basic principle by which to assign responsibilities to objects? 

Assign responsibility to the class that has the information needed to fulfill it.



2. Creator: 

Who creates object A?

Assign class B the responsibility to create object A if one of these is true (more is better). B contains or compositely aggregates A. B has the initializing data for A. B closely uses A and B records A.

3. Controller:

What the first object beyond the UI layer receives and coordinates “controls” a system operation?

Assign the responsibility to an object representing one of these choices:

  • Represents the overall “system”, “root object”, device that the software is running within, or a major subsystem (these are all variations of a facade controller)
  • Represents a use case scenario within which the system operation occurs (a use case or session controller)



4. Low Coupling:

How to reduce the impact of change? How to support low dependency and increased reuse?

Assign responsibilities so that (unnecessary) coupling remains low. Use this principle to evaluate alternatives. 

Coupling is a measure of how one element is related to another. The higher the coupling, the greater the dependence of one element to another. 

The low coupling means our objects are more independent and isolated. If something is isolated we can change it not worrying that we have to change something else or whether we would break something



5. High Cohesion:

How to keep objects focused, understandable, manageable, and as a side effect support Low Coupling?

Assign a responsibility so that cohesion remains high. Use this to evaluate alternatives.
Cohesion is a measure of how strongly all responsibilities of the element are related. In other words, what is the degree to which the parts inside an element belong together? Classes with low cohesion have unrelated data and/or unrelated behaviors.

6. Indirection:

Where to assign a responsibility to avoid direct coupling between two or more things?

Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. This is where Mediator Pattern comes into play.



7. Polymorphism:

How handle alternatives based on type?

When related alternatives or behaviors vary by type (class), assign responsibility for the behavior (using polymorphic operations) to the types for which the behavior varies. In this context, the principle is strongly connected with (among others) Strategy patterns.

8. Pure Fabrication:

What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling but solutions offered by other principles are not appropriate?

Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept.

9. Protected Variations:

How to design objects, subsystems, and systems so that the variations or instability in these elements do not have an undesirable impact on other elements?

Identify points of predicted variation or instability, assign responsibilities to create a stable interface around them.



Q90. What is Dependency Hell Problem?

Dependency hell is a colloquial term for the frustration of some software users who have installed software packages that have dependencies on specific versions of other software packages. The dependency issue arises when several packages have dependencies on the same shared packages or libraries, but they depend on different and incompatible versions of the shared packages.

Dependency hell is a term used to define the problems faced by software developers, publishers, and users in general when the software or a software package is dependent on other software. Dependency hell occurs when software works abnormally or displays errors and bugs due to an integrated software/application developed by a third party. Dependency hell is a common problem found in software/applications that are built using an add-on software package or that rely on one for complete functionality.



The "dependency hell" often goes by a local specific name, generally the name of components.

  1. DLL Hell Problem: This is a form of dependency hell occurring on Microsoft Windows.
  2. JAR Hell Problem: This is a form of dependency hell occurring in the Java Runtime Environment before build tools like Apache Maven solved this problem back in 2004.
  3. RPM Hell Problem: This is a form of dependency hell occurring in the Red Hat distribution of Linux and other distributions that use RPM as a package manager.
  4. Extension Conflict Problem: It is a form of dependency hell occurring on the classic Mac OS.

Forms of Dependency Hell Problem: 

  • Too many dependencies
  • Multiple package managers
  • The package or version you need isn’t in your package manager
  • Monkey patching a dependency
  • Breaking changes on a minor or patch version.
  • Circular dependencies
  • Conflicting dependencies
  • The diamond dependency problem



Q91. What is Software Bloat Problem?

Software bloat is a process whereby successive versions of a computer program become perceptibly slower, use more memory, disk space or processing power, or have higher hardware requirements than the previous version, while making only dubious user-perceptible improvements or suffering from feature creep. 

The term "bloatware" is also used to describe unwanted pre-installed software or bundled programs. In computer programming, code bloat refers to the presence of program code (source code or machine code) that is perceived as unnecessarily long, slow, or otherwise wasteful of resources.

Library bloat refers to libraries that are declared or used in the build script while they are not necessary for executing the software application. A library that becomes bloated in a project is very likely to remain bloated in future evolutions of the project, which artificially increases maintenance effort since developers will maintain these bloated dependencies.



Q92. What is Technical Debt or Code Debt in Software Industry?

Technical Debt is also known as Design Debt or Code Debt. In software development, technical debt is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

If technical debt is not repaid, it can accumulate "interest" the same as normal monetary debt, making it harder to implement changes. However technical debt is not necessarily a bad thing and sometimes is required to move projects forward. 



Q93. What is the Big Ball of Mud Problem in the Software Industry?

A big ball of mud is a software system that lacks a perceivable architecture. Although undesirable from a software engineering point of view, such systems are common in practice due to business pressures, developer turnover, and code entropy. 

They are a type of design anti-pattern. The term was popularized in Brian Foote and Joseph Yoder's 1997 paper of the same name.



Q94. What is Spaghetti Code? Why do they happen?

Spaghetti code is a pejorative phrase for unstructured and difficult-to-maintain source code. Spaghetti code can be caused by several factors, such as volatile project requirements, lack of programming style rules, and software engineers with insufficient ability or experience. 

In a 1980 publication by the United States National Bureau of Standards, the phrase spaghetti program was used to describe older programs having "fragmented and scattered files".

For example, a code that overuses GOTO statements rather than structured programming constructs, resulting in convoluted and unmaintainable programs, is often called spaghetti code.

Spaghetti code can also describe an anti-pattern in which object-oriented code is written in a procedural style, such as by creating classes whose methods are overly long and messy or forsaking object-oriented concepts like polymorphism. The presence of this form of spaghetti code can significantly reduce the comprehensibility of a system.



Q95. What is SONARQube?

SonarQube is an open-source platform developed by SonarSource for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells. It can be used in 20+ programming languages. 

SonarQube offers reports on duplicated code, coding standards, unit tests, code coverage, code complexity, comments, bugs, and security recommendations. SonarQube is available for free under the GNU Lesser General Public License. SonarQube can record metrics history and provides evolution graphs. 

SonarQube provides fully automated analysis and integration with Maven, Ant, Gradle, MSBuild, and continuous integration tools like Jenkins, Azure DevOps, Bamboo, etc. Some most common supporting languages include Java, C#, C, C++, JavaScript, TypeScript, Python, Go, Swift, COBOL, Apex, PHP, Kotlin, Ruby, Scala, HTML, CSS, ABAP, Flex, Objective-C, PL/I, PL/SQL, RPG, T-SQL, VB.NET, VB6, and XML. 

SonarQube integrates with Eclipse, Visual Studio, Visual Studio Code, and IntelliJ IDEA development environments through the SonarLint plug-ins, and also integrates with external tools like LDAP, Active Directory, GitHub, and others. SonarQube is expandable with the use of plug-ins.





To Be Continued Part-13...


Recommended Articles






Thanks for visiting this page. Please follow and join us on LinkedInFacebookTelegramQuoraYouTubeTwitterPinterestTumbler, and VK, for regular updates.

    



External Reference:


  1. Wikipedia
  2. RefacturingGuru
  3. SourceMaking
  4. Grasp


No comments:

Post a Comment

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