"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.
3. Session => Refactoring to SOLID Code
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
Sponsors:
4. Speaker => Adil Ahmed Mughal
Affiliations:
Contact Information:
adil.mughal@live.com
@adilamughal
http://www.adilmughal.com
5. 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!
6. 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?
16. The Single Responsibility Principle
"A responsibility is a reason to change, a class or
module should have one, and only one, reason
to change."
17. 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
18. Trade Validator
Trade
Validator
DB
Trade
What is wrong here: Changes if DB
changes or Business Logic Changes
19. Refactored Trade Validator
Trade Trade
Validator Source
Trade
DB
What's its job?
Classes must have an identifiable single
responsibility.
22. The Open Closed Principle
“Software Entities (Classes, Modules, Functions,
etc.) should be open for extension, but closed for
modification”
23. 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?
24. OCP – Change behavior without
changing code?
• Abstraction is the key to achieve it
Client Server
Closed Client
25. OCP – Change behavior without
changing code?
Client Abstract
Server
Server
Open Client
31. Interface Segregation Principle
“Clients should not be forced to depend upon
interfaces that they do not use.”
• Prefer small, cohesive interfaces to fat
interfaces
34. 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.”
35. Trade Validator
Introduce stability
High Level (Less Stable) with abstraction
Trade Trade
Validator Source
Trade
Low Level DB
(More Stable)
40. Actions => From Now On
Learn, Practice and Make it your Habit
Links:
- ObjectMentor.com
- Practices and Patterns on MSDN
Books:
41. 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