Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ARC202 - Combating Software Entropy with Design Patterns and Principles<br />Hammad Rajjoub<br />Solutions Architect @ Inf...
Cogito, Ergo , Sum<br />Microsoft MVP – Connected Systems (5+ yrs)<br />Solutions Architect at Infusion<br />The coolest c...
Agenda<br /> Why is Software Complex?<br /> What is bad design?<br /> How to Fix it?<br /> Summary<br /> References<br />Q...
Why is Software Complex<br />Writing new software<br />Mandated to develop new systems<br />Generally from scratch <br />B...
What is bad design?<br />
Bad design is...<br />Hard to change!<br />A single change break lots of other code<br />Rigid<br />Fragile<br />Can’t be ...
How to fix it?<br />Using design principles and practices<br />The Single Responsibility Principle<br />The Open Closed Pr...
Single Responsibility Principle<br />None but Buddha himself must take the responsibility of giving out occult secrets...<...
The Single responsibility principal<br />"A responsibility is a reason to change, a class or module should have one, and o...
The Single Responsibility Principal<br />Responsibility is a ‘Reason for change’<br />Each responsibility is an axis of ch...
BusinessPartnerValidtor Module<br />Example:<br />
BusinessPartnerValidator<br />BusinessPartner<br />Validator<br />DB<br />Trade<br />What is wrong here: Changes if DB cha...
Counterparty Validator – Iter 1<br />internal class BusinessPartnerValidator<br />{<br />public void AssertValid(Trade t)<...
BusinessPartyValidator – Iter 2<br /> internal class BusinessPartnerValidator<br />    {<br />private readonlyBusinessPart...
RefactoredBusinessPartnerValidator<br />BusinessPartner<br />Validator<br />BusinessPartner<br />Source<br />Trade<br />DB...
Open Closed Principle<br />“..this is the heart of Object Oriented Programming...”<br />OCP<br />
The Open Closed Principle<br />Realise that generally systems outlive their expected timelines<br />All software entities ...
Liskov Substitution Principle<br />There is a theory which states that if ever anybody discovers exactly what the Universe...
The Liskov substitution principal<br />“Functions that reference a base class must be able to use objects of derived class...
Using Inheritance for OCP?<br />RateCalculator<br />Trade<br />Option<br />Fee<br />
Trade Rate Calculation<br />public decimal CalulateRate(Trade t)<br />{<br />if (t is Fee)<br />    {<br />return 1.0m;<br...
Fragile: sensitive to any change in Trade Fee Hierarchy</li></li></ul><li>Better Trade Rate Calculation<br /> public abstr...
Design forces implementation</li></li></ul><li>The Liskov substitution principal<br />Be vary of ‘is-a’ relationship<br />...
Dependency Inversion<br />It may be that the old astrologers had the truth exactly reversed, when they believed that the s...
Dependency Inversion Principal<br /><ul><li>High level modules should not depend upon low level modules. Both should depen...
Abstractions should not depend upon details. Details should depend upon abstractions.</li></li></ul><li>BusinessParty Vali...
Better BusinessPartner Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartnerValidator<br />BusinessP...
Extensible BusinessParty Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartyValidator<br />Trade<br ...
DI & IoC<br />IoC is key part of Frameworks<br />Interfaces, Closures & Events<br />Hollywood Principal (Don’t call us, We...
Software Design Metrics<br />
Some Key Design Metrics - Ca<br />Afferent Couplings  - Ca<br />The number of other packages that depend upon classes with...
Some Key Design Metrics<br />Efferent Couplings – Ce<br />The number of other packages that the classes in the package dep...
Some Key Design Metrics<br />Instability – I = Ce / (Ce + Ca)<br />This metric is an indicator of the package's resilience...
Use Visual Studio Code Metrics<br />Maintainability Index<br />Cyclomatic Complexity<br />Depth of Inheritance<br />Class ...
Further reading<br />
What else can I do?<br />ISP: Interface Segregation Principle  Avoid fat interfaces<br />REP: The Release Reuse Equivalen...
Strategic Closure<br />No significant program can be 100% closed<br />Closures cant be complete<br />Closures must be ‘Str...
Summary<br />Remember your application will outlive your expectation<br />Follow these design principles<br />Be Agile!<br...
References<br />Uncle Bob http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod<br />Agile Principles, Patterns and Pra...
question & answer<br />
Required Slide<br />Speakers, <br />TechEd 2010 is not producing <br />a DVD. Please announce that <br />attendees can acc...
Required Slide<br />Complete an evaluation on CommNet and enter to win an HTC HD2!<br />
Required Slide<br />© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product...
Upcoming SlideShare
Loading in …5
×

C:\Fakepath\Combating Software Entropy 2

2,198 views

Published on

Hammad Rajjoub's presentation of Software Design and Architecture during Microsoft Tech Ed Middle East.

Published in: Technology
  • Be the first to comment

C:\Fakepath\Combating Software Entropy 2

  1. 1.
  2. 2. ARC202 - Combating Software Entropy with Design Patterns and Principles<br />Hammad Rajjoub<br />Solutions Architect @ Infusion<br />Microsoft MVP<br />
  3. 3. Cogito, Ergo , Sum<br />Microsoft MVP – Connected Systems (5+ yrs)<br />Solutions Architect at Infusion<br />The coolest company in town<br />Develop. Design. Venture.  Join us!<br />Speaker, Author & Community Leader<br />I do: Blog + Twitter + PodCast<br />Bing me http://www.bing.com/search?q=hammadrajjoub<br />
  4. 4. Agenda<br /> Why is Software Complex?<br /> What is bad design?<br /> How to Fix it?<br /> Summary<br /> References<br />QnA<br />
  5. 5. Why is Software Complex<br />Writing new software<br />Mandated to develop new systems<br />Generally from scratch <br />But still mostly relying on existing libraries and frameworks<br />Real-world problems are sometimes complex<br />Modifying Existing Software<br />Find that ‘bug’ and ‘fix’ it<br />Add a new exciting feature<br />Review and refactor to a better design<br />
  6. 6. What is bad design?<br />
  7. 7. Bad design is...<br />Hard to change!<br />A single change break lots of other code<br />Rigid<br />Fragile<br />Can’t be ‘extended’ <br />Immobile<br />
  8. 8. How to fix it?<br />Using design principles and practices<br />The Single Responsibility Principle<br />The Open Closed Principle<br />Liskov Substitution Principle<br />Dependency Inversion Principle<br />Using Software Design Metrics<br />And yes a whole lot of refactoring <br />
  9. 9. Single Responsibility Principle<br />None but Buddha himself must take the responsibility of giving out occult secrets...<br />E. Cobham Brewer 1810–1897.<br />Dictionary of Phrase and Fable. 1898.<br />SRP<br />
  10. 10. The Single responsibility principal<br />"A responsibility is a reason to change, a class or module should have one, and only one, reason to change."<br />
  11. 11. The Single Responsibility Principal<br />Responsibility is a ‘Reason for change’<br />Each responsibility is an axis of change<br />There should never be more than one reason for a class to change<br />Dijkstra’s SoC: Separation of Concerns<br />This helps us evaluate a class ‘s<br /> exposure to change<br />
  12. 12. BusinessPartnerValidtor Module<br />Example:<br />
  13. 13. BusinessPartnerValidator<br />BusinessPartner<br />Validator<br />DB<br />Trade<br />What is wrong here: Changes if DB changes or Business Logic Changes<br />
  14. 14. Counterparty Validator – Iter 1<br />internal class BusinessPartnerValidator<br />{<br />public void AssertValid(Trade t)<br /> {<br />varsql = "SELECT COUNT(*) FROM BusinessPartner WHERE name=@Name";<br />using (varconn = CreateOpenConnection())<br /> {<br />varcmd = new SqlCommand(sql, conn);<br />cmd.Parameters.Add("@Name", SqlDbType.VarChar);<br />cmd.Parameters["@name"].Value = t.BusinessPartnerName;<br />var count = (Int32) cmd.ExecuteScalar();<br />if (count != 1) throw new InvalidBusinessPartyException(t.BusinessPartyName);<br /> }<br /> }<br />...<br />Where is the business logic? <br />Hidden by database code.<br />
  15. 15. BusinessPartyValidator – Iter 2<br /> internal class BusinessPartnerValidator<br /> {<br />private readonlyBusinessPartnerValidatorbusinessPartnersource;<br />public BusinessPartyValidator(BusinessPartnerSourceBusinessPartySource)<br /> {<br />this.businessPartnerSource = BusinessPartnerSource;<br /> }<br /> public void AssertValid(Trade t)<br /> {<br />if (BusinessPartnerSource.FindByName(t.BusinessPartnerSource) == null) <br /> throw new InvalidBusinessPartnerException(t.BusinessPartnerName);<br /> }<br /> }<br />BusinessPartyValidator now has a single responsibility<br />
  16. 16. RefactoredBusinessPartnerValidator<br />BusinessPartner<br />Validator<br />BusinessPartner<br />Source<br />Trade<br />DB<br />What's its job?<br />Classes must have an identifiable single responsibility. <br />
  17. 17. Open Closed Principle<br />“..this is the heart of Object Oriented Programming...”<br />OCP<br />
  18. 18. The Open Closed Principle<br />Realise that generally systems outlive their expected timelines<br />All software entities should be closed for change and opened for extension<br />Your design modules should never change<br />You should just extend the behaviour<br />
  19. 19. Liskov Substitution Principle<br />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. <br />Douglas Adams (1952 - 2001)<br />
  20. 20. The Liskov substitution principal<br />“Functions that reference a base class must be able to use objects of derived classes without knowing it."<br />
  21. 21. Using Inheritance for OCP?<br />RateCalculator<br />Trade<br />Option<br />Fee<br />
  22. 22. Trade Rate Calculation<br />public decimal CalulateRate(Trade t)<br />{<br />if (t is Fee)<br /> {<br />return 1.0m;<br /> }<br /> return t.BaseAmount/t.QuotedAmount;<br />}<br /><ul><li>Use of convention rather than design
  23. 23. Fragile: sensitive to any change in Trade Fee Hierarchy</li></li></ul><li>Better Trade Rate Calculation<br /> public abstract class Trade<br /> {<br />...<br /> public abstract decimal Rate { get; }<br /> }<br /> public class Fee : Trade<br /> {<br />...<br />public override decimal Rate<br /> {<br /> get { return 1.0m; }<br /> }<br /> }<br /><ul><li> Open for extension
  24. 24. Design forces implementation</li></li></ul><li>The Liskov substitution principal<br />Be vary of ‘is-a’ relationship<br />LSP is prime enabler of OCP<br />Important Pointers for LSP compliance:<br />Hollow methods (Degenerate Functions)<br />Sub type = substitutable<br />
  25. 25. Dependency Inversion<br />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 <br />
  26. 26. Dependency Inversion Principal<br /><ul><li>High level modules should not depend upon low level modules. Both should depend upon abstractions.
  27. 27. Abstractions should not depend upon details. Details should depend upon abstractions.</li></li></ul><li>BusinessParty Validator<br />Introduce stability with abstraction<br />High Level (Less Stable)<br />BusinessParty<br />Source<br />BusinessParty<br />Validator<br />Trade<br />DB<br />Low Level<br />(More Stable)<br />
  28. 28. Better BusinessPartner Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartnerValidator<br />BusinessPartySource<br />Trade<br />DB<br />
  29. 29. Extensible BusinessParty Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartyValidator<br />Trade<br />WSBusinessPartnerSource<br />DbBusinessPartySource<br />DB<br />Cloud<br />
  30. 30. DI & IoC<br />IoC is key part of Frameworks<br />Interfaces, Closures & Events<br />Hollywood Principal (Don’t call us, We will call you)<br />IoC is a very general name and hence the Dependency Injection*<br />Suits Test Driven Development<br />Number of dependencies indicate stability<br />*http://martinfowler.com/articles/injection.htm l<br />
  31. 31. Software Design Metrics<br />
  32. 32. Some Key Design Metrics - Ca<br />Afferent Couplings - Ca<br />The number of other packages that depend upon classes within the package is an indicator of the package's responsibility.<br />BPackage<br />APackage<br />Package<br />Class<br />
  33. 33. Some Key Design Metrics<br />Efferent Couplings – Ce<br />The number of other packages that the classes in the package depend upon is an indicator of the package's independence. <br />BPackage<br />APackage<br />Package<br />Class<br />
  34. 34. Some Key Design Metrics<br />Instability – I = Ce / (Ce + Ca)<br />This metric is an indicator of the package's resilience to change. <br />The range for this metric is 0 to 1, <br />0 indicating a completely stable package<br />1 indicating a completely instable package. <br />
  35. 35. Use Visual Studio Code Metrics<br />Maintainability Index<br />Cyclomatic Complexity<br />Depth of Inheritance<br />Class Coupling<br />Lines of Code<br />Code Coverage<br />
  36. 36. Further reading<br />
  37. 37. What else can I do?<br />ISP: Interface Segregation Principle  Avoid fat interfaces<br />REP: The Release Reuse Equivalency Principle  The granule of reuse is the granule of release. <br />CCP: The Common Closure Principle  Classes that change together are packaged together.<br />CRP: The Common Reuse Principle  Classes that are used together are packaged together.<br />SDP: The Stable Dependencies Principle  Depend in the direction of stability. <br />
  38. 38. Strategic Closure<br />No significant program can be 100% closed<br />Closures cant be complete<br />Closures must be ‘Strategic’<br />Stability metrics can indicate hotpots<br />Designer must choose the changes against which her design should be closed<br />
  39. 39. Summary<br />Remember your application will outlive your expectation<br />Follow these design principles<br />Be Agile!<br />Refactor ++<br />Use Code Metrics<br />
  40. 40. References<br />Uncle Bob http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod<br />Agile Principles, Patterns and Practices in C#<br />Martin Fowler’s Blog:<br />http://martinfowler.com/bliki/<br />
  41. 41. question & answer<br />
  42. 42. Required Slide<br />Speakers, <br />TechEd 2010 is not producing <br />a DVD. Please announce that <br />attendees can access session <br />recordings at TechEd Online. <br />www.microsoft.com/teched<br />Sessions On-Demand & Community<br />www.microsoft.com/learning<br />Microsoft Certification & Training Resources<br />http://microsoft.com/technet<br />Resources for IT Professionals<br />http://microsoft.com/msdn<br />Resources for Developers<br />Resources<br />
  43. 43. Required Slide<br />Complete an evaluation on CommNet and enter to win an HTC HD2!<br />
  44. 44. Required Slide<br />© 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.<br />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.<br />

×