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

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

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

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

6. What is bad design?

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

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

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

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

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

12. BusinessPartnerValidtor Module Example:

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

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

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

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

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

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

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

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

21. Using Inheritance for OCP? RateCalculator Trade Option Fee

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

28. Better BusinessPartner Validator <Interface> IBusinessPartnerSource BusinessPartnerValidator BusinessPartySource Trade DB

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

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

31. Software Design Metrics

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

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

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

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

36. Further reading

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

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

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

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

41. question & answer

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

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

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