SOLID PRINCIPLE I

SESSION 12

SUBJECT MATTER EXPERT

D6421 – Muhammad Fikri Hasani
OUTLINE
COURSE OUTLINE

- Introduction

- Single Responsibility Principle

- Open Closed Principle

- Liskov Substitution Principle

SOLID PRINCIPLE I
INTRODUCTION

• SOLID is an acronym for OOP principle which help gives a standard for ease of
maintenance for the application built using OOP approach.

• The purpose of using SOLID principle is to create software that is easy to maintain,
extend, and reuse. SOLID principle helps developers avoid code smells, reduce
dependencies, and improve readability and stability of the code.

• By following SOLID principle, developers can write software that is more flexible,
logical, and adaptable to changes
SOLID PRINCIPLE I
INTRODUCTION

• Kinds of principles inside solid:

• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

• This session will talk from single responsibility until liskov substitution
SOLID PRINCIPLE I
SINGLE RESPONSIBILITY

• The single responsibility principle (SRP) states that every class, module, or function
should have only one responsibility or purpose in a program.

• This means that each class should have only one reason to change, and that reason
should be related to the class’s responsibility
SOLID PRINCIPLE I
SINGLE RESPONSIBILITY

• For example, suppose we have a class that handles student registration, result
calculation, and email sending. This class violates the SRP, because it has three
different responsibilities and three different reasons to change. If we want to modify
the registration logic, we might affect the result calculation or email sending logic.
This makes the code hard to maintain, test, and reuse.

• A better design would be to separate these three responsibilities into three different
classes, each with its own responsibility and reason to change. This way, we can
change one class without affecting the others, and we can reuse the classes in
different contexts. This makes the code more modular, readable, and stable
 SOLID PRINCIPLE I
SINGLE RESPONSIBILITY EXAMPLE
// This class has two responsibilities: storing user data and validating user
input
• Here is a code block that shows public class User {
an example of a class that private String name;
violates the single responsibility private String email;
private String password;
principle:
public User(String name, String email, String password) {
this.name = name;
this.email = email;
this.password = password;
}

// getters and setters

// This method is not related to the user data, it is a validation logic

public boolean isValidEmail() {
return email.contains("@");
}

// This method is not related to the user data, it is a validation logic

public boolean isValidPassword() {
return password.length() >= 8;
}
}
SOLID PRINCIPLE I
SINGLE RESPONSIBILITY EXAMPLE

// This class has one responsibility: storing

user data
• To follow the single public class User {
private String name;
responsibility principle, we private String email;
private String password;
should separate the validation
public User(String name, String email,
logic from the user data. We can String password) {
this.name = name;
create another class that
this.email = email;
this.password = password;
handles the validation, and use
}
it in the user class
// getters and setters
}
 SOLID PRINCIPLE I
SINGLE RESPONSIBILITY EXAMPLE

// This class has one responsibility: validating user

input
• The validation class can be seen at the public class UserValidator {
// This method is related to the validation logic
right. public boolean isValidEmail(String email) {
return email.contains("@");
• Now, the user class and the user validator }

class have only one responsibility each, // This method is related to the validation logic
public boolean isValidPassword(String password) {
and they have only one reason to change
return password.length() >= 8;
}
}
SOLID PRINCIPLE I
OPEN CLOSED PRINCIPLE

• It states that software entities, such as classes, modules, or functions, should be open for

extension, but closed for modification.

• This means that you can add new features or behaviors to a software entity without changing

its existing code.

• This way, you can avoid breaking the existing functionality or introducing bugs
SOLID PRINCIPLE I
OPEN CLOSED PRINCIPLE

• One way to achieve the open closed principle is to use interfaces or abstract classes to define

the contracts or behaviors of your software entities.

• Then, you can implement or inherit from these interfaces or abstract classes to provide

different implementations or variations of the behaviors.

• This allows you to extend the functionality of your software entities without modifying the

original interfaces or abstract classes

SOLID PRINCIPLE I
OPEN CLOSED PRINCIPLE
// This class has one responsibility: calculating the area
of different shapes
• example of a class public class AreaCalculator {
public double calculateArea(Object shape) {
that violates the
double area = 0;
open closed if (shape instanceof Circle) {
Circle circle = (Circle) shape;
principle area = Math.PI * circle.getRadius() *
circle.getRadius();
} else if (shape instanceof Rectangle) {
Rectangle rectangle = (Rectangle) shape;
area = rectangle.getLength() *
rectangle.getWidth();
}
// If we want to add more shapes, we need to modify
this method
return area;
}
}
SOLID PRINCIPLE I
OPEN CLOSED PRINCIPLE

• To follow the open closed principle, we should separate the area calculation logic from the shape classes.
• We can create an interface that defines a method for calculating the area, and implement it in each shape

class.

• Then, we can use polymorphism to invoke the appropriate method for each shape

// This interface defines a contract for calculating the area of a shape

public interface Shape {
double calculateArea();
}
 SOLID PRINCIPLE I
OPEN CLOSED PRINCIPLE
// This class implements the Shape interface and provides // This class implements the Shape interface and
its own logic for calculating the area provides its own logic for calculating the area
public class Rectangle implements Shape { public class Circle implements Shape {
private double length; private double radius;
private double width;
public Circle(double radius) {
public Rectangle(double length, double width) {
this.radius = radius;
this.length = length;
this.width = width;
}
}
public double getRadius() {
public double getLength() { return radius;
return length; }
}
@Override
public double getWidth() { public double calculateArea() {
return width; return Math.PI * radius * radius;
} }
}
@Override
public double calculateArea() {
return length * width;
}
}
SOLID PRINCIPLE I
OPEN CLOSED PRINCIPLE

•Now, the AreaCalculator class and the // This class has one responsibility: calculating the
total area of a list of shapes
shape classes have only one
public class AreaCalculator {
responsibility each, and they have only
one reason to change. This makes the public double calculateTotalArea(List<Shape> shapes) {
code more modular, readable, and double totalArea = 0;
maintainable. for (Shape shape : shapes) {
totalArea += shape.calculateArea(); // This
•If we want to add more shapes, we can will invoke the appropriate method for each shape
simply create a new class that }
implements the Shape interface, and return totalArea;
the AreaCalculator class will not need }
to change }
SOLID PRINCIPLE I
LISKOV SUBSTITUTION PRINCIPLE

• It states that if a class S is a subclass of a class T, then objects of class T

can be replaced by objects of class S without breaking the program.

• In other words, a subclass should behave like its superclass and not
introduce any unexpected behavior or side effects
SOLID PRINCIPLE I
LISKOV SUBSTITUTION PRINCIPLE (LSP)

• One way to follow this principle is to use interfaces or abstract classes

to define the contracts or behaviors of your classes, and then
implement or inherit from them to provide different variations of the
behaviors.

• This allows you to extend the functionality of your classes without

modifying the original interfaces or abstract classes

• Notice that: The example of open closed principle in previous slides

already using liskov substitution principle

• Great example to understand how to adhere with LSP: Liskov

Substitution Principle in Java | Baeldung
SOLID PRINCIPLE I
REFERENCES

• Daniel Liang, Introduction to Java Programming and Data Structure, 12 th edition.

• https://www.baeldung.com/java-liskov-substitution-principle