Scribd
Upload
9 views22 pages

18 SOLID Principles

Uploaded by

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

18 SOLID Principles

Uploaded by

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

SOLID Design Principles

Ref: https://stackify.com/solid-design-principles/
What is SOLID

S • Single-responsibility Principle

O • Open-closed Principle

L • Liskov Substitution Principle

I • Interface Segregation Principle

D • Dependency Inversion Principle


S – SINGLE RESPONSIBILITY
The “S” Principle
A class should have one, and only one, reason to change.
// Academic ERP
class Student{
StudentBean sinfo;
CourseBean courses[];
float CGPA;
VALPBean valp[];
public: What are the violations
// Grades management
uploadCourseGrade(); of the “S” principle here?
computeCGPA();
addVALP();
PDFFile printMarkSheetPDF();
JSONDoc printMarkSheetJSON();

// Profile management
void updateStudentInfo sinfo;

// Course management
void manageCourse( String operation, Course c ); operation is ADD, DROP
};
Indications of violations of “S”

Code churn • Too many check-in / check-out in version history

• Too many attributes


Heavy class • Too many methods

Build • Single change forces mass recompilation

Side-effects • Ripple effect of changes

• Localization of defects becomes challenging


Complex testing • Regression testing becomes difficult
But remember

Single Responsibility Single Method

class CourseAdd{ class CourseDrop{


Student s; Student s;
public: public:
Student addCourse(Course c); Student dropCourse(Course c);
}; };

class CourseGrade{
Course course;
float grade;
public:
CourseGrade( Course c );
updateGrade(float grade);
};
Real-world Examples

Examples where “S” is implemented


• JPA for persistence in Java
• Drools for rule management
• JAXP for XML processing

Examples where “S” is violated


• JSP includes HTML and Java code for client
server applications
O – OPEN / CLOSED PRINCIPLE
The “O/C” Principle
Software entities (classes, modules, functions, etc.) should
be open for extension, but closed for modification.
class Student{
Student name;
String sType;
public: What are the violations
float getStipend(float hours){ of the “O/C” principle
if(sType.equals(“TA”)) here?
return 5000;
else if(sType.equals(“RA”)
return hours*14;
else
return 0;
}
};
Indications of violations of “O/C”

IF • Too many conditional processing


statements based on types of the object

• Any change forces mass


Build recompilation

• No other way to add / modify


GOD class behaviour
Implementing “O/C” Principle

Using Inheritance
• Define concrete methods to “close”
• Define polymorphic methods to “open”
• Increases coupling

Using Interfaces
• Provide “open” specifications
• No straight forward to give “closed” methods
Real-World Examples
• Custom UI themes in Linux Distributions
• JDBC implementations
• Design Patterns?
L – LISKOV SUBSTITUION
PRINCIPLE
The “LSP”
The principle
Let Φ(x) be a defines
propertythat objects
provable of a superclass
about objects x ofshall
typebeT.
replaceable with objects
Then Φ(y) should be trueof
foritsobjects
subclasses without
y of type breaking
S where S is
the application.
a subtype of T..
class Rectangle{
int width, height; What are the violations
public: of the “LSP” here?
void setWidth(w){width=w};
void setHeight(h){height=h};
int area(){return width*height;}
};

class Square extends Rectangle{


int side;
public:
@override
int area(){return side*side;}
};
Counter Example
What are the violations
class MainDemo{ of the “LSP” here?
public static void main(String args[]){
int side = 4;
Square s1 = new Square(side);
int area = s1.area();

Square s2 = new Square();


getDimensions(s2);
area = s2.area();
}
public void getDimensions(Rectangle r){
r.setWidth(4); r.setHeight(5);
}
};
I – INTERFACE SEGREGATION
The “I” Principle
Clients should not be forced to depend upon interfaces
that they do not use
D – DEPENDENCY INVERSION
The “D” Principle
High-level modules should not depend upon low-level
modules

You might also like