refactoring to solid code

42
Design Principles & Practices Emerging .NET Devs October User Group Meeting Adil Ahmed Mughal Zubair Ahmed

Upload: adil-mughal

Post on 05-Dec-2014

3.646 views

Category:

Technology


9 download

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.

TRANSCRIPT

Page 1: Refactoring to SOLID Code

Design Principles & Practices

Emerging .NET Devs October User Group Meeting

Adil Ahmed Mughal Zubair Ahmed

Page 2: Refactoring to SOLID Code

Refactoring to SOLID Code

Emerging .NET Devs

Page 3: Refactoring to SOLID Code

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

Page 4: Refactoring to SOLID Code

Speaker => Adil Ahmed Mughal Affiliations:

Contact Information:

@adilamughal

http://www.adilmughal.com

[email protected]

Page 5: Refactoring to SOLID Code

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!

Page 6: Refactoring to SOLID Code

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?

Page 7: Refactoring to SOLID Code
Page 8: Refactoring to SOLID Code

Bad design is...

Rigid

Fragile

Immobile

Viscous

Needless Complexity

Needless Repetition

Page 9: Refactoring to SOLID Code
Page 10: Refactoring to SOLID Code
Page 11: Refactoring to SOLID Code

What would You Call a Good Design?

• Reliability

• Flexibility

• Separations of Concerns

• Reusability

• Maintainability

Page 12: Refactoring to SOLID Code

SOLID

Object Oriented Principles Introduced by Robert C. Martin in

early 2000s

Page 13: Refactoring to SOLID Code

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)

Page 14: Refactoring to SOLID Code

Single Responsibility Principle (SRP)

Page 15: Refactoring to SOLID Code
Page 16: Refactoring to SOLID Code

The Single Responsibility Principle

"A responsibility is a reason to change, a class or module should have one, and only one, reason to change."

Page 17: Refactoring to SOLID Code

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

Page 18: Refactoring to SOLID Code

Trade Validator

Trade Validator

Trade DB

What is wrong here: Changes if DB changes or Business Logic Changes

Page 19: Refactoring to SOLID Code

Refactored Trade Validator

Trade Validator

Trade

DB

Trade Source

What's its job? Classes must have an identifiable single responsibility.

Page 20: Refactoring to SOLID Code
Page 21: Refactoring to SOLID Code

The Open-Closed Principle (OCP)

Page 22: Refactoring to SOLID Code

The Open Closed Principle

“Software Entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification”

Page 23: Refactoring to SOLID Code

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?

Page 24: Refactoring to SOLID Code

OCP – Change behavior without changing code?

• Abstraction is the key to achieve it

Server Client

Closed Client

Page 25: Refactoring to SOLID Code

OCP – Change behavior without changing code?

Abstract Server

Client

Open Client

Server

Page 26: Refactoring to SOLID Code
Page 27: Refactoring to SOLID Code

Liskov Substitution Principle (LSP)

Page 28: Refactoring to SOLID Code

Liskov Substitution Principle

“Functions that reference a base class must be able to use objects of derived classes without knowing it."

Page 29: Refactoring to SOLID Code
Page 30: Refactoring to SOLID Code

Interface Segregation Principle (ISP)

Page 31: Refactoring to SOLID Code

Interface Segregation Principle

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

• Prefer small, cohesive interfaces to fat interfaces

Page 32: Refactoring to SOLID Code
Page 33: Refactoring to SOLID Code

Dependency Inversion Principle (DIP)

Page 34: Refactoring to SOLID Code

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.”

Page 35: Refactoring to SOLID Code

Trade Validator

Trade Validator

Trade DB

Trade Source

High Level (Less Stable)

Low Level (More Stable)

Introduce stability with abstraction

Page 36: Refactoring to SOLID Code

Better Trade Validator

Trade Validator

Trade

DB

DbTradeSource

<Interface> ITradeSource

Page 37: Refactoring to SOLID Code

Extensible Trade Validator

TradeValidator

Trade

DB

DbTradeSource

<Interface> ITradeSource

WSTradeSource

Cloud

Page 38: Refactoring to SOLID Code
Page 39: Refactoring to SOLID Code

DEMO

Let’s Refactor!

Page 40: Refactoring to SOLID Code

Actions => From Now On

Books:

Learn, Practice and Make it your Habit

Links:

- ObjectMentor.com - Practices and Patterns on MSDN

Page 41: Refactoring to SOLID Code

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

Page 42: Refactoring to SOLID Code

Thank You!

Refactoring to SOLID Code

Emerging .NET Devs