writing solid code - welcome to
TRANSCRIPT
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
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: [email protected]
http://jeffbarnes.net/blog
http://twitter.com/jeff_barnes