Scribd
Upload
3 views

Design Patterns

The document discusses various design patterns and principles, including the SOLID principles: Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP). Each principle emphasizes the importance of modularity, abstraction, and separation of concerns in software design. Additionally, it introduces the Singleton pattern, which restricts a class to a single instance and provides a global access point to that instance.

Uploaded by

Varun
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
3 views

Design Patterns

The document discusses various design patterns and principles, including the SOLID principles: Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP). Each principle emphasizes the importance of modularity, abstraction, and separation of concerns in software design. Additionally, it introduces the Singleton pattern, which restricts a class to a single instance and provides a global access point to that instance.

Uploaded by

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

Design Patterns

Solid
https://www.freecodecamp.org/news/solid-principles-single-responsibility-principle-explained/

SRP
Classes should be more cohesive and should have less coupling.
As per SRP, function which change together should exist together.
For example, We should have separate class for handing data and healthcheck in UHC. Separate
class for configuration.

We need to segegrate only when class are bond to change and may cause ridity and code
duplication.

OCP
Class core behavior should not change and it can only be extended.
It means add any functionality, we have to make changes at lot of places and it could also
be in core functionality. So if we need to add new feature, we may have to reship whole
application again.
By applying concept of abstract, we can add more functionality and client can call new
methods at run time. New subclass can implement this abstraction and old class do not
require changes.
Strategy Pattern or Factory pattern (New implementation can be called at run time)
But over doing abstraction can also cause complexity.

LSP
Subtype should be substitutable for their base type. Meaning subclass should inherit all
behaviour of base class. And they can be used interchangabily. Everything true of parent
class should be true for subclass.
So here we should never redefin inherited non-virtual method. Meaning we should always
use base class implementation of non-virtual method.
In below example for ebook,restock in not a validate option. So when we inherit ebook with
this call, restock need not be implemented, thus not all feature of base class is being
implemented in subclass.
Liskov substitution principle gives us the idea that when a new class has the need to inherit
an existing class, it should do so because this new class has a need for the methods the
existing class has.
ISP
The interface segregation principle makes us understand that it is unnecessary and
unreasonable to create an interface with a lot of methods as some of these methods may
be irrelevant to the needs of a particular user when extended.
It means interface or class should contain only those method by which subclass need not
skip any implementation of base class. In code example we have segrated flying behaviour
from bird interface as not all birds can fly. And FlyingBird class inherit bird class as all birds
which can fly also has feature of bird interface, so we have mult-level inhertiance.

See Code

DIP
High-level modules should not import anything from low-level modules. Both should
depend on abstractions (e.g., interfaces).
Abstractions should not depend on details. Details (concrete implementations) should
depend on abstractions.
public interface ATM {
void ATM_OPERATION();
}

public class Bank implements ATM {


@Override
ATM_OPERATION(){
// code to add money to ATM and increase the ATM balance
}
}

public class Customer implements ATM {

@Override
ATM_OPERATION(){
// code to withdraw money from ATM and decrease the ATM balance
}
}

Design Principle
Identify the aspects of app that changes and separate them from what stays the same
Now to fix this, we need to separate parts that changes then parts that dont change. Like
separating fly and quack into separate class and have multiple implementation of quack like
quack, squeaking or silence.

So Duck is base class with implementation that don't change like swim. and multiple fly and
quack class inheriting Duck class. For, example we may want to instantiate MallardDuck with
specific fly behaviour.

Program to interface not to an implementation


Lets say we want to change fly behiour at run time. So we can't have implementation attached
to base class as virtual method or to subclass as override. So will create an interface with
varying implementation and provide that varying implmentation at run time.

Design Pattern

Singleton
It allows a class to have only one instance and defines where it has to be taken from

public class Singleton


{
// The single instance
private static Singleton instance;
// Initialize the single instance
static Singleton()
{
instance = new Singleton();
}
// The property for retrieving the single instance
public static Singleton Instance
{
get { return instance; }
}
// Private constructor: protects against direct instantiation
private Singleton() { }
}

We have a hidden (private) constructor in order to limit external instantiations. We have a static
variable, which holds the only instance. We initialize it only once in the static constructor of the
class. The property for retrieving the single instance is usually called Instance.

https://www.linkedin.com/pulse/8-best-system-design-books-programmers-developers-soma-
sharma/

You might also like