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

Refactoring to SOLID Code

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

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