0% found this document useful (0 votes)
49 views9 pages

OOP and Design Pattern - Q and A

Common oop Q and A for senior software engineer interview

Uploaded by

Benny Susanto
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
49 views9 pages

OOP and Design Pattern - Q and A

Common oop Q and A for senior software engineer interview

Uploaded by

Benny Susanto
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 9

Table of Contents

OOP.................................................................................................................................................2
OOP Characteristics.......................................................................................................................2
Benefits of Structured Code.............................................................................................................2
Analysis and Design........................................................................................................................2
OOAD..............................................................................................................................................3
UML.................................................................................................................................................4
Design Patterns...............................................................................................................................4
GRASP.............................................................................................................................................5
SOLID..............................................................................................................................................6
GoF..................................................................................................................................................6
GoF Patterns...................................................................................................................................7
Dependency Inversion.....................................................................................................................8
OOP

Q: What is OOP?
A: OOP is a programming paradigm based on the concept of objects. These objects have
state and behavior, and they collaborate between each other’s.

References:

Object-oriented programming (OOP) is a programming paradigm based on the concept


of objects, which can contain data and code: data in the form of fields (often known
as attributes or properties), and code in the form of procedures (often known as methods). In
OOP, computer programs are designed by making them out of objects that interact with one
another. (Wikipedia).

OOP Characteristics

Q: Mention some basic characteristics of Object-Oriented Programming


A: OOP has characteristics as listed below

- Abstraction
- Encapsulation
- Inheritance
- Polymorphism
- Modularization

Benefits of Structured Code

Q: Mention some things that we want to achieve in a structured code


A: Some of the things that we want to achieve are

- Reusability
- Flexibility
- Extensibility
- Easy to maintain

Analysis and Design


Q: What is analysis and design?
A: Analysis is the activity to observe something to gain a lot of knowledge and information
about something. Design is an activity to create a conceptual solution without focusing on
too much low levels detail and implementation

References:

Analysis emphasizes an investigation of the problem and requirements, rather than a solution.
For example, if a new online trading system is desired, how will it be used? What are its
functions?

"Analysis" is a broad term, best qualified, as in requirements analysis (an investigation of the
requirements) or object-oriented analysis (an investigation of the domain objects).

Design emphasizes a conceptual solution (in software and hardware) that fulfils the
requirements, rather than its implementation. For example, a description of a database schema
and software objects. Design ideas often exclude low-level or "obvious" detail so obvious to the
intended consumers. Ultimately, designs can be implemented, and the implementation (such as
code) expresses the true and complete realized design.

(Applying UML and Patterns)

OOAD

Q: What is object-oriented analysis and design?


A: Object oriented analysis design is an activity during a software development process
where we try to understand the problem in the real world in the concept of objects. Object
oriented analysis design is an activity where we make the solution based on the concept of
objects.

References:

During object-oriented analysis there is an emphasis on finding and describing the objects or
concepts in the problem domain. For example, in the case of the flight information system,
some of the concepts include Plane, Flight, and Pilot.

During object-oriented design (or simply, object design) there is an emphasis on defining
software objects and how they collaborate to fulfill the requirements. For example, a Plane
software object may have a tailNumber attribute and a getFlightHistory method.

(Applying UML and Patterns)


OOAD provides a way to reduce well-designed applications that satisfy both the customers
and programmers (Head First Object Oriented Analysis and Design)
Object-oriented analysis and design (OOAD) is a technical approach for analyzing and
designing an application, system, or business by applying object-oriented programming, as
well as using visual modeling throughout the software development process to guide
stakeholder communication and product quality. (Wikipedia)

UML

Q: What is UML
A: UML is a visual language to provide a standard way to document of a system

References:

The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems (Applying UML and Patterns)
The unified modeling language (UML) is a general-purpose visual modeling language that is
intended to provide a standard way to visualize the design of a system (Wikipedia)

Design Patterns

Q: What is design pattern?


A: In OOP, it’s a well-known conceptual / high level solution to a certain problem

References:

In OO design, a pattern is a named description of a problem and solution that can be applied
to new contexts; ideally, a pattern advises us on how to apply its solution in varying
circumstances and considers the forces and trade-offs. Many patterns, given a specific
category of problem, guide the assignment of responsibilities to objects

New pattern should be considered an oxymoron if it describes a new idea. The very term
"pattern" suggests a long-repeating thing. The point of design patterns is not to express new
design ideas. Quite the opposite, great patterns attempt to codify existing tried-and true
knowledge, idioms, and principles; the more honed, old, and widely used, the better.

(Applying UML and Patterns)

 Patterns show you how to build systems with good 00 design qualities.
 Patterns are proven oriented experience
 Patterns don't give you code, they give you general solutions at design problems. You
apply them at your specific application.
 Patterns aren't invented, they are discovered
 Most patterns and principles address issues of change in software.
 Most patterns allow some part of a system to vary independently of al other parts.
 Shared pattern vocabularies are POWERFUL. When you communicate with another
developer or your team using patterns, you are communicating not just a pattern name
but a whole set of qualities, characteristics and constraints that the pattern represents.
 Patterns allow you to say more with less. When you use a pattern in a description,
other developers quickly know precisely the design you have in mind.
 Talking at the pattern level allows you to stay "in patterns allows you to keep the
discussion at the design level, without having to dive down to the nitty gritty details of
implementing objects and classes.
 Shared vocabularies can turbo charge your development team. A team well versed in
design patterns can move more quickly with less room for misunderstanding.
 Shared vocabularies encourage more junior developers to get up to speed. Junior
developers look up to experienced developers. When senior developers make use of
design patterns, junior developers also become motivated to learn them. Build
community of pattern users at your organization.
(Head First Design Patterns)
In software engineering, a design pattern describes a relatively small, well-defined aspect
(i.e. functionality) of a computer program in terms of how to write the code. Using a pattern
is intended to leverage an existing concept rather than re-inventing it. This can decrease the
time to develop software and increase the quality of the resulting program. (Wikipedia).

GRASP

Q: What is GRASP? and mention some of it


A: GRASP is a set of "nine fundamental principles in object design and responsibility
assignment

Some of the GRASP patterns are:


 Creator
 Informational Expert
 Controller
 Low Coupling
 High Cohesion
 Polymorphism
 Pure Fabrication
 Indirection
 Protected Variation
References:

GRASP defines nine basic OO design principles or basic building blocks in design. (Applying
UML and Patterns)
GRASP stands for General Responsibility Assignment Software Patterns (or Principles),
abbreviated GRASP, 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. (Wikipedia).

SOLID

Q: What is SOLID? and what are SOLID principles?


A: SOLID is a design principle in programming to make the software achieve some positive
attributes (reusable, flexible, extensible and easy to maintain)

The 5 SOLID principles are:


- SRP (Single Responsibility Principle)
- OCP (Open Closed Principle)
- LSP (Liskov Substitution Principle)
- ISP (Inteface Segregation Principle)
- DIP (Dependency Inversion Principle)

References:

The SOLID principles tell us how to arrange our functions and data structures into classes,
and how those classes should be interconnected. The use of the word “class” does not imply
that these principles are applicable only to object-oriented software. A class is simply a
coupled grouping of functions and data. Every software system has such groupings, whether
they are called classes or not. The SOLID principles apply to those groupings (Clean
Architecture)

In software programming, SOLID is a mnemonic acronym for five design principles intended
to make object-oriented designs more understandable, flexible, and maintainable
(Wikipedia).

GoF

Q: What is GoF ?
A: GoF stands for Gang of Four, it contains 23 patterns for OO Design.
The idea of named patterns in software comes from Kent Beck (also of Extreme Programming
fame) in the mid 1980s. However, 1994 was a major milestone in the history of patterns, OO
design, and software design books: The massive-selling and hugely influential book Design
Patterns [GHJV95] was published, authored by Gamma, Helm, Johnson, and Vlissides. The
book, considered the "Bible" of design pattern books, describes 23 patterns for OO design,
with names such as Strategy and Adapter. These 23 patterns, authored by four people, are
therefore called the Gang of Four(or GoF) design patterns. (Applying UML and Patterns)

GoF Patterns

Q: Mention some of GpF patterns


A: Below are the G-F patterns

 Creational
Creational patterns are ones that create objects, rather than having to instantiate objects
directly. This gives the program more flexibility in deciding which objects need to be
created for a given case.
o Abstract factory groups object factories that have a common theme.
o Builder constructs complex objects by separating construction and representation.
o Factory method creates objects without specifying the exact class to create.
o Prototype creates objects by cloning an existing object.
o Singleton restricts object creation for a class to only one instance.
 Structural
Structural patterns concern class and object composition. They use inheritance to
compose interfaces and define ways to compose objects to obtain new functionality.
o Adapter allows classes with incompatible interfaces to work together by
wrapping its own interface around that of an already existing class.
o Bridge decouples an abstraction from its implementation so that the two can vary
independently.
o Composite composes zero-or-more similar objects so that they can be
manipulated as one object.
o Decorator dynamically adds/overrides behavior in an existing method of an
object.
o Facade provides a simplified interface to a large body of code.
o Flyweight reduces the cost of creating and manipulating a large number of similar
objects.
o Proxy provides a placeholder for another object to control access, reduce cost,
and reduce complexity.
 Behavioral
Most behavioral design patterns are specifically concerned with communication between
objects.
o Chain of responsibility delegates commands to a chain of processing objects.
o Command creates objects that encapsulate actions and parameters.
o Interpreter implements a specialized language.
o Iterator accesses the elements of an object sequentially without exposing its
underlying representation.
o Mediator allows loose coupling between classes by being the only class that has
detailed knowledge of their methods.
o Memento provides the ability to restore an object to its previous state (undo).
o Observer is a publish/subscribe pattern, which allows a number of observer
objects to see an event.
o State allows an object to alter its behavior when its internal state changes.
o Strategy allows one of a family of algorithms to be selected on-the-fly at runtime.
o Template method defines the skeleton of an algorithm as an abstract class,
allowing its subclasses to provide concrete behavior.
o Visitor separates an algorithm from an object structure by moving the hierarchy
of methods into one object.

Dependency Inversion

Q: What is Dependency Inversion, Dependency Injection and Inversion of Control


A: Dependency Inversion, Dependency Injection and Inversion of Control are related but
distinct concepts in software design, often discussed within the context of object-oriented
programming and design principles.

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle is one of the five SOLID principles of object-oriented
design. It states:
 High-level modules should not depend on low-level modules. Both should depend on
abstractions (e.g., interfaces).
 Abstractions should not depend on details. Details should depend on abstractions.

In essence, this principle is about reversing the direction of dependency to follow abstraction
rather than concrete implementations. The goal is to reduce the coupling between different parts
of a system and make the code more flexible and maintainable.

Inversion of Control (IoC)


Inversion of Control is a broader concept that describes a design in which the flow of control of a
program is inverted compared to traditional procedural programming. Rather than the
programmer controlling the flow of the application, the framework or runtime controls it. IoC
can be implemented in various ways, including through:
 Dependency Injection: Where an object receives its dependencies from an external source
rather than creating them itself.
 Service Locator: Where an object looks up dependencies from a central registry or
locator.
 Event-driven architectures: Where the flow of the program is determined by events and
listeners rather than a main control loop

Dependency Injection (DI)


Dependency Injection (DI) is a design pattern used in object-oriented programming to
achieve Inversion of Control (IoC) between classes and their dependencies. DI allows an
object to receive its dependencies from an external source rather than creating them
itself. This helps in making the system more modular, testable, and maintainable by
promoting loose coupling between classes.

Key Concepts of Dependency Injection

1. Dependencies: These are the objects that a class needs to function. For instance, if a
service class requires a repository to fetch data, the repository is a dependency of the
service.

2. Injection: The process of providing the dependencies to a class, rather than the class
creating the dependencies itself.

Types of Dependency Injection:

 Constructor
 Setter
 Field

Relationship Between DIP, DI and IoC


While Dependency Inversion Principle and Inversion of Control are not the same, they are
related:

 DIP is a specific principle aimed at decoupling high-level and low-level components


through abstraction.
 IoC is a broader pattern or principle that can be used to achieve DIP
 DI is a design pattern to achieve IoC

You might also like