SOLID Principles

This document discusses SOLID principles for software design. It introduces each of the five SOLID principles - Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. For each principle, it provides a brief explanation of what the principle means and how it can be applied to achieve benefits like high cohesion, low coupling, and flexibility in a software design. The overall aim of applying these principles is to create a design that is robust, maintainable and extensible over time.

Uploaded by

Rajesh Pillai

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

100% found this document useful (1 vote)

275 views28 pages

SOLID Principles

Uploaded by

Rajesh Pillai

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/ 28

Redefining IT Consulting and Training

SOLID PRINCIPLES
Rajesh Pillai
Founder and CTO

rajesh.pillai@tekacademy.com
pillai.rajesh@gmail.com

www.tekacademy.com
Redefining IT Consulting and Training
Agenda
What design
exactly is
about?
Bad Design
Good Design
SOLID
principles
Summary
Redefining IT Consulting and Training
Design
Meaning of
Design
Analysis vs
Design
Analysis is about
WHAT?
Design is about
HOW
Redefining IT Consulting and Training
Design
Why do we need good design?
To deliver
faster
To manage
change
To deal
with
complexity
Redefining IT Consulting and Training
Design
How do we know a design is ba?
Hey
Uffff?
Grrrr?
???
Hey???
Grrrr??
Redefining IT Consulting and Training
Design
Hmm.. Some better criterias
Rigidity
Fragility
Immobility
Viscocity
Redefining IT Consulting and Training
Design
Issues: Explanations
Rigidity
Impact of change is unpredictable and costs
become unpredictable
Tendency to be difficult to change
Cascade of changes
Simple two day change grows to man-month
of effort
Redefining IT Consulting and Training
Design
Issues: Explanations
Fragility
Easily to break in many places with minor
change
Breaks in conceptually non related areas
Cascading effects
Every fix creates more problem..
Redefining IT Consulting and Training
Design
Issues: Explanations
Immobility
Difficult to reuse
Tied to specific implementation
Duplications
Cost of rewriting is less.
Redefining IT Consulting and Training
Design
Issues: Explanations
Viscosity
Two forms :
Of design
Of environment
Easy to do the wrong thing, but hard to do the
right thing
Dev env. Is very slow causes high viscosity
Redefining IT Consulting and Training
Design
Why design becomes RFIV?
Improper
dependencies
between modules
Redefining IT Consulting and Training
Good Design
Some characteristics.
High
Cohesion
Low
Coupling
Redefining IT Consulting and Training
Good Design
Cohesion
Measure of how strongly
related each piece of
functionality is expressed by
source code.
Aim for high cohesion
Redefining IT Consulting and Training
Good Design
Coupling
Degree of
dependency
Aim for low coupling
Redefining IT Consulting and Training
Good Design
How can we achieve good design? ENTER SOLID
SRP
Single Responsibility
Principle
OCP
Open/Closes Principle
LSP
Liskov Substitution
Principle
ISP
Interface Segregation
Principle
DIP
Dependency Inversion
Principle
Redefining IT Consulting and Training
SOLID
SINGLE RESPONSIBILITY PRINCIPLE
Redefining IT Consulting and Training
SINGLE RESPONSIBILITY PRINCIPLE :
WHAT?
A software or
module should
have only one
reason for
change
This is related
to high
cohesion
Its usually hard
to see different
responsibilities
Redefining IT Consulting and Training
SOLID
SINGLE RESPONSIBILITY PRINCIPLE HOW?
Identify
things that
are changing
for different
reasons
Group things
that change
for the same
reason
Naming of
classes and
methods is
very
important
Redefining IT Consulting and Training
SOLID
OPEN CLOSED PRINCIPLE
Redefining IT Consulting and Training
OPEN CLOSED PRINCIPLE
Modules should be
open for extension
but closed for
modification
You should be able to
extend the behaviour
of a module without
changing it.
Redefining IT Consulting and Training
SOLID
OPEN CLOSE PRINCIPLE
Abstraction is
the key
Keep the things
that change
frequently from
things that
dont change
Redefining IT Consulting and Training
SOLID
LISKOV SUBSTITUTION PRINCIPLE
Redefining IT Consulting and Training
LISKOV SUBSTITUTION PRINCIPLE
If it looks like a
Duck, Quack Like a
Duck, but needs
batteries, then you
probably have the
wrong abstraction
Simply it means
derived types
should be
substitutable
where a base type
is expected.
Redefining IT Consulting and Training
SOLID
INTERFACE SEGREGATION PRINCIPLE
Redefining IT Consulting and Training
INTERFACE SEGREGATION PRINCIPLE
Avoid fat
classes
Rely on clean
cohesive
interfaces
You dont want
to depend on
soemthing you
dont use
Redefining IT Consulting and Training
SOLID
DEPENDENCY INVERSION PRINCIPLE
Redefining IT Consulting and Training
Dependency Inversion Principle
High level modules should not
depend upon low level
modules, both should depend
upon abstractions
Abstractions should not
depend upon details, details
should depend upon
abstractions

Drives you
towards low
coupling
Redefining IT Consulting and Training
Conclusions
Apply these principles
based on your specific
scenarios
The main force is high
cohesion and low
coupling. Rest, most of
the things are side effects.