writing solid code - welcome to

WRITING SOLID CODE

An Introduction to the SOLID Principles

About Me

Jeff Barnes

.NET Software Craftsman @ DAXKO

Microsoft MVP in Connected Systems

ALT.NET Supporter

jeff@jeffbarnes.net

http://jeffbarnes.net/blog

http://twitter.com/jeff_barnes

Disclaimer

I do not claim to be an expert in anything!

I’m simply here to share ideas and knowledge regarding topics on which I am quite passionate.

Question everything I say and form your own opinions based on the information!

Credit Where Credit Is Due

This presentation was heavily influenced by:

Robert Martin’s SOLID material

Derick Bailey’s SOLID presentation

Los Techies SOLID Principles eBook

Numerous random resources

Links will be provided on the resources slide at the end of the presentation.

Agenda

Quick review of relevant OOP concepts

What are the SOLID Principles?

How do they improve class design?

Why should you care?

Persuade you to embrace them! (I hope)

What is SOLID?

Collection of best practices for approaching object oriented design to achieve: Loose Coupling

High Cohesion

Increased Flexibility/Maintainability

Acronym of Acronyms

Principles were coined by Robert Martin

Principles address dependency management

S.O.L.I.D.

RP:

CP:

SP:

SP:

IP:

The Big Picture

Brief Review of Essential OOP

Important concepts related to SOLID:

Cohesion

Coupling

Encapsulation

Cohesion

“A measure of how strongly-related and focused the various responsibilities of a software module are” - Wikipedia

Coupling

“The degree to which each program module relies on each one of the other modules” – Wikipedia

Encapsulation

“The hiding of design decisions in a computer program that are most likely to change” - Wikipedia

Single Responsibility Principle

Single Responsibility Principle

There should never be more than one reason for a class to change.

Saith Uncle Bob:

“If a class has more then one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.”

Single Responsibility Principle

My Take:

Focus on the words “reason for change”

Doesn’t mean the class literally only does one thing

Ask yourself:

Is the functionality within the class really related?

Are separate concerns being blurred together?

Simple it is, easy it is not.

All other principles tie back to this one.

Open Closed Principle

Open Closed Principle

Modules that conform to the open-closed principle have two primary attributes.

1. They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.

2. They are “Closed for Modification”.The source code of such a module is inviolate. No one is allowed to make source code changes to it.

Open Closed Principle

My Take:

Minimizes impact to the rest of the system.

Avoid lots of slightly different methods.

Ask yourself:

If I need to alter behavior, are modifications required?

How can I enable extensibility for the consumer?

Proper abstraction is critical.

Inheritance can work, but think composition!

Liskov Substitution Principle

Liskov Substitution Principle

Functions that use…references to base classes must be able to use objects of derived classes without knowing it.

Quote from Barbara Liskov:“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.”

Liskov Substitution Principle

My Take:

If/Switch logic based on type is usually a smell.

Can provide warning signs for design flaws.

Ask yourself:

Why do I need to know the type?

Why am I casting to a more specific type?

Violation of LSP also violates OCP.

Reinforces the concept of design by contract.

Interface Segregation Principle

Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use.

Saith Uncle Bob:“This principle deals with the disadvantages of ‘fat’ interfaces. Classes that have ‘fat’ interfaces are classes whose interfaces are not cohesive. In other words, the interfaces of the class can be broken up into groups of member functions. Each group serves a different set of clients. Thus some clients use one group of member functions, and other clients use the other groups.”

Interface Segregation Principle

My Take:

Applying SRP to interfaces.

Choose to make life happy or hell for consumers.

Ask yourself:

Do these methods really belong together?

Will the consumer require all of the methods?

Violation can lead to inadvertent coupling.

See WCF and ASP.NET for violation examples.

Dependency Inversion Principle

I got a fever, and the only

prescription…is more cowbell!

Dependency Inversion Principle

1) High level modules should not depend upon low level modules. Both should depend upon abstractions.

2) Abstractions should not depend upon details. Details should depend upon abstractions.

Dependency Inversion Principle

Saith Uncle Bob:

“What is it that makes a design rigid, fragile and immobile?

It is the interdependence of the modules within that design. A design is rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules.”

Dependency Inversion Principle

My Take:

Another way of saying Dependency Injection

Critical for truly flexible software

Ask yourself:

Am I using “details” or “abstractions”? Why?

Where should this dependency come from?

Fight against rigid, fragile, immobile code

Leads you to IoC containers (for large scale)

Resources

http://bit.ly/vmV73 (LosTechies Free eBook)

http://bit.ly/7lcxjx (Derick Bailey Presentation)

http://bit.ly/17QX2a (Uncle Bob Articles)

Contact Me: jeff@jeffbarnes.net

http://jeffbarnes.net/blog

http://twitter.com/jeff_barnes