Microsoft MVP for Connected Systems (6+ yrs)

Member of Business Technology Platform Advisors

Author I do: Blog + Twitter + PodCast www.hammadrajjoub.net Follow me on Twitter @HammadRajjoub Bing me

http://www.bing.com/search?q=hammadrajjoub

Why is Software Complex?

What is bad design?

How to Fix it?

Summary

References

QnA

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

Rigid

Fragile

Immobile

Hard to change!

A single change break lots of other

code

Can’t be ‘extended’

Using design principles and practices

The Single Responsibility Principle

The Open Closed Principle

Liskov Substitution Principle

Dependency Inversion Principle

Using Software Design Metrics Using advanced tools like VS 2010 Ultimate

And yes a whole lot of refactoring

None but Buddha himself must take the responsibility of giving out occult secrets...

E. Cobham Brewer 1810–1897.Dictionary of Phrase and Fable. 1898.

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

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

Example:

BusinessPartnerValidator

TradeDB

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

internal class BusinessPartnerValidator{

public void AssertValid(Trade t){

var sql = "SELECT COUNT(*) FROM BusinessPartner WHERE name=@Name";

using (var conn = CreateOpenConnection()){

var cmd = 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.

internal class BusinessPartnerValidator{

private readonly BusinessPartnerValidatorbusinessPartnersource;

public BusinessPartyValidator(BusinessPartnerSourceBusinessPartySource)

{this.businessPartnerSource =

BusinessPartnerSource;}

public void AssertValid(Trade t){

if (BusinessPartnerSource.FindByName(t.BusinessPartnerSource) == null)

throw new InvalidBusinessPartnerException(t.BusinessPartnerName);

}}

BusinessPartyValidatornow has a single responsibility

BusinessPartnerValidator

Trade

DB

BusinessPartnerSource

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

Dependency Inversion

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

BusinessPartyValidator

TradeDB

BusinessPartySource

High Level (Less Stable)

Low Level(More Stable)

Introduce stability with abstraction

BusinessPartnerValidator

Trade

DB

BusinessPartySource

<Interface>IBusinessPartnerSourc

e

BusinessPartyValidator

Trade

DB

DbBusinessPartySource

<Interface>IBusinessPartnerSource

WSBusinessPartnerSource

Cloud

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

Afferent Couplings - CaThe number of other packages

that depend upon classes within the package is an indicator of the package's responsibility.

BPackage

APackage

PackageClass

Efferent Couplings – CeThe number of other packages

that the classes in the package depend upon is an indicator of the package's independence. BPackage

APackage

PackageClass

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.

Maintainability Index Cyclomatic Complexity Depth of Inheritance Class Coupling Lines of Code Code Coverage

• Code Visualizations DGML• Layered Diagrams• Good Old UML

-DGML-Layered Architecture and Validations-UML Diagrams

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.

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

Remember your application will outlive your expectation

Follow these design principles Be Agile! Refactor ++ Use Code Metrics

Uncle Bob http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Agile Principles, Patterns and Practices in C#

Martin Fowler’s Blog:http://martinfowler.com/bliki/

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