C:\Fakepath\Combating Software Entropy 2

ARC202 - Combating Software Entropy with Design Patterns and Principles
Hammad Rajjoub
Solutions Architect @ Infusion
Microsoft MVP

Cogito, Ergo , Sum
Microsoft MVP – Connected Systems (5+ yrs)
Solutions Architect at Infusion
The coolest company in town
Develop. Design. Venture.  Join us!
Speaker, Author & Community Leader
I do: Blog + Twitter + PodCast
Bing me http://www.bing.com/search?q=hammadrajjoub

Agenda
Why is Software Complex?
What is bad design?
How to Fix it?
Summary
References
QnA

Why is Software Complex
Writing new software
Mandated to develop new systems
Generally from scratch
But still mostly relying on existing libraries and frameworks
Real-world problems are sometimes complex
Modifying Existing Software
Find that ‘bug’ and ‘fix’ it
Add a new exciting feature
Review and refactor to a better design

What is bad design?

Bad design is...
Hard to change!
A single change break lots of other code
Rigid
Fragile
Can’t be ‘extended’
Immobile

How to fix it?
Using design principles and practices
The Single Responsibility Principle
The Open Closed Principle
Liskov Substitution Principle
Dependency Inversion Principle
Using Software Design Metrics
And yes a whole lot of refactoring 

Single Responsibility Principle
None but Buddha himself must take the responsibility of giving out occult secrets...
E. Cobham Brewer 1810–1897.
Dictionary of Phrase and Fable. 1898.
SRP

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

The Single Responsibility Principal
Responsibility is a ‘Reason for change’
Each responsibility is an axis of change
There should never be more than one reason for a class to change
Dijkstra’s SoC: Separation of Concerns
This helps us evaluate a class ‘s
exposure to change

BusinessPartnerValidtor Module
Example:

BusinessPartnerValidator
BusinessPartner
Validator
DB
Trade
What is wrong here: Changes if DB changes or Business Logic Changes

Counterparty Validator – Iter 1
internal class BusinessPartnerValidator
{
public void AssertValid(Trade t)
{
varsql = "SELECT COUNT(*) FROM BusinessPartner WHERE name=@Name";
using (varconn = CreateOpenConnection())
{
varcmd = new SqlCommand(sql, conn);
cmd.Parameters.Add("@Name", SqlDbType.VarChar);
cmd.Parameters["@name"].Value = t.BusinessPartnerName;
var count = (Int32) cmd.ExecuteScalar();
if (count != 1) throw new InvalidBusinessPartyException(t.BusinessPartyName);
}
}
...
Where is the business logic?
Hidden by database code.

BusinessPartyValidator – Iter 2
internal class BusinessPartnerValidator
{
private readonlyBusinessPartnerValidatorbusinessPartnersource;
public BusinessPartyValidator(BusinessPartnerSourceBusinessPartySource)
{
this.businessPartnerSource = BusinessPartnerSource;
}
public void AssertValid(Trade t)
{
if (BusinessPartnerSource.FindByName(t.BusinessPartnerSource) == null)
throw new InvalidBusinessPartnerException(t.BusinessPartnerName);
}
}
BusinessPartyValidator now has a single responsibility

RefactoredBusinessPartnerValidator
BusinessPartner
Validator
BusinessPartner
Source
Trade
DB
What's its job?
Classes must have an identifiable single responsibility.

Open Closed Principle
“..this is the heart of Object Oriented Programming...”
OCP

The Open Closed Principle
Realise that generally systems outlive their expected timelines
All software entities should be closed for change and opened for extension
Your design modules should never change
You should just extend the behaviour

Liskov Substitution Principle
There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened.
Douglas Adams (1952 - 2001)

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

Using Inheritance for OCP?
RateCalculator
Trade
Option
Fee

Trade Rate Calculation
public decimal CalulateRate(Trade t)
{
if (t is Fee)
{
return 1.0m;
}
return t.BaseAmount/t.QuotedAmount;
}
Use of convention rather than design
Fragile: sensitive to any change in Trade Fee Hierarchy

Better Trade Rate Calculation
public abstract class Trade
{
...
public abstract decimal Rate { get; }
}
public class Fee : Trade
{
...
public override decimal Rate
{
get { return 1.0m; }
}
}
Open for extension
Design forces implementation

The Liskov substitution principal
Be vary of ‘is-a’ relationship
LSP is prime enabler of OCP
Important Pointers for LSP compliance:
Hollow methods (Degenerate Functions)
Sub type = substitutable

Dependency Inversion
It may be that the old astrologers had the truth exactly reversed, when they believed that the stars controlled the destinies of men. The time may come when men control the destinies of stars. Arthur C. Clarke (1917 - ), First on the Moon, 1970

Dependency Inversion Principal
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.

BusinessParty Validator
Introduce stability with abstraction
High Level (Less Stable)
BusinessParty
Source
BusinessParty
Validator
Trade
DB
Low Level
(More Stable)

Better BusinessPartner Validator
<Interface>
IBusinessPartnerSource
BusinessPartnerValidator
BusinessPartySource
Trade
DB

Extensible BusinessParty Validator
<Interface>
IBusinessPartnerSource
BusinessPartyValidator
Trade
WSBusinessPartnerSource
DbBusinessPartySource
DB
Cloud

DI & IoC
IoC is key part of Frameworks
Interfaces, Closures & Events
Hollywood Principal (Don’t call us, We will call you)
IoC is a very general name and hence the Dependency Injection*
Suits Test Driven Development
Number of dependencies indicate stability
*http://martinfowler.com/articles/injection.htm l

Software Design Metrics

Some Key Design Metrics - Ca
Afferent Couplings - Ca
The number of other packages that depend upon classes within the package is an indicator of the package's responsibility.
BPackage
APackage
Package
Class

Some Key Design Metrics
Efferent Couplings – Ce
The number of other packages that the classes in the package depend upon is an indicator of the package's independence.
BPackage
APackage
Package
Class

Some Key Design Metrics
Instability – I = Ce / (Ce + Ca)
This metric is an indicator of the package's resilience to change.
The range for this metric is 0 to 1,
0 indicating a completely stable package
1 indicating a completely instable package.

Use Visual Studio Code Metrics
Maintainability Index
Cyclomatic Complexity
Depth of Inheritance
Class Coupling
Lines of Code
Code Coverage

Further reading

What else can I do?
ISP: Interface Segregation Principle  Avoid fat interfaces
REP: The Release Reuse Equivalency Principle  The granule of reuse is the granule of release.
CCP: The Common Closure Principle  Classes that change together are packaged together.
CRP: The Common Reuse Principle  Classes that are used together are packaged together.
SDP: The Stable Dependencies Principle  Depend in the direction of stability.

Strategic Closure
No significant program can be 100% closed
Closures cant be complete
Closures must be ‘Strategic’
Stability metrics can indicate hotpots
Designer must choose the changes against which her design should be closed

Summary
Remember your application will outlive your expectation
Follow these design principles
Be Agile!
Refactor ++
Use Code Metrics

References
Uncle Bob http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Agile Principles, Patterns and Practices in C#
Martin Fowler’s Blog:
http://martinfowler.com/bliki/

question & answer

Required Slide
Speakers,
TechEd 2010 is not producing
a DVD. Please announce that
attendees can access session
recordings at TechEd Online.
www.microsoft.com/teched
Sessions On-Demand & Community
www.microsoft.com/learning
Microsoft Certification & Training Resources
http://microsoft.com/technet
Resources for IT Professionals
http://microsoft.com/msdn
Resources for Developers
Resources

Required Slide
Complete an evaluation on CommNet and enter to win an HTC HD2!

Required Slide
© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

http://dotnetwizards.blogspot.com	230
http://hammadrajjoub.net	55
http://www.dotnetwizards.blogspot.com	8
http://dotnetwizards.blogspot.in	8
http://dotnetwizards.blogspot.co.uk	2
http://dotnetwizards.blogspot.jp	1
http://dotnetwizards.blogspot.se	1
http://dotnetwizards.blogspot.com.au	1

C:\Fakepath\Combating Software Entropy 2

by Hammad Rajjoub on Mar 02, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

8 Embeds 306

Statistics

C:\Fakepath\Combating Software Entropy 2 — Presentation Transcript