OOP and Design Pattern - Q and A
OOP and Design Pattern - Q and A
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:
OOP Characteristics
- Abstraction
- Encapsulation
- Inheritance
- Polymorphism
- Modularization
- Reusability
- Flexibility
- Extensibility
- Easy to maintain
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.
OOAD
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.
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
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.
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
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
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
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
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.
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.
Constructor
Setter
Field