Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

S.O.L.I.D

SOLID principles for software design
by

Daniel González

on 8 June 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of S.O.L.I.D

S
O
L
I
D
Cohesion
Coupling
Encapsulation
The Bad
Rigidity
Fragility
Immobility
Viscosity
Opacity
Needless
Complexity
Repetition
Object Orientation Goals
The Good
The Ugly
Multiple solutions
Problem
=
Pragmatism
Dogmatism
Measure of how strong the responsibilities of an element are
high
low
Responsibilities are few and intimately related
Methods act on same state or are somehow connected
Promotes encapsulation (beware of ease of testing)
Responsibilities are many and/or not so related to each other
Some methods work with different state
Indicates complexity. Candidates to be split
Measure of how a component (class/package) depends on other components
low
high
not avoided ad-infinitum
managed, instead
loose, weak
tight, strong
Interaction between a limited number of components
Changes in coupled components do not propagate
Fosters reuse. Watch unnecessary complexity
Interactions are spread all over the place
Changes in "remote" places propagate themselves
Low Coupling
High Cohesion
Encapsulation
OCP, DIP, ISP
Same as low coupling + SRP, LSP
SRP, LSP, DIP
Elements are difficult to understand in isolation
Hiding details that are likely to change
separation is King
abstraction
implementation
data
behavior
Low coupling
High cohesion
Law of Demeter
do not talk to strangers
container object
a parameter
a member variable/property
objects created within
within a method
violation of LOD
encapsulation broken
coupling increased
cohesion lowered
Tendency of a program to be difficult to change
Changes propagate to dependant modules
Estimations blow up and fear of change installs
Changes break unrelated code
Fragile code is an usual host of the bug list
Impossibility of logic reuse between projects
too much effort and risk in separating part for reuse, therefore...
...no logic is ever reused
doing things the right way becomes much more expensive than hacking
presents itself in the enviroment, when it "gets in our way" too often
"Non-design-preserving-changes" (hacks) proliferate and good engineering practices stop being performed
a system is hard to read and understand
code is written in an unclear and convoluted way
hard to come back code becomes a candidate for rewriting
codebase contains infrastructure that adds no immediate value
code carries dead weight that would never pay off carrying
code maintains repeating structures instead of sound abstractions
C&P Programming leads to duplication og bugs
ingle
R
esponsibility
P
rinciple
resiliency to changes
increases cohesion
lowers coupling
pen -
C
losed
P
rinciple
a class should only have only one reason to change
as few responsibilities as possible
honoring principle
no change
software entities should be Open for extension but Closed for modification
polymorphism
abstractions
no break
class changes
add
new functionality
when
/ change
existing ones
iskov
S
ubstitution
rinciple
P
subclasses must live up to the expectations set for their parents
NotImplementedException
downcasting
derivatives must be substitutables for their base types
"Wilma, Open this door!"
"Be water, my friend"
"If for each object o1 of type S
there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.”
nterface
S
egregation
P
rinciple
A client should not depend on interfaces it does no use
promotes use of cohesive and focused interfaces
isolates clients from changes in the abstraction
ependency
I
nversion
P
rinciple
depend upon Abstractions, not concretions
change of direction of dependencies comes natural in proper object-oriented code
tackles Rigidity
degradation is often due to poor management of dependencies
crash the "abstraction party" when the component is stable
Daniel Gonzalez Garcia
Full transcript