Scribd
Upload
111 views41 pages

SOLID

This document discusses SOLID principles for object-oriented design. It begins with an introduction of the author and overview of topics to be covered, including basic OOP concepts, code smells, design smells, and the five SOLID principles - Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. Code examples are provided to illustrate each principle and the document concludes with a question and answer section.

Uploaded by

Mönsîeur Abd Nour
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
111 views41 pages

SOLID

This document discusses SOLID principles for object-oriented design. It begins with an introduction of the author and overview of topics to be covered, including basic OOP concepts, code smells, design smells, and the five SOLID principles - Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. Code examples are provided to illustrate each principle and the document concludes with a question and answer section.

Uploaded by

Mönsîeur Abd Nour
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/ 41

SOLID Object Oriented

Design
Craig Berntson
www.craigberntson.com
[email protected]
Twitter: @craigber

A little about me
Independent

consultant in Salt Lake

City
Currently developing database
software for sale to hospitals
Microsoft MVP
INETA Community Speaker
Author

Todays session
Review

basic OOP and smells


SOLID principles
Other agile/OOP principles

Basic OOP
Polymorphism
Encapsulation
Inheritance
Cohesion
Coupling

Refactoring code smells


Duplicate

code
Long method
Large class
Temporary field
Switch statements
Parallel inheritance hierarchies

Design smells
Rigidity

Software is difficult to change


Fragility

Program breaks in many places when


a change made in a single place
Immobility

Parts could be useful in other systems,


but effort and risk to separate from
original system is too great

Design smells
Viscosity

Design-preserving methods are more difficult to


use than the hacks
Development environment is slow and inefficient
Needless

complexity

Contains elements that arent currently useful


Needless

repetition

System has lots of repeated code elements


Opacity

A module is difficult to understand

Why does software rot?


Waterfall

methodology

Requirements change
Code

wants to be chaotic

We dont take time to refactor


We

suck at OO design

Designs and practices are at fault

Technical Debt
The

cost to fix rotting code


Interest charges build over time
The longer we take to remove the
smells, the more it will cost

SOLID
Single

Responsibility Principle (SRP)


Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle
(DIP)

Where does SOLID come from?

Jenga

A real example

Single Responsibility Principle (SRP)

A class should
have only one
reason to change

Responsibility
What

a class does
The more a class does, the more
likely it will change
The more a class changes, the
more likely we will introduce bugs

Cohesion and Coupling


Cohesion

How closely related are


the different responsibilities of a
module
Coupling How much one module
relies on another
Goal is low coupling and high
cohesion

EXAMPLE CODE
Single Responsibility
Principle

Demo
Single

Responsibility Principle

Open Closed principle (OCP)

Software entities
(classes, modules,
functions, etc.) should
be open for extension
but closed for
modification

Conforming to OCP
Open

for extension

Behavior of the module can be


extended
We are able to change what the
module does
Closed

for modification

Extending behavior does not result in


changes to source, binary, or code of
the module

Does not conform to OCP

Client is not open and closed

Strategy pattern

Client is both open and closed

Conforming to OCP
Rely

on abstractions

Interfaces
Abstract classes

EXAMPLE CODE
Open Closed Principle

Liskov Substitution Principle (LSP)

Subtypes must
be substitutable
for their base
types

IS-A
Basic

OOP discusses inheritance


with IS-A
LSP says that IS-A refers to
behavior
Behavior is what software is really
all about

Substitution
Calling

code should not know that


one module is different from its
substitute

EXAMPLE CODE
Liskov Substitution
Principle

Interface Segregation Principle (ISP)

Clients should not


be forced to depend
on methods they do
not use

EXAMPLE CODE
Interface Segregation
Principle

Dependency Inversion Principle (DIP)


High-level

modules should not


depend on low-level modules.
Both should depend on
abstractions
Abstractions should not depend
on details. Details should
depend upon abstractions

EXAMPLE CODE
Dependency Inversion
Principle

Other principles
Keep

It Simple Stupid (KISS)


You Aint Gonna Need It (YAGNI)
Dont Repeat Yourself (DRY)

Todays session
Review

basic OOP and smells


Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substutution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle
(DIP)
Other agile/OOP principles

Questions?
Motivational

posters courtesy of
Derick Bailey through the Creative
Commons License
Contact me
Email: [email protected]
Blog: www.craigberntson.com/blog
Twitter: @craigber

You might also like