Upload
adil-mughal
View
3.645
Download
9
Embed Size (px)
DESCRIPTION
"Refactoring to SOLID Code" session presentation from Emerging .NET Devs - October 2011 User Group Meeting.Please note that this presentation has been simplified for publishing.
Citation preview
Design Principles & Practices
Emerging .NET Devs October User Group Meeting
Adil Ahmed Mughal Zubair Ahmed
Refactoring to SOLID Code
Emerging .NET Devs
Session => Refactoring to SOLID Code
Sponsors:
What You must already know: - Object Oriented Programming Language such as Java, C++, C# - Professional Experience
What You will learn today: - Good Practices - OO Principles
Speaker => Adil Ahmed Mughal Affiliations:
Contact Information:
@adilamughal
http://www.adilmughal.com
Agenda
This is not a single side talk, its discussion!
Promise me that you will raise hand when you have query?
• How You Code Today?
• What is Bad Design?
• What would You Call a Good Design?
• SOLID Principles!
How You Code Today?
• Do you care about design principles or patterns?
• Anti-patterns?
• Is your code Agile?
• Do you Refactor your code?
• Is your code design bad or good?
Bad design is...
Rigid
Fragile
Immobile
Viscous
Needless Complexity
Needless Repetition
What would You Call a Good Design?
• Reliability
• Flexibility
• Separations of Concerns
• Reusability
• Maintainability
SOLID
Object Oriented Principles Introduced by Robert C. Martin in
early 2000s
SOLID Principles
• S – Single Responsibility Principle (SRP)
• O – Open Closed Principle (OCP)
• L – Liskov Substitution Principle (LSP)
• I – Interface Segregation Principle (ISP)
• D – Dependency Inversion Principle (DIP)
Single Responsibility Principle (SRP)
The Single Responsibility Principle
"A responsibility is a reason to change, a class or module should have one, and only one, reason to change."
The Single Responsibility Principle
• “There should never be more than one reason for a class to change.”
• More responsibilities => More likelihood of change
• Dijkstra’s SoC: separation of concerns
• Applies on every level of code
• Solves the naming dilemma
Trade Validator
Trade Validator
Trade DB
What is wrong here: Changes if DB changes or Business Logic Changes
Refactored Trade Validator
Trade Validator
Trade
DB
Trade Source
What's its job? Classes must have an identifiable single responsibility.
The Open-Closed Principle (OCP)
The Open Closed Principle
“Software Entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification”
The Open Closed Principle
• Modules that conform to the open-closed principle have
two primary attributes
– Open For Extension
• behavior of the module can be extended
– Closed for Modification
• The source code of such a module is inviolate
• The normal way to extend the behavior of a module is to
make changes to that module. How can these two opposing attributes be resolved?
OCP – Change behavior without changing code?
• Abstraction is the key to achieve it
Server Client
Closed Client
OCP – Change behavior without changing code?
Abstract Server
Client
Open Client
Server
Liskov Substitution Principle (LSP)
Liskov Substitution Principle
“Functions that reference a base class must be able to use objects of derived classes without knowing it."
Interface Segregation Principle (ISP)
Interface Segregation Principle
“Clients should not be forced to depend upon interfaces that they do not use.”
• Prefer small, cohesive interfaces to fat interfaces
Dependency Inversion Principle (DIP)
Dependency Inversion Principle
“High level modules should not depend upon low level modules. Both should depend upon abstractions. “
“Abstractions should not depend upon details. Details should depend upon abstractions.”
Trade Validator
Trade Validator
Trade DB
Trade Source
High Level (Less Stable)
Low Level (More Stable)
Introduce stability with abstraction
Better Trade Validator
Trade Validator
Trade
DB
DbTradeSource
<Interface> ITradeSource
Extensible Trade Validator
TradeValidator
Trade
DB
DbTradeSource
<Interface> ITradeSource
WSTradeSource
Cloud
DEMO
Let’s Refactor!
Actions => From Now On
Books:
Learn, Practice and Make it your Habit
Links:
- ObjectMentor.com - Practices and Patterns on MSDN
References
• Combatting Software Entropy using Design Principles
and Practices – Hammad Rajjoub – TechEd ME
• Agile Principles, Patterns and Practices using C# by
Robert.C.Martin
• Special thanks for motivational poster images by
NimblePros
Thank You!
Refactoring to SOLID Code
Emerging .NET Devs