Scribd
Upload
51 views

WEEK - 5 SOLID Principles

The document discusses the SOLID principles of object-oriented design, which are a set of principles for designing flexible and maintainable software. It describes the Single Responsibility Principle, which states that every module should have a single responsibility. It then discusses the Open/Closed Principle, which states that software should be open for extension but closed for modification. The document continues explaining the Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle.

Uploaded by

Zainab Athar
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
51 views

WEEK - 5 SOLID Principles

The document discusses the SOLID principles of object-oriented design, which are a set of principles for designing flexible and maintainable software. It describes the Single Responsibility Principle, which states that every module should have a single responsibility. It then discusses the Open/Closed Principle, which states that software should be open for extension but closed for modification. The document continues explaining the Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle.

Uploaded by

Zainab Athar
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 23

SOLID

Principles

ZUNERA ZAHID
2
Main Concept

 SOLID is the most popular sets of design principles in object-


oriented software.

 make software designs more understandable, flexible


and maintainable.

 Generally, software should be written as simply as possible in


order to produce the desired result. However, once updating
the software becomes painful, the software’s design should
be adjusted to eliminate the pain.
3

Single Responsibility Principle

Open / Closed Principle

Concepts Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion
4
Single Responsibility Principle

 Every Module, Class, or function should


have responsibility over a single part of
the functionality provided by
the software.

 That responsibility should be


entirely encapsulated by the class.
5

Single
Responsibility
Principle
6

Single
Responsibility
Principle
7

Single
Responsibility
Principle

To solve that, let’s introduce the next principle:


8

Open –
closed
Principle
9

Open –
closed
Principle
10

Open – closed Principle


11
Open – closed Principle

 Every Module, Class, or function should be


open for extension, but closed for
modification.

 An entity can allow its behavior to be


extended without modifying its source
code.
12
Liskov Substitution principle

 Objects in a program should be


replaceable with instances of their
subtypes without altering the correctness
of that program.

 The Liskov substitution principle (LSP) is a


particular definition of a subtyping
relation, called (strong) behavioral
subtyping.
13

Liskov
Substitution
principle
14

Liskov
Substitution
principle
15
Interface Segregation Principle

 No client should be forced to depend on


methods it does not use.

 Many client-specific interfaces are better


than one general-purpose interface

 Splits interfaces that are very large into


smaller and more specific ones so that
clients will only have to know about the
methods that are of interest to them.
16

Interface
Segregation
Principle
17

Interface
Segregation
Principle
18

Interface
Segregation
Principle

The way suggested by ISP is to create more client-specific


interfaces rather than one general-purpose interface. So, our
code example becomes:
19

Interface
Segregation
Principle
20

Interface Segregation
Principle
21

Dependency
inversion
principle
22
Dependency inversion principle

 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 (concrete
implementations) should depend on
abstractions.
Software inevitably changes/evolves over time (maintenance, upgrade)

 Single responsibility principle (SRP)

 Every class should have only one reason to be changed

 If class "A" has two responsibilities, create new classes "B" and "C" to
handle each responsibility in isolation, and then compose "A" out of "B"
and "C"

 Open/closed principle (OCP)

 Every class should be open for extension (derivative classes), but closed
for modification (fixed interfaces)

 Put the system parts that are likely to change into implementations (i.e.

SOLID Design
concrete classes) and define interfaces around the parts that are unlikely
to change (e.g. abstract base classes)

 Liskov substitution principle (LSP)

Principles  Every implementation of an interface needs to fully comply with the


requirements of this interface (requirements determined by its clients!)

 Any algorithm that works on the interface, should continue to work for any
substitute implementation

 Interface segregation principle (ISP)

 Keep interfaces as small as possible, to avoid unnecessary dependencies

 Ideally, it should be possible to understand any part of the code in


isolation, without needing to look up the rest of the system code

 Dependency inversion principle (DIP)

 Instead of having concrete implementations communicate directly (and


depend on each other), decouple them by formalizing their
communication interface as an abstract interface based on the needs of
the higher-level class

23

You might also like