Introducing SOLID

Introducing
SOLID Object-Oriented Design Principles

and
Microsoft Unity
Regina .NET User Group
Tuesday, May 5, 2009
©2008 Protegra Inc. All rights reserved.

Agenda
• adaptive software development

• missing technical principles and practices
• SOLID principles
• object-oriented concepts
• cohesion, coupling
• abstraction, encapsulation, inheritance, polymorphism
• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle
• Microsoft Unity Application Block
• dependency injection
©2009 Protegra Inc. All rights reserved. 2

Adaptive Software Development
• Manifesto for Agile Software Development

agilemanifesto.org
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.
• Principles behind the Agile Manifesto

agilemanifesto.org/principles.html
• welcome changing requirements, even late in development
• continuous attention to technical excellence and
good design enhances agility

• Scrum

• non-technical principles and practices

• what about technical principles and practices?

• Flaccid Scrum,
Martin Fowler, January 29, 2009
martinfowler.com/bliki/FlaccidScrum.html
• “What's happened [with quite a few Scrum
projects recently] is that they haven't paid
enough attention to the internal quality of their
software. If you make that mistake you'll soon
find your productivity dragged down because
it's much harder to add new features than
you'd like….
“The scrum community needs to redouble its efforts to

ensure that people understand the importance of
strong technical practices.”

• Fixing the Agile Engineering Problem,

George Dinwiddie, January 30, 2009
blog.gdinwiddie.com/2009/01/30/fixing-the-agile-engineering-problem/
• “…developers have to learn to recognize
what is ‘better,’ they have to learn how to do it,
and the cultural context in which they work
has to change such that it really is important
enough to have happen.”

• recommended reading
Robert C. Martin is the author of

award-winning books on
object-oriented design and
Agile development

SOLID Principles
Software Development is not a Jenga game.

SOLID Principles
• Single Responsibility Principle

• en.wikipedia.org/wiki/Single_responsibility_principle
• Open/Closed Principle
• en.wikipedia.org/wiki/Open/closed_principle
• Liskov Substitution Principle
• en.wikipedia.org/wiki/Liskov_substitution_principle
• Interface Segregation Principle
• www.oodesign.com/interface-segregation-principle.html
• Dependency Inversion Principle
• en.wikipedia.org/wiki/Dependency_inversion_principle

Object-Oriented Concepts
• cohesion
• coupling
• abstraction
• encapsulation
• inheritance
• polymorphism

• cohesion
• en.wikipedia.org/wiki/Cohesion_(computer_science)
• “…a measure of how strongly-related and focused the various
responsibilities of a software module are.”
•
• “Modules with high cohesion tend to be preferable because

high cohesion is associated with several desirable traits of software
including robustness, reliability, reusability, and understandability
whereas low cohesion is associated with undesirable traits
such as being difficult to maintain, difficult to test,
difficult to reuse, and even difficult to understand.”

• coupling
• en.wikipedia.org/wiki/Coupling_(computer_science)
• “… the degree to which each program module relies on
each one of the other modules.”
•

• coupling, continued
• “Low coupling refers to a relationship in which one module
interacts with another module through a stable interface and does not
need to be concerned with the other module's internal implementation….
With low coupling, a change in one module will not require a change
in the implementation of another module. Low coupling is often a sign of a
well-structured computer system, and when combined with high cohesion,
supports the general goals of high readability and maintainability.”

• abstraction
• en.wikipedia.org/wiki/Abstraction_(computer_science)
• “…a mechanism and practice to reduce and factor out details
so that one can focus on a few concepts at a time.”
•

• encapsulation
• en.wikipedia.org/wiki/Encapsulation_(computer_science)
• “…the hiding of the internal mechanisms and data structures of a
software component behind a defined interface, in such a way that
users of the component (other pieces of software) only need to know
what the component does, and cannot make themselves dependent
on the details of how it does it.”
•
// Reference System.Speech
new SpeechSynthesizer()
.Speak(
"Hello, " +
"Regina .NET User Group!"
);

• inheritance
• en.wikipedia.org/wiki/Inheritance_(computer_science)
• “…a way to form new classes (instances of which are called objects)
using classes that have already been defined.”
•

• polymorphism
• en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming
• “…the ability of one type, A, to appear as and be used like
another type, B. In strongly typed languages, this usually means that
type A somehow derives from type B, or type A implements
an interface that represents type B.”
•
catch (ArgumentException) {
...
}

The Single Responsibility Principle
• A class should have only one reason to change.

•
Just because you can, doesn’t mean you should.

• does not adhere to the principle

•

• does not adhere to the principle

•
• connection management
• data transfer
• operating system features

• does adhere to the principle

•
• random number generation

• benefits
• code is smaller
• easier to read
• easier to understand
• easier to maintain
• code is potentially easier to test
• change is easier to manage
• code is easier to replace
• contention may be reduced for source code files
among multiple developers
• deployment may be reduced

• call to action
• recognize the class as the software building block
• make classes which
• do one thing or change for only one reason
• are small
• are easy to read and understand
• are easy to maintain
• are potentially easy to test
• are easy to replace
• ensure high cohesion
• each member should directly relate to the class name
• remember that it’s a principle, not a rule;
use your professional skills and experience

The Open/Closed Principle
• Software entities (classes, modules, functions, etc.)

should be open for extension but closed for modification.

• customer
• “Please log all errors to a file.”
• demonstration
• SolidDemonstration

• customer
• “On the other hand, please log all errors to the event log.”
• “Actually, I’d like all errors logged to….”

• abstractions
•
Client <<interface>> abstraction (interface)
Server
•
Client ServerBase abstraction (abstract class)
Server

• demonstration
•
Logger LogWriter abstraction (abstract class)
FileLogWriter

• demonstration
•
Logger LogWriter
FileLogWriter EventLogWriter new code
• changes are made by adding, not modifying, code

Eating something different shouldn’t require open chest surgery.

• benefits
• design is more stable
• existing (working) code does not change
• changes are made by adding, not modifying, code
• changes are isolated and do not cascade throughout the code
• design is extensible
• code is potentially reusable
• deployment may be reduced

• call to action
• implement potentially volatile code as abstractions
• use short iterations and frequent demonstrations
• develop features before infrastructure
• develop the most important features first

The Liskov Substitution Principle
• Subtypes must be substitutable for their base types.

• subtypes must be substitutable

•
Logger LogWriter
FileLogWriter EventLogWriter substitutable

If it looks like a duck, quacks like a duck, but needs batteries, you
probably have the wrong abstraction.

• benefits
• design is more flexible
• a base type can be confidently substituted for a derived type
• required to support the Open/Closed Principle

• call to action
• ensure that
• the base type can be substituted for a derived type
• derived types are substitutable for their base type
• avoid runtime type checking

The Interface Segregation Principle
• Clients should not be forced to depend on methods

they do not use.

You want me to plug this in where?

• demonstration

• benefits
• cohesion is increased
• clients can demand cohesive interfaces
• design is more stable
• changes are isolated and do not cascade throughout the code
• supports the Liskov Substitution Principle

• call to action
• consider the needs of the client when designing the interface
• create client-specific interfaces

The Dependency Inversion Principle
• High-level modules should not depend on

low-level modules.
• Both should depend on abstractions.
•
high-level module
abstraction
low-level module

• Abstractions should not depend upon details.

• Details should depend upon abstractions.
•
abstraction
details

Would you solder a lamp directly to the electrical wiring in the wall?

• benefits
• design is extensible
• required to support the Open/Closed Principle

• call to action
• create abstractions
• depend on abstractions
• declare parameters and variables as an interface or abstract class
• derive only from abstract classes
• override only abstract members

Microsoft Unity Application Block
• Unity Application Block 1.2 - October 2008

• msdn.microsoft.com/unity/
•
• Unity is a lightweight, extensible dependency injection container.

• It facilitates building loosely coupled applications and provides
developers with the following advantages:
• simplified object creation
• abstraction of requirements
• increased flexibility
• service location capability
• instance and type interception


• demonstration
• container configuration
• imperative
• declarative
• object creation

• Unity Configuration Schematic

msdn.microsoft.com/library/dd203182.aspx
•

Summary
• call to action
• make small classes
• create and depend on abstractions
• avoid runtime type checking
• ensure substitutability
• create client-specific interfaces
• evaluate the Microsoft Unity Application Block
(or alternate dependency injection container)
• remember that these are principles, not rules;
• have fun!

Contact
• Uwe Schmitz
Technical Architect
uschmitz@protegra.com
(204) 272-2293
• Protegra
67 Scurfield Boulevard
Winnipeg, MB
www.protegra.com
• Agile Principles, Patterns,

and Practices in C#
Robert C. Martin
ISBN: 978-0131857254

Introducing SOLID

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introducing SOLID

Uploaded by

Copyright:

Available Formats

Introducing

SOLID Object-Oriented Design Principles

©2008 Protegra Inc. All rights reserved.

• adaptive software development

©2009 Protegra Inc. All rights reserved. 2

• Manifesto for Agile Software Development

• Principles behind the Agile Manifesto

©2009 Protegra Inc. All rights reserved. 3

©2009 Protegra Inc. All rights reserved. 4

• non-technical principles and practices

©2009 Protegra Inc. All rights reserved. 5

“The scrum community needs to redouble its efforts to

©2009 Protegra Inc. All rights reserved. 6

• Fixing the Agile Engineering Problem,

©2009 Protegra Inc. All rights reserved. 7

Robert C. Martin is the author of

©2009 Protegra Inc. All rights reserved. 8

Software Development is not a Jenga game.

©2009 Protegra Inc. All rights reserved. 9

• Single Responsibility Principle

©2009 Protegra Inc. All rights reserved. 10

©2009 Protegra Inc. All rights reserved. 11

• “Modules with high cohesion tend to be preferable because

©2009 Protegra Inc. All rights reserved. 12

©2009 Protegra Inc. All rights reserved. 13

©2009 Protegra Inc. All rights reserved. 14

©2009 Protegra Inc. All rights reserved. 15

©2009 Protegra Inc. All rights reserved. 16

©2009 Protegra Inc. All rights reserved. 17

©2009 Protegra Inc. All rights reserved. 18

• A class should have only one reason to change.

Just because you can, doesn’t mean you should.

©2009 Protegra Inc. All rights reserved. 19

• does not adhere to the principle

©2009 Protegra Inc. All rights reserved. 20

• does not adhere to the principle

©2009 Protegra Inc. All rights reserved. 21

• does adhere to the principle

• random number generation

©2009 Protegra Inc. All rights reserved. 22

©2009 Protegra Inc. All rights reserved. 23

©2009 Protegra Inc. All rights reserved. 24

• Software entities (classes, modules, functions, etc.)

©2009 Protegra Inc. All rights reserved. 25

©2009 Protegra Inc. All rights reserved. 26

©2009 Protegra Inc. All rights reserved. 27

©2009 Protegra Inc. All rights reserved. 28

©2009 Protegra Inc. All rights reserved. 29

FileLogWriter EventLogWriter new code

• changes are made by adding, not modifying, code

©2009 Protegra Inc. All rights reserved. 30

Eating something different shouldn’t require open chest surgery.

©2009 Protegra Inc. All rights reserved. 31

©2009 Protegra Inc. All rights reserved. 32

©2009 Protegra Inc. All rights reserved. 33

• Subtypes must be substitutable for their base types.

©2009 Protegra Inc. All rights reserved. 34

• subtypes must be substitutable

FileLogWriter EventLogWriter substitutable

©2009 Protegra Inc. All rights reserved. 35

©2009 Protegra Inc. All rights reserved. 36

©2009 Protegra Inc. All rights reserved. 37

©2009 Protegra Inc. All rights reserved. 38

• Clients should not be forced to depend on methods