my presentation at The First Riyadh Online Summit 2010.

2.  Microsoft MVP for Connected Systems (6+
yrs)
 Member of BusinessTechnology Platform
Advisors
 Author
 I do: Blog +Twitter + PodCast
 www.hammadrajjoub.net
 Follow me onTwitter @HammadRajjoub
 Bing me
http://www.bing.com/search?q=hammadr
ajjoub

3.  Why is Software Complex?
 What is bad design?
 How to Fix it?
 Summary
 References
 QnA

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

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

7.  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 likeVS 2010 Ultimate
And yes a whole lot of refactoring 

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

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

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

11. Example:

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

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

14. internal class BusinessPartnerValidator
{
private readonly BusinessPartnerValidator
businessPartnersource;
public BusinessPartyValidator(BusinessPartnerSource
BusinessPartySource)
{
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

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

16. Dependency Inversion

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

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

19. BusinessPartnerValidator
Trade
DB
BusinessPartySource
<Interface>
IBusinessPartnerSourc
e

20. BusinessPartyValidato
r
Trade
DB
DbBusinessPartySource
<Interface>
IBusinessPartnerSource
WSBusinessPartnerSource
Cloud

21.  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*
 SuitsTest Driven Development
 Number of dependencies indicate
stability*http://martinfowler.com/articles/injection.htm
l

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

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

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

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

27. • CodeVisualizations  DGML
• Layered Diagrams
• Good Old UML

28. -DGML
-Layered Architecture andValidations
-UML Diagrams

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

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

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

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

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