SlideShare a Scribd company logo
1 of 99
Download to read offline
SOLIDDeconstruction
@KevlinHenney
S
O
L
I
D
Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
In object-oriented programming, the single responsibility
principle states that every object should have a single
responsibility, and that responsibility should be entirely
encapsulated by the class. All its services should be narrowly
aligned with that responsibility.
http://en.wikipedia.org/wiki/Single_responsibility_principle
The term was introduced by Robert C. Martin [...]. Martin
described it as being based on the principle of cohesion, as
described by Tom DeMarco in his book Structured Analysis and
Systems Specification.
http://en.wikipedia.org/wiki/Single_responsibility_principle
We refer to a sound line of reasoning,
for example, as coherent. The thoughts
fit, they go together, they relate to each
other. This is exactly the characteristic
of a class that makes it coherent: the
pieces all seem to be related, they seem
to belong together, and it would feel
somewhat unnatural to pull them apart.
Such a class exhibits cohesion.
utility
 the state of being useful, profitable or beneficial
 useful, especially through having several functions
 functional rather than attractive
Concise Oxford English Dictionary
#include <stdlib.h>
Every class should
embody only about 3–5
distinct responsibilities.
Grady Booch, Object Solutions
One of the most foundational
principles of good design is:
Gather together those things
that change for the same
reason, and separate those
things that change for
different reasons.
This principle is often known
as the single responsibility
principle, or SRP. In short, it
says that a subsystem, module,
class, or even a function,
should not have more than one
reason to change.
Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
Interface inheritance (subtyping) is used
whenever one can imagine that client code
should depend on less functionality than the full
interface. Services are often partitioned into
several unrelated interfaces when it is possible to
partition the clients into different roles. For
example, an administrative interface is often
unrelated and distinct in the type system from
the interface used by “normal” clients.
"General Design Principles"
CORBAservices
The dependency
should be on the
interface, the
whole interface,
and nothing but
the interface.
We refer to a sound line of reasoning,
for example, as coherent. The thoughts
fit, they go together, they relate to each
other. This is exactly the characteristic
of a class that makes it coherent: the
pieces all seem to be related, they seem
to belong together, and it would feel
somewhat unnatural to pull them apart.
Such a class exhibits cohesion.
We refer to a sound line of reasoning,
for example, as coherent. The thoughts
fit, they go together, they relate to each
other. This is exactly the characteristic of
an interface that makes it coherent: the
pieces all seem to be related, they seem
to belong together, and it would feel
somewhat unnatural to pull them apart.
Such an interface exhibits cohesion.
public interface LineIO
{
String read();
void write(String toWrite);
}
public interface LineReader
{
String read();
}
public interface LineWriter
{
void write(String toWrite);
}
Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
In a purist view of object-oriented methodology,
dynamic dispatch is the only mechanism for
taking advantage of attributes that have been
forgotten by subsumption.
This position is often taken on abstraction
grounds: no knowledge should be obtainable
about objects except by invoking their methods.
In the purist approach, subsumption provides a
simple and effective mechanism for hiding
private attributes.
A type hierarchy is composed of subtypes and
supertypes. The intuitive idea of a subtype is one
whose objects provide all the behavior of objects
of another type (the supertype) plus something
extra. What is wanted here is something like the
following substitution property: 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.
Barbara Liskov
"Data Abstraction and Hierarchy"
generalisation
specialisation
commonality
variation
E.g., Python's dict class, which is a
hashed mapping container
E.g., Python's OrderedDict class,
which preserves order of insertion
public class RecentlyUsedList
{
...
public int Count
{
get ...
}
public string this[int index]
{
get ...
}
public void Add(string newItem) ...
...
}
public class RecentlyUsedList
{
private IList<string> items = new List<string>();
public int Count
{
get
{
return items.Count;
}
}
public string this[int index]
{
get
{
return items[index];
}
}
public void Add(string newItem)
{
if(newItem == null)
throw new ArgumentNullException();
items.Remove(newItem);
items.Insert(0, newItem);
}
...
}
public class RecentlyUsedList : List<string>
{
public override void Add(string newItem)
{
if(newItem == null)
throw new ArgumentNullException();
items.Remove(newItem);
items.Insert(0, newItem);
}
...
}
namespace List_spec
{
...
[TestFixture]
public class Addition
{
private List<string> list;
[Setup]
public void List_is_initially_empty()
{
list = ...
}
...
[Test]
public void Addition_of_non_null_item_is_appended() ...
[Test]
public void Addition_of_null_is_permitted() ...
[Test]
public void Addition_of_duplicate_item_is_appended() ...
...
}
...
}
namespace List_spec
{
...
[TestFixture]
public class Addition
{
private List<string> list;
[Setup]
public void List_is_initially_empty()
{
list = new List<string>();
}
...
[Test]
public void Addition_of_non_null_item_is_appended() ...
[Test]
public void Addition_of_null_is_permitted() ...
[Test]
public void Addition_of_duplicate_item_is_appended() ...
...
}
...
}
namespace List_spec
{
...
[TestFixture]
public class Addition
{
private List<string> list;
[Setup]
public void List_is_initially_empty()
{
list = new RecentlyUsedList();
}
...
[Test]
public void Addition_of_non_null_item_is_appended() ...
[Test]
public void Addition_of_null_is_permitted() ...
[Test]
public void Addition_of_duplicate_item_is_appended() ...
...
}
...
}
A type hierarchy is composed of subtypes and
supertypes. The intuitive idea of a subtype is one
whose objects provide all the behavior of objects
of another type (the supertype) plus something
extra. What is wanted here is something like the
following substitution property: 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.
Barbara Liskov
"Data Abstraction and Hierarchy"
A type hierarchy is composed of subtypes and
supertypes. The intuitive idea of a subtype is one
whose objects provide all the behavior of objects
of another type (the supertype) plus something
extra. What is wanted here is something like the
following substitution property: 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.
Barbara Liskov
"Data Abstraction and Hierarchy"
A type hierarchy is composed of subtypes and
supertypes. The intuitive idea of a subtype is one
whose objects provide all the behavior of objects
of another type (the supertype) plus something
extra. What is wanted here is something like the
following substitution property: 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.
Barbara Liskov
"Data Abstraction and Hierarchy"
A type hierarchy is composed of subtypes and
supertypes. The intuitive idea of a subtype is one
whose objects provide all the behavior of objects
of another type (the supertype) plus something
extra. What is wanted here is something like the
following substitution property: 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.
Barbara Liskov
"Data Abstraction and Hierarchy"
Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
Bertrand Meyer gave us guidance as long ago
as 1988 when he coined the now famous
open-closed principle. To paraphrase him:
Software entites (classes, modules,
functions, etc.) should be open for
extension, but closed for modification.
Robert C Martin
"The Open-Closed Principle"
C++ Report, January 1996
Open for
extension
Closed for
extension
Closed for
modification
Open for
modification
Extend existing code
without changing it,
e.g., using a framework
Extend or change existing
code, e.g., open-source
and unpublished code
Non-extensible and
unchangeable code,
e.g., composable code
or legacy code
Non-extensible code that
can be maintained, e.g.,
composable code in a
maintained library
The principle stated that a good module
structure should be both open and closed:
 Closed, because clients need the
module's services to proceed with their
own development, and once they have
settled on a version of the module should
not be affected by the introduction of new
services they do not need.
 Open, because there is no guarantee that
we will include right from the start every
service potentially useful to some client.
[...] A good module structure
should be [...] closed [...] because
clients need the module's
services to proceed with their
own development, and once
they have settled on a version of
the module should not be
affected by the introduction of
new services they do not need.
Published Interface is a term I used (first in
Refactoring) to refer to a class interface that's used
outside the code base that it's defined in.
Martin Fowler
http://martinfowler.com/bliki/PublishedInterface.html
There is no problem changing a
method name if you have access to
all the code that calls that method.
Even if the method is public, as long
as you can reach and change all the
callers, you can rename the method.
There is a problem only if the
interface is being used by code that
you cannot find and change. When
this happens, I say that the interface
becomes a published interface (a
step beyond a public interface).
Published Interface is a term I used (first in
Refactoring) to refer to a class interface that's used
outside the code base that it's defined in.
The distinction between published and public is
actually more important than that between public and
private.
The reason is that with a non-published interface you
can change it and update the calling code since it is all
within a single code base. [...] But anything published
so you can't reach the calling code needs more
complicated treatment.
Martin Fowler
http://martinfowler.com/bliki/PublishedInterface.html
[...] A good module structure
should be [...] open [...] because
there is no guarantee that we will
include right from the start every
service potentially useful to some
client.
Speculative Generality
Brian Foote suggested this name for a
smell to which we are very sensitive.
You get it when people say, "Oh, I
think we need the ability to do this
kind of thing someday" and thus want
all sorts of hooks and special cases to
handle things that aren't required.
extends
A myth in the object-oriented design
community goes something like this:
If you use object-oriented technology,
you can take any class someone else
wrote, and, by using it as a base class,
refine it to do a similar task.
Robert B Murray
C++ Strategies and Tactics
Design and implement for
inheritance or else prohibit it
By now, it should be apparent that
designing a class for inheritance places
substantial limitations on the class.
http://blog.8thlight.com/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html
http://blog.8thlight.com/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html
I've heard it said that the OCP is wrong,
unworkable, impractical, and not for real
programmers with real work to do. The
rise of plugin architectures makes it plain
that these views are utter nonsense. On
the contrary, a strong plugin architecture
is likely to be the most important aspect
of future software systems.
OCP ≡ Plug-ins?
OCP ≡ Plug-ins/
public abstract class Shape
{
...
}
public class Square : Shape
{
...
public void DrawSquare() ...
}
public class Circle : Shape
{
...
public void DrawCircle() ...
}
public abstract class Shape ...
public class Square : Shape ...
public class Circle : Shape ...
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
if (s is Square)
(s as Square).DrawSquare();
else if (s is Circle)
(s as Circle).DrawCircle();
}
public abstract class Shape ...
public class Square : Shape ...
public class Circle : Shape ...
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
if (s is Square)
(s as Square).DrawSquare();
else if (s is Circle)
(s as Circle).DrawCircle();
}
public abstract class Shape
{
...
public abstract void Draw();
}
public class Square : Shape
{
...
public override void Draw() ...
}
public class Circle : Shape
{
...
public override void Draw() ...
}
public abstract class Shape ...
public class Square : Shape ...
public class Circle : Shape ...
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
s.Draw();
}
public abstract class Shape ...
public class Square : Shape ...
public class Circle : Shape ...
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
s.Draw();
}
public abstract class Shape ...
public class Square : Shape ...
public class Circle : Shape ...
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
s.Draw();
}
Bertrand Meyer gave us guidance as long ago
as 1988 when he coined the now famous
open-closed principle. To paraphrase him:
Software entites (classes, modules,
functions, etc.) should be open for
extension, but closed for modification.
Robert C Martin
"The Open-Closed Principle"
C++ Report, January 1996
Bertrand Meyer gave us guidance as long ago
as 1988 when he coined the now famous
open-closed principle. To paraphrase him:
Software entites (classes, modules,
functions, etc.) should be open for
extension, but closed for modification.
Robert C Martin
"The Open-Closed Principle"
C++ Report, January 1996
This double requirement looks like a
dilemma, and classical module
structures offer no clue.
This double requirement looks like a
dilemma, and classical module
structures offer no clue. But
inheritance solves it.
This double requirement looks like a
dilemma, and classical module
structures offer no clue. But
inheritance solves it. A class is
closed, since it may be compiled,
stored in a library, baselined, and
used by client classes. But it is also
open, since any new class may use
it as parent, adding new features.
public abstract class Shape ...
public class Square : Shape ...
public class Circle : Shape ...
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
if (s is Square)
(s as Square).DrawSquare();
else if (s is Circle)
(s as Circle).DrawCircle();
}
public abstract class Shape ...
public class Square : Shape ...
public class Circle : Shape ...
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
if (s is Square)
(s as Square).DrawSquare();
else if (s is Circle)
(s as Circle).DrawCircle();
}
public abstract class Shape ...
public class Square : Shape ...
public class Circle : Shape ...
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
s.Draw();
}
public abstract class Shape ...
public class Square : Shape ...
public class Circle : Shape ...
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
s.Draw();
}
public sealed class Shape
{
public enum Type { Square, Circle }
...
public void Draw() ...
}
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
s.Draw();
}
public sealed class Shape
{
public enum Type { Square, Circle }
...
public void Draw() ...
}
static void DrawAllShapes(Shape[] list)
{
foreach (Shape s in list)
s.Draw();
}
Don't publish
interfaces prematurely.
Modify your code
ownership policies to
smooth refactoring.
Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
In object-oriented programming, the dependency inversion
principle refers to a specific form of decoupling where
conventional dependency relationships established from high-
level, policy-setting modules to low-level, dependency
modules are inverted (i.e. reversed) for the purpose of
rendering high-level modules independent of the low-level
module implementation details.
http://en.wikipedia.org/wiki/Dependency_inversion_principle
The principle states:
A. High-level modules should not depend on low-level
modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should
depend upon abstractions.
http://en.wikipedia.org/wiki/Dependency_inversion_principle
inversion, noun
 the action of inverting or the state of being
inverted
 reversal of the normal order of words,
normally for rhetorical effect
 an inverted interval, chord, or phrase
 a reversal of the normal decrease of air
temperature with altitude, or of water
temperature with depth
Concise Oxford English Dictionary
Parameterize
from Above
Hardwire
from Below
Stewart Brand, How Buildings Learn
See also http://www.laputan.org/mud/
package com.sun...;


 



Scenario buffering by dot-voting possible changes and invert dependencies as needed
One of the most foundational
principles of good design is:
Gather together those things
that change for the same
reason, and separate those
things that change for
different reasons.
This principle is often known
as the single responsibility
principle, or SRP. In short, it
says that a subsystem, module,
class, or even a function,
should not have more than one
reason to change.
At some level
the style
becomes the
substance.

More Related Content

What's hot

Introduction to oop
Introduction to oopIntroduction to oop
Introduction to oopcolleges
 
Object Oriented Programming using C++ Part II
Object Oriented Programming using C++ Part IIObject Oriented Programming using C++ Part II
Object Oriented Programming using C++ Part IIAjit Nayak
 
Chapter 04 object oriented programming
Chapter 04 object oriented programmingChapter 04 object oriented programming
Chapter 04 object oriented programmingPraveen M Jigajinni
 
Object Oriented Concepts and Principles
Object Oriented Concepts and PrinciplesObject Oriented Concepts and Principles
Object Oriented Concepts and Principlesdeonpmeyer
 
Oops concepts || Object Oriented Programming Concepts in Java
Oops concepts || Object Oriented Programming Concepts in JavaOops concepts || Object Oriented Programming Concepts in Java
Oops concepts || Object Oriented Programming Concepts in JavaMadishetty Prathibha
 
Concepts In Object Oriented Programming Languages
Concepts In Object Oriented Programming LanguagesConcepts In Object Oriented Programming Languages
Concepts In Object Oriented Programming Languagesppd1961
 
Oop in c++ lecture 1
Oop in c++  lecture 1Oop in c++  lecture 1
Oop in c++ lecture 1zk75977
 
Basic Concepts Of OOPS/OOPS in Java,C++
Basic Concepts Of OOPS/OOPS in Java,C++Basic Concepts Of OOPS/OOPS in Java,C++
Basic Concepts Of OOPS/OOPS in Java,C++Guneesh Basundhra
 
Oops concept in c++ unit 3 -topic 4
Oops concept in c++ unit 3 -topic 4Oops concept in c++ unit 3 -topic 4
Oops concept in c++ unit 3 -topic 4MOHIT TOMAR
 
Basic Concepts of OOPs (Object Oriented Programming in Java)
Basic Concepts of OOPs (Object Oriented Programming in Java)Basic Concepts of OOPs (Object Oriented Programming in Java)
Basic Concepts of OOPs (Object Oriented Programming in Java)Michelle Anne Meralpis
 
C++ Object oriented concepts & programming
C++ Object oriented concepts & programmingC++ Object oriented concepts & programming
C++ Object oriented concepts & programmingnirajmandaliya
 

What's hot (20)

Lecture 2
Lecture 2Lecture 2
Lecture 2
 
Introduction to oop
Introduction to oopIntroduction to oop
Introduction to oop
 
Java Notes
Java NotesJava Notes
Java Notes
 
Oop in kotlin
Oop in kotlinOop in kotlin
Oop in kotlin
 
Understanding Python
Understanding PythonUnderstanding Python
Understanding Python
 
Object Oriented Programming using C++ Part II
Object Oriented Programming using C++ Part IIObject Oriented Programming using C++ Part II
Object Oriented Programming using C++ Part II
 
2.oop concept
2.oop concept2.oop concept
2.oop concept
 
OOP java
OOP javaOOP java
OOP java
 
Chapter 04 object oriented programming
Chapter 04 object oriented programmingChapter 04 object oriented programming
Chapter 04 object oriented programming
 
Object Oriented Concepts and Principles
Object Oriented Concepts and PrinciplesObject Oriented Concepts and Principles
Object Oriented Concepts and Principles
 
Oops concepts || Object Oriented Programming Concepts in Java
Oops concepts || Object Oriented Programming Concepts in JavaOops concepts || Object Oriented Programming Concepts in Java
Oops concepts || Object Oriented Programming Concepts in Java
 
Concepts In Object Oriented Programming Languages
Concepts In Object Oriented Programming LanguagesConcepts In Object Oriented Programming Languages
Concepts In Object Oriented Programming Languages
 
Oop in c++ lecture 1
Oop in c++  lecture 1Oop in c++  lecture 1
Oop in c++ lecture 1
 
Concepts of oops
Concepts of oopsConcepts of oops
Concepts of oops
 
The Ceylon Type System
The Ceylon Type SystemThe Ceylon Type System
The Ceylon Type System
 
Basic Concepts Of OOPS/OOPS in Java,C++
Basic Concepts Of OOPS/OOPS in Java,C++Basic Concepts Of OOPS/OOPS in Java,C++
Basic Concepts Of OOPS/OOPS in Java,C++
 
Oops concept in c++ unit 3 -topic 4
Oops concept in c++ unit 3 -topic 4Oops concept in c++ unit 3 -topic 4
Oops concept in c++ unit 3 -topic 4
 
Notes on c++
Notes on c++Notes on c++
Notes on c++
 
Basic Concepts of OOPs (Object Oriented Programming in Java)
Basic Concepts of OOPs (Object Oriented Programming in Java)Basic Concepts of OOPs (Object Oriented Programming in Java)
Basic Concepts of OOPs (Object Oriented Programming in Java)
 
C++ Object oriented concepts & programming
C++ Object oriented concepts & programmingC++ Object oriented concepts & programming
C++ Object oriented concepts & programming
 

Viewers also liked

The Error of Our Ways
The Error of Our WaysThe Error of Our Ways
The Error of Our WaysKevlin Henney
 
Declarative Thinking, Declarative Practice
Declarative Thinking, Declarative PracticeDeclarative Thinking, Declarative Practice
Declarative Thinking, Declarative PracticeKevlin Henney
 
Seven Ineffective Coding Habits of Many Programmers
Seven Ineffective Coding Habits of Many ProgrammersSeven Ineffective Coding Habits of Many Programmers
Seven Ineffective Coding Habits of Many ProgrammersKevlin Henney
 
Python Advanced – Building on the foundation
Python Advanced – Building on the foundationPython Advanced – Building on the foundation
Python Advanced – Building on the foundationKevlin Henney
 
The Architecture of Uncertainty
The Architecture of UncertaintyThe Architecture of Uncertainty
The Architecture of UncertaintyKevlin Henney
 
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Kevlin Henney
 
DPC2007 Objects Of Desire (Kevlin Henney)
DPC2007 Objects Of Desire (Kevlin Henney)DPC2007 Objects Of Desire (Kevlin Henney)
DPC2007 Objects Of Desire (Kevlin Henney)dpc
 
Serializing Value Objects-Ara Hacopian
Serializing Value Objects-Ara HacopianSerializing Value Objects-Ara Hacopian
Serializing Value Objects-Ara HacopianSmartLogic
 
Programming with GUTs
Programming with GUTsProgramming with GUTs
Programming with GUTsKevlin Henney
 
A System Is Not a Tree
A System Is Not a TreeA System Is Not a Tree
A System Is Not a TreeKevlin Henney
 

Viewers also liked (18)

The Error of Our Ways
The Error of Our WaysThe Error of Our Ways
The Error of Our Ways
 
Declarative Thinking, Declarative Practice
Declarative Thinking, Declarative PracticeDeclarative Thinking, Declarative Practice
Declarative Thinking, Declarative Practice
 
Seven Ineffective Coding Habits of Many Programmers
Seven Ineffective Coding Habits of Many ProgrammersSeven Ineffective Coding Habits of Many Programmers
Seven Ineffective Coding Habits of Many Programmers
 
Python Advanced – Building on the foundation
Python Advanced – Building on the foundationPython Advanced – Building on the foundation
Python Advanced – Building on the foundation
 
The Architecture of Uncertainty
The Architecture of UncertaintyThe Architecture of Uncertainty
The Architecture of Uncertainty
 
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
 
The Rule of Three
The Rule of ThreeThe Rule of Three
The Rule of Three
 
Game of Sprints
Game of SprintsGame of Sprints
Game of Sprints
 
Good Code
Good CodeGood Code
Good Code
 
DPC2007 Objects Of Desire (Kevlin Henney)
DPC2007 Objects Of Desire (Kevlin Henney)DPC2007 Objects Of Desire (Kevlin Henney)
DPC2007 Objects Of Desire (Kevlin Henney)
 
Serializing Value Objects-Ara Hacopian
Serializing Value Objects-Ara HacopianSerializing Value Objects-Ara Hacopian
Serializing Value Objects-Ara Hacopian
 
FizzBuzz Trek
FizzBuzz TrekFizzBuzz Trek
FizzBuzz Trek
 
Programming with GUTs
Programming with GUTsProgramming with GUTs
Programming with GUTs
 
A System Is Not a Tree
A System Is Not a TreeA System Is Not a Tree
A System Is Not a Tree
 
Modernsalafism saidfoudah
Modernsalafism saidfoudahModernsalafism saidfoudah
Modernsalafism saidfoudah
 
Immutability FTW!
Immutability FTW!Immutability FTW!
Immutability FTW!
 
Functional C++
Functional C++Functional C++
Functional C++
 
The Programmer
The ProgrammerThe Programmer
The Programmer
 

Similar to SOLID Principles Explained

It Is Possible to Do Object-Oriented Programming in Java
It Is Possible to Do Object-Oriented Programming in JavaIt Is Possible to Do Object-Oriented Programming in Java
It Is Possible to Do Object-Oriented Programming in JavaKevlin Henney
 
Module01_OO_Intro.ppt
Module01_OO_Intro.pptModule01_OO_Intro.ppt
Module01_OO_Intro.pptNelsonYanes6
 
Module01_OO_Intro.ppt
Module01_OO_Intro.pptModule01_OO_Intro.ppt
Module01_OO_Intro.pptRajKamal95773
 
27 f157al5enhanced er diagram
27 f157al5enhanced er diagram27 f157al5enhanced er diagram
27 f157al5enhanced er diagramdddgh
 
Kripanshu MOOC PPT - Kripanshu Shekhar Jha (1).pptx
Kripanshu MOOC PPT - Kripanshu Shekhar Jha (1).pptxKripanshu MOOC PPT - Kripanshu Shekhar Jha (1).pptx
Kripanshu MOOC PPT - Kripanshu Shekhar Jha (1).pptxsg4795
 
Class and object 1
Class and object 1Class and object 1
Class and object 1sajib miha
 
Dcap Ja Progmeet 2007 07 05
Dcap Ja Progmeet 2007 07 05Dcap Ja Progmeet 2007 07 05
Dcap Ja Progmeet 2007 07 05Julie Allinson
 
1 intro
1 intro1 intro
1 introabha48
 
Mapping ER and EER Model
Mapping ER and EER ModelMapping ER and EER Model
Mapping ER and EER ModelMary Brinda
 
Lotusphere 2007 BP301 Advanced Object Oriented Programming for LotusScript
Lotusphere 2007 BP301 Advanced Object Oriented Programming for LotusScriptLotusphere 2007 BP301 Advanced Object Oriented Programming for LotusScript
Lotusphere 2007 BP301 Advanced Object Oriented Programming for LotusScriptBill Buchan
 
CHAPTER 1 - OVERVIEW OOP.ppt
CHAPTER 1 - OVERVIEW OOP.pptCHAPTER 1 - OVERVIEW OOP.ppt
CHAPTER 1 - OVERVIEW OOP.pptNgoHuuNhan1
 
SWAP : A Dublin Core Application Profile for desribing scholarly works
SWAP : A Dublin Core Application Profile for desribing scholarly worksSWAP : A Dublin Core Application Profile for desribing scholarly works
SWAP : A Dublin Core Application Profile for desribing scholarly worksJulie Allinson
 
2012.10 - DDI Lifecycle - Moving Forward - 3
2012.10 - DDI Lifecycle - Moving Forward - 32012.10 - DDI Lifecycle - Moving Forward - 3
2012.10 - DDI Lifecycle - Moving Forward - 3Dr.-Ing. Thomas Hartmann
 

Similar to SOLID Principles Explained (20)

It Is Possible to Do Object-Oriented Programming in Java
It Is Possible to Do Object-Oriented Programming in JavaIt Is Possible to Do Object-Oriented Programming in Java
It Is Possible to Do Object-Oriented Programming in Java
 
Module01_OO_Intro.ppt
Module01_OO_Intro.pptModule01_OO_Intro.ppt
Module01_OO_Intro.ppt
 
Module01_OO_Intro.ppt
Module01_OO_Intro.pptModule01_OO_Intro.ppt
Module01_OO_Intro.ppt
 
enhanced er diagram
enhanced er diagramenhanced er diagram
enhanced er diagram
 
27 f157al5enhanced er diagram
27 f157al5enhanced er diagram27 f157al5enhanced er diagram
27 f157al5enhanced er diagram
 
Objects of Value
Objects of ValueObjects of Value
Objects of Value
 
Substitutability
SubstitutabilitySubstitutability
Substitutability
 
Kripanshu MOOC PPT - Kripanshu Shekhar Jha (1).pptx
Kripanshu MOOC PPT - Kripanshu Shekhar Jha (1).pptxKripanshu MOOC PPT - Kripanshu Shekhar Jha (1).pptx
Kripanshu MOOC PPT - Kripanshu Shekhar Jha (1).pptx
 
AI_2nd Lab.pptx
AI_2nd Lab.pptxAI_2nd Lab.pptx
AI_2nd Lab.pptx
 
Python-Classes.pptx
Python-Classes.pptxPython-Classes.pptx
Python-Classes.pptx
 
Class and object 1
Class and object 1Class and object 1
Class and object 1
 
Dcap Ja Progmeet 2007 07 05
Dcap Ja Progmeet 2007 07 05Dcap Ja Progmeet 2007 07 05
Dcap Ja Progmeet 2007 07 05
 
1 intro
1 intro1 intro
1 intro
 
Mapping ER and EER Model
Mapping ER and EER ModelMapping ER and EER Model
Mapping ER and EER Model
 
Lotusphere 2007 BP301 Advanced Object Oriented Programming for LotusScript
Lotusphere 2007 BP301 Advanced Object Oriented Programming for LotusScriptLotusphere 2007 BP301 Advanced Object Oriented Programming for LotusScript
Lotusphere 2007 BP301 Advanced Object Oriented Programming for LotusScript
 
CHAPTER 1 - OVERVIEW OOP.ppt
CHAPTER 1 - OVERVIEW OOP.pptCHAPTER 1 - OVERVIEW OOP.ppt
CHAPTER 1 - OVERVIEW OOP.ppt
 
SWAP : A Dublin Core Application Profile for desribing scholarly works
SWAP : A Dublin Core Application Profile for desribing scholarly worksSWAP : A Dublin Core Application Profile for desribing scholarly works
SWAP : A Dublin Core Application Profile for desribing scholarly works
 
2012.10 - DDI Lifecycle - Moving Forward - 3
2012.10 - DDI Lifecycle - Moving Forward - 32012.10 - DDI Lifecycle - Moving Forward - 3
2012.10 - DDI Lifecycle - Moving Forward - 3
 
Subtyping
Subtyping Subtyping
Subtyping
 
01. design pattern
01. design pattern01. design pattern
01. design pattern
 

More from Kevlin Henney

The Case for Technical Excellence
The Case for Technical ExcellenceThe Case for Technical Excellence
The Case for Technical ExcellenceKevlin Henney
 
Empirical Development
Empirical DevelopmentEmpirical Development
Empirical DevelopmentKevlin Henney
 
Lambda? You Keep Using that Letter
Lambda? You Keep Using that LetterLambda? You Keep Using that Letter
Lambda? You Keep Using that LetterKevlin Henney
 
Lambda? You Keep Using that Letter
Lambda? You Keep Using that LetterLambda? You Keep Using that Letter
Lambda? You Keep Using that LetterKevlin Henney
 
Procedural Programming: It’s Back? It Never Went Away
Procedural Programming: It’s Back? It Never Went AwayProcedural Programming: It’s Back? It Never Went Away
Procedural Programming: It’s Back? It Never Went AwayKevlin Henney
 
Structure and Interpretation of Test Cases
Structure and Interpretation of Test CasesStructure and Interpretation of Test Cases
Structure and Interpretation of Test CasesKevlin Henney
 
Refactoring to Immutability
Refactoring to ImmutabilityRefactoring to Immutability
Refactoring to ImmutabilityKevlin Henney
 
Turning Development Outside-In
Turning Development Outside-InTurning Development Outside-In
Turning Development Outside-InKevlin Henney
 
Giving Code a Good Name
Giving Code a Good NameGiving Code a Good Name
Giving Code a Good NameKevlin Henney
 
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Kevlin Henney
 
Thinking Outside the Synchronisation Quadrant
Thinking Outside the Synchronisation QuadrantThinking Outside the Synchronisation Quadrant
Thinking Outside the Synchronisation QuadrantKevlin Henney
 

More from Kevlin Henney (20)

Program with GUTs
Program with GUTsProgram with GUTs
Program with GUTs
 
The Case for Technical Excellence
The Case for Technical ExcellenceThe Case for Technical Excellence
The Case for Technical Excellence
 
Empirical Development
Empirical DevelopmentEmpirical Development
Empirical Development
 
Lambda? You Keep Using that Letter
Lambda? You Keep Using that LetterLambda? You Keep Using that Letter
Lambda? You Keep Using that Letter
 
Lambda? You Keep Using that Letter
Lambda? You Keep Using that LetterLambda? You Keep Using that Letter
Lambda? You Keep Using that Letter
 
Get Kata
Get KataGet Kata
Get Kata
 
Procedural Programming: It’s Back? It Never Went Away
Procedural Programming: It’s Back? It Never Went AwayProcedural Programming: It’s Back? It Never Went Away
Procedural Programming: It’s Back? It Never Went Away
 
Structure and Interpretation of Test Cases
Structure and Interpretation of Test CasesStructure and Interpretation of Test Cases
Structure and Interpretation of Test Cases
 
Agility ≠ Speed
Agility ≠ SpeedAgility ≠ Speed
Agility ≠ Speed
 
Refactoring to Immutability
Refactoring to ImmutabilityRefactoring to Immutability
Refactoring to Immutability
 
Old Is the New New
Old Is the New NewOld Is the New New
Old Is the New New
 
Turning Development Outside-In
Turning Development Outside-InTurning Development Outside-In
Turning Development Outside-In
 
Giving Code a Good Name
Giving Code a Good NameGiving Code a Good Name
Giving Code a Good Name
 
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...
 
Thinking Outside the Synchronisation Quadrant
Thinking Outside the Synchronisation QuadrantThinking Outside the Synchronisation Quadrant
Thinking Outside the Synchronisation Quadrant
 
Code as Risk
Code as RiskCode as Risk
Code as Risk
 
Software Is Details
Software Is DetailsSoftware Is Details
Software Is Details
 
Driven to Tests
Driven to TestsDriven to Tests
Driven to Tests
 
Learning Curve
Learning CurveLearning Curve
Learning Curve
 
Unequal Equivalence
Unequal EquivalenceUnequal Equivalence
Unequal Equivalence
 

Recently uploaded

JavaLand 2024 - Going serverless with Quarkus GraalVM native images and AWS L...
JavaLand 2024 - Going serverless with Quarkus GraalVM native images and AWS L...JavaLand 2024 - Going serverless with Quarkus GraalVM native images and AWS L...
JavaLand 2024 - Going serverless with Quarkus GraalVM native images and AWS L...Bert Jan Schrijver
 
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full RecordingOpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full RecordingShane Coughlan
 
The Ultimate Guide to Performance Testing in Low-Code, No-Code Environments (...
The Ultimate Guide to Performance Testing in Low-Code, No-Code Environments (...The Ultimate Guide to Performance Testing in Low-Code, No-Code Environments (...
The Ultimate Guide to Performance Testing in Low-Code, No-Code Environments (...kalichargn70th171
 
Osi security architecture in network.pptx
Osi security architecture in network.pptxOsi security architecture in network.pptx
Osi security architecture in network.pptxVinzoCenzo
 
Best Angular 17 Classroom & Online training - Naresh IT
Best Angular 17 Classroom & Online training - Naresh ITBest Angular 17 Classroom & Online training - Naresh IT
Best Angular 17 Classroom & Online training - Naresh ITmanoharjgpsolutions
 
Advantages of Cargo Cloud Solutions.pptx
Advantages of Cargo Cloud Solutions.pptxAdvantages of Cargo Cloud Solutions.pptx
Advantages of Cargo Cloud Solutions.pptxRTS corp
 
Understanding Flamingo - DeepMind's VLM Architecture
Understanding Flamingo - DeepMind's VLM ArchitectureUnderstanding Flamingo - DeepMind's VLM Architecture
Understanding Flamingo - DeepMind's VLM Architecturerahul_net
 
Ronisha Informatics Private Limited Catalogue
Ronisha Informatics Private Limited CatalogueRonisha Informatics Private Limited Catalogue
Ronisha Informatics Private Limited Catalogueitservices996
 
2024 DevNexus Patterns for Resiliency: Shuffle shards
2024 DevNexus Patterns for Resiliency: Shuffle shards2024 DevNexus Patterns for Resiliency: Shuffle shards
2024 DevNexus Patterns for Resiliency: Shuffle shardsChristopher Curtin
 
Keeping your build tool updated in a multi repository world
Keeping your build tool updated in a multi repository worldKeeping your build tool updated in a multi repository world
Keeping your build tool updated in a multi repository worldRoberto Pérez Alcolea
 
Large Language Models for Test Case Evolution and Repair
Large Language Models for Test Case Evolution and RepairLarge Language Models for Test Case Evolution and Repair
Large Language Models for Test Case Evolution and RepairLionel Briand
 
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdfSteve Caron
 
Understanding Plagiarism: Causes, Consequences and Prevention.pptx
Understanding Plagiarism: Causes, Consequences and Prevention.pptxUnderstanding Plagiarism: Causes, Consequences and Prevention.pptx
Understanding Plagiarism: Causes, Consequences and Prevention.pptxSasikiranMarri
 
What’s New in VictoriaMetrics: Q1 2024 Updates
What’s New in VictoriaMetrics: Q1 2024 UpdatesWhat’s New in VictoriaMetrics: Q1 2024 Updates
What’s New in VictoriaMetrics: Q1 2024 UpdatesVictoriaMetrics
 
Amazon Bedrock in Action - presentation of the Bedrock's capabilities
Amazon Bedrock in Action - presentation of the Bedrock's capabilitiesAmazon Bedrock in Action - presentation of the Bedrock's capabilities
Amazon Bedrock in Action - presentation of the Bedrock's capabilitiesKrzysztofKkol1
 
Leveraging AI for Mobile App Testing on Real Devices | Applitools + Kobiton
Leveraging AI for Mobile App Testing on Real Devices | Applitools + KobitonLeveraging AI for Mobile App Testing on Real Devices | Applitools + Kobiton
Leveraging AI for Mobile App Testing on Real Devices | Applitools + KobitonApplitools
 
GraphSummit Madrid - Product Vision and Roadmap - Luis Salvador Neo4j
GraphSummit Madrid - Product Vision and Roadmap - Luis Salvador Neo4jGraphSummit Madrid - Product Vision and Roadmap - Luis Salvador Neo4j
GraphSummit Madrid - Product Vision and Roadmap - Luis Salvador Neo4jNeo4j
 
Zer0con 2024 final share short version.pdf
Zer0con 2024 final share short version.pdfZer0con 2024 final share short version.pdf
Zer0con 2024 final share short version.pdfmaor17
 
Pros and Cons of Selenium In Automation Testing_ A Comprehensive Assessment.pdf
Pros and Cons of Selenium In Automation Testing_ A Comprehensive Assessment.pdfPros and Cons of Selenium In Automation Testing_ A Comprehensive Assessment.pdf
Pros and Cons of Selenium In Automation Testing_ A Comprehensive Assessment.pdfkalichargn70th171
 
Mastering Project Planning with Microsoft Project 2016.pptx
Mastering Project Planning with Microsoft Project 2016.pptxMastering Project Planning with Microsoft Project 2016.pptx
Mastering Project Planning with Microsoft Project 2016.pptxAS Design & AST.
 

Recently uploaded (20)

JavaLand 2024 - Going serverless with Quarkus GraalVM native images and AWS L...
JavaLand 2024 - Going serverless with Quarkus GraalVM native images and AWS L...JavaLand 2024 - Going serverless with Quarkus GraalVM native images and AWS L...
JavaLand 2024 - Going serverless with Quarkus GraalVM native images and AWS L...
 
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full RecordingOpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
 
The Ultimate Guide to Performance Testing in Low-Code, No-Code Environments (...
The Ultimate Guide to Performance Testing in Low-Code, No-Code Environments (...The Ultimate Guide to Performance Testing in Low-Code, No-Code Environments (...
The Ultimate Guide to Performance Testing in Low-Code, No-Code Environments (...
 
Osi security architecture in network.pptx
Osi security architecture in network.pptxOsi security architecture in network.pptx
Osi security architecture in network.pptx
 
Best Angular 17 Classroom & Online training - Naresh IT
Best Angular 17 Classroom & Online training - Naresh ITBest Angular 17 Classroom & Online training - Naresh IT
Best Angular 17 Classroom & Online training - Naresh IT
 
Advantages of Cargo Cloud Solutions.pptx
Advantages of Cargo Cloud Solutions.pptxAdvantages of Cargo Cloud Solutions.pptx
Advantages of Cargo Cloud Solutions.pptx
 
Understanding Flamingo - DeepMind's VLM Architecture
Understanding Flamingo - DeepMind's VLM ArchitectureUnderstanding Flamingo - DeepMind's VLM Architecture
Understanding Flamingo - DeepMind's VLM Architecture
 
Ronisha Informatics Private Limited Catalogue
Ronisha Informatics Private Limited CatalogueRonisha Informatics Private Limited Catalogue
Ronisha Informatics Private Limited Catalogue
 
2024 DevNexus Patterns for Resiliency: Shuffle shards
2024 DevNexus Patterns for Resiliency: Shuffle shards2024 DevNexus Patterns for Resiliency: Shuffle shards
2024 DevNexus Patterns for Resiliency: Shuffle shards
 
Keeping your build tool updated in a multi repository world
Keeping your build tool updated in a multi repository worldKeeping your build tool updated in a multi repository world
Keeping your build tool updated in a multi repository world
 
Large Language Models for Test Case Evolution and Repair
Large Language Models for Test Case Evolution and RepairLarge Language Models for Test Case Evolution and Repair
Large Language Models for Test Case Evolution and Repair
 
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
 
Understanding Plagiarism: Causes, Consequences and Prevention.pptx
Understanding Plagiarism: Causes, Consequences and Prevention.pptxUnderstanding Plagiarism: Causes, Consequences and Prevention.pptx
Understanding Plagiarism: Causes, Consequences and Prevention.pptx
 
What’s New in VictoriaMetrics: Q1 2024 Updates
What’s New in VictoriaMetrics: Q1 2024 UpdatesWhat’s New in VictoriaMetrics: Q1 2024 Updates
What’s New in VictoriaMetrics: Q1 2024 Updates
 
Amazon Bedrock in Action - presentation of the Bedrock's capabilities
Amazon Bedrock in Action - presentation of the Bedrock's capabilitiesAmazon Bedrock in Action - presentation of the Bedrock's capabilities
Amazon Bedrock in Action - presentation of the Bedrock's capabilities
 
Leveraging AI for Mobile App Testing on Real Devices | Applitools + Kobiton
Leveraging AI for Mobile App Testing on Real Devices | Applitools + KobitonLeveraging AI for Mobile App Testing on Real Devices | Applitools + Kobiton
Leveraging AI for Mobile App Testing on Real Devices | Applitools + Kobiton
 
GraphSummit Madrid - Product Vision and Roadmap - Luis Salvador Neo4j
GraphSummit Madrid - Product Vision and Roadmap - Luis Salvador Neo4jGraphSummit Madrid - Product Vision and Roadmap - Luis Salvador Neo4j
GraphSummit Madrid - Product Vision and Roadmap - Luis Salvador Neo4j
 
Zer0con 2024 final share short version.pdf
Zer0con 2024 final share short version.pdfZer0con 2024 final share short version.pdf
Zer0con 2024 final share short version.pdf
 
Pros and Cons of Selenium In Automation Testing_ A Comprehensive Assessment.pdf
Pros and Cons of Selenium In Automation Testing_ A Comprehensive Assessment.pdfPros and Cons of Selenium In Automation Testing_ A Comprehensive Assessment.pdf
Pros and Cons of Selenium In Automation Testing_ A Comprehensive Assessment.pdf
 
Mastering Project Planning with Microsoft Project 2016.pptx
Mastering Project Planning with Microsoft Project 2016.pptxMastering Project Planning with Microsoft Project 2016.pptx
Mastering Project Planning with Microsoft Project 2016.pptx
 

SOLID Principles Explained

  • 2.
  • 3.
  • 7. In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. http://en.wikipedia.org/wiki/Single_responsibility_principle
  • 8. The term was introduced by Robert C. Martin [...]. Martin described it as being based on the principle of cohesion, as described by Tom DeMarco in his book Structured Analysis and Systems Specification. http://en.wikipedia.org/wiki/Single_responsibility_principle
  • 9.
  • 10.
  • 11.
  • 12.
  • 13. We refer to a sound line of reasoning, for example, as coherent. The thoughts fit, they go together, they relate to each other. This is exactly the characteristic of a class that makes it coherent: the pieces all seem to be related, they seem to belong together, and it would feel somewhat unnatural to pull them apart. Such a class exhibits cohesion.
  • 14. utility  the state of being useful, profitable or beneficial  useful, especially through having several functions  functional rather than attractive Concise Oxford English Dictionary
  • 16. Every class should embody only about 3–5 distinct responsibilities. Grady Booch, Object Solutions
  • 17.
  • 18. One of the most foundational principles of good design is: Gather together those things that change for the same reason, and separate those things that change for different reasons. This principle is often known as the single responsibility principle, or SRP. In short, it says that a subsystem, module, class, or even a function, should not have more than one reason to change.
  • 20. Interface inheritance (subtyping) is used whenever one can imagine that client code should depend on less functionality than the full interface. Services are often partitioned into several unrelated interfaces when it is possible to partition the clients into different roles. For example, an administrative interface is often unrelated and distinct in the type system from the interface used by “normal” clients. "General Design Principles" CORBAservices
  • 21. The dependency should be on the interface, the whole interface, and nothing but the interface.
  • 22.
  • 23. We refer to a sound line of reasoning, for example, as coherent. The thoughts fit, they go together, they relate to each other. This is exactly the characteristic of a class that makes it coherent: the pieces all seem to be related, they seem to belong together, and it would feel somewhat unnatural to pull them apart. Such a class exhibits cohesion.
  • 24. We refer to a sound line of reasoning, for example, as coherent. The thoughts fit, they go together, they relate to each other. This is exactly the characteristic of an interface that makes it coherent: the pieces all seem to be related, they seem to belong together, and it would feel somewhat unnatural to pull them apart. Such an interface exhibits cohesion.
  • 25. public interface LineIO { String read(); void write(String toWrite); }
  • 26. public interface LineReader { String read(); } public interface LineWriter { void write(String toWrite); }
  • 27.
  • 29.
  • 30. In a purist view of object-oriented methodology, dynamic dispatch is the only mechanism for taking advantage of attributes that have been forgotten by subsumption. This position is often taken on abstraction grounds: no knowledge should be obtainable about objects except by invoking their methods. In the purist approach, subsumption provides a simple and effective mechanism for hiding private attributes.
  • 31. A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra. What is wanted here is something like the following substitution property: 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. Barbara Liskov "Data Abstraction and Hierarchy"
  • 33. E.g., Python's dict class, which is a hashed mapping container E.g., Python's OrderedDict class, which preserves order of insertion
  • 34.
  • 35.
  • 36. public class RecentlyUsedList { ... public int Count { get ... } public string this[int index] { get ... } public void Add(string newItem) ... ... }
  • 37. public class RecentlyUsedList { private IList<string> items = new List<string>(); public int Count { get { return items.Count; } } public string this[int index] { get { return items[index]; } } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... }
  • 38. public class RecentlyUsedList : List<string> { public override void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... }
  • 39. namespace List_spec { ... [TestFixture] public class Addition { private List<string> list; [Setup] public void List_is_initially_empty() { list = ... } ... [Test] public void Addition_of_non_null_item_is_appended() ... [Test] public void Addition_of_null_is_permitted() ... [Test] public void Addition_of_duplicate_item_is_appended() ... ... } ... }
  • 40. namespace List_spec { ... [TestFixture] public class Addition { private List<string> list; [Setup] public void List_is_initially_empty() { list = new List<string>(); } ... [Test] public void Addition_of_non_null_item_is_appended() ... [Test] public void Addition_of_null_is_permitted() ... [Test] public void Addition_of_duplicate_item_is_appended() ... ... } ... }
  • 41. namespace List_spec { ... [TestFixture] public class Addition { private List<string> list; [Setup] public void List_is_initially_empty() { list = new RecentlyUsedList(); } ... [Test] public void Addition_of_non_null_item_is_appended() ... [Test] public void Addition_of_null_is_permitted() ... [Test] public void Addition_of_duplicate_item_is_appended() ... ... } ... }
  • 42. A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra. What is wanted here is something like the following substitution property: 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. Barbara Liskov "Data Abstraction and Hierarchy"
  • 43. A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra. What is wanted here is something like the following substitution property: 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. Barbara Liskov "Data Abstraction and Hierarchy"
  • 44. A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra. What is wanted here is something like the following substitution property: 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. Barbara Liskov "Data Abstraction and Hierarchy"
  • 45. A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra. What is wanted here is something like the following substitution property: 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. Barbara Liskov "Data Abstraction and Hierarchy"
  • 47. Bertrand Meyer gave us guidance as long ago as 1988 when he coined the now famous open-closed principle. To paraphrase him: Software entites (classes, modules, functions, etc.) should be open for extension, but closed for modification. Robert C Martin "The Open-Closed Principle" C++ Report, January 1996
  • 48. Open for extension Closed for extension Closed for modification Open for modification Extend existing code without changing it, e.g., using a framework Extend or change existing code, e.g., open-source and unpublished code Non-extensible and unchangeable code, e.g., composable code or legacy code Non-extensible code that can be maintained, e.g., composable code in a maintained library
  • 49.
  • 50. The principle stated that a good module structure should be both open and closed:  Closed, because clients need the module's services to proceed with their own development, and once they have settled on a version of the module should not be affected by the introduction of new services they do not need.  Open, because there is no guarantee that we will include right from the start every service potentially useful to some client.
  • 51. [...] A good module structure should be [...] closed [...] because clients need the module's services to proceed with their own development, and once they have settled on a version of the module should not be affected by the introduction of new services they do not need.
  • 52. Published Interface is a term I used (first in Refactoring) to refer to a class interface that's used outside the code base that it's defined in. Martin Fowler http://martinfowler.com/bliki/PublishedInterface.html
  • 53.
  • 54. There is no problem changing a method name if you have access to all the code that calls that method. Even if the method is public, as long as you can reach and change all the callers, you can rename the method.
  • 55. There is a problem only if the interface is being used by code that you cannot find and change. When this happens, I say that the interface becomes a published interface (a step beyond a public interface).
  • 56. Published Interface is a term I used (first in Refactoring) to refer to a class interface that's used outside the code base that it's defined in. The distinction between published and public is actually more important than that between public and private. The reason is that with a non-published interface you can change it and update the calling code since it is all within a single code base. [...] But anything published so you can't reach the calling code needs more complicated treatment. Martin Fowler http://martinfowler.com/bliki/PublishedInterface.html
  • 57. [...] A good module structure should be [...] open [...] because there is no guarantee that we will include right from the start every service potentially useful to some client.
  • 58.
  • 59. Speculative Generality Brian Foote suggested this name for a smell to which we are very sensitive. You get it when people say, "Oh, I think we need the ability to do this kind of thing someday" and thus want all sorts of hooks and special cases to handle things that aren't required.
  • 61. A myth in the object-oriented design community goes something like this: If you use object-oriented technology, you can take any class someone else wrote, and, by using it as a base class, refine it to do a similar task. Robert B Murray C++ Strategies and Tactics
  • 62.
  • 63. Design and implement for inheritance or else prohibit it By now, it should be apparent that designing a class for inheritance places substantial limitations on the class.
  • 64.
  • 66. http://blog.8thlight.com/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html I've heard it said that the OCP is wrong, unworkable, impractical, and not for real programmers with real work to do. The rise of plugin architectures makes it plain that these views are utter nonsense. On the contrary, a strong plugin architecture is likely to be the most important aspect of future software systems.
  • 69. public abstract class Shape { ... } public class Square : Shape { ... public void DrawSquare() ... } public class Circle : Shape { ... public void DrawCircle() ... }
  • 70. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) if (s is Square) (s as Square).DrawSquare(); else if (s is Circle) (s as Circle).DrawCircle(); }
  • 71. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) if (s is Square) (s as Square).DrawSquare(); else if (s is Circle) (s as Circle).DrawCircle(); }
  • 72. public abstract class Shape { ... public abstract void Draw(); } public class Square : Shape { ... public override void Draw() ... } public class Circle : Shape { ... public override void Draw() ... }
  • 73. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) s.Draw(); }
  • 74. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) s.Draw(); }
  • 75. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) s.Draw(); }
  • 76. Bertrand Meyer gave us guidance as long ago as 1988 when he coined the now famous open-closed principle. To paraphrase him: Software entites (classes, modules, functions, etc.) should be open for extension, but closed for modification. Robert C Martin "The Open-Closed Principle" C++ Report, January 1996
  • 77. Bertrand Meyer gave us guidance as long ago as 1988 when he coined the now famous open-closed principle. To paraphrase him: Software entites (classes, modules, functions, etc.) should be open for extension, but closed for modification. Robert C Martin "The Open-Closed Principle" C++ Report, January 1996
  • 78. This double requirement looks like a dilemma, and classical module structures offer no clue. This double requirement looks like a dilemma, and classical module structures offer no clue. But inheritance solves it. This double requirement looks like a dilemma, and classical module structures offer no clue. But inheritance solves it. A class is closed, since it may be compiled, stored in a library, baselined, and used by client classes. But it is also open, since any new class may use it as parent, adding new features.
  • 79. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) if (s is Square) (s as Square).DrawSquare(); else if (s is Circle) (s as Circle).DrawCircle(); }
  • 80. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) if (s is Square) (s as Square).DrawSquare(); else if (s is Circle) (s as Circle).DrawCircle(); }
  • 81. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) s.Draw(); }
  • 82. public abstract class Shape ... public class Square : Shape ... public class Circle : Shape ... static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) s.Draw(); }
  • 83. public sealed class Shape { public enum Type { Square, Circle } ... public void Draw() ... } static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) s.Draw(); }
  • 84. public sealed class Shape { public enum Type { Square, Circle } ... public void Draw() ... } static void DrawAllShapes(Shape[] list) { foreach (Shape s in list) s.Draw(); }
  • 85. Don't publish interfaces prematurely. Modify your code ownership policies to smooth refactoring.
  • 87. In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high- level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details. http://en.wikipedia.org/wiki/Dependency_inversion_principle
  • 88. The principle states: A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend upon details. Details should depend upon abstractions. http://en.wikipedia.org/wiki/Dependency_inversion_principle
  • 89. inversion, noun  the action of inverting or the state of being inverted  reversal of the normal order of words, normally for rhetorical effect  an inverted interval, chord, or phrase  a reversal of the normal decrease of air temperature with altitude, or of water temperature with depth Concise Oxford English Dictionary
  • 91.
  • 92.
  • 93.
  • 94.
  • 95. Stewart Brand, How Buildings Learn See also http://www.laputan.org/mud/
  • 97.        Scenario buffering by dot-voting possible changes and invert dependencies as needed
  • 98. One of the most foundational principles of good design is: Gather together those things that change for the same reason, and separate those things that change for different reasons. This principle is often known as the single responsibility principle, or SRP. In short, it says that a subsystem, module, class, or even a function, should not have more than one reason to change.
  • 99. At some level the style becomes the substance.