The document summarizes techniques for combating software entropy through principles of software design such as the single responsibility principle, open/closed principle, and dependency inversion principle. It provides examples of how to refactor code to follow these principles by separating concerns and abstracting dependencies. Following these principles helps make software easier to change, extend, and maintain over time.

2. ARC202 - Combating Software Entropy with Design Patterns and PrinciplesHammad RajjoubSolutions Architect @ InfusionMicrosoft MVP

3. Cogito, Ergo , SumMicrosoft MVP – Connected Systems (5+ yrs)Solutions Architect at InfusionThe coolest company in townDevelop. Design. Venture.  Join us!Speaker, Author & Community LeaderI do: Blog + Twitter + PodCastBing me http://www.bing.com/search?q=hammadrajjoub

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

5. Why is Software ComplexWriting new softwareMandated to develop new systemsGenerally from scratch But still mostly relying on existing libraries and frameworksReal-world problems are sometimes complexModifying Existing SoftwareFind that ‘bug’ and ‘fix’ itAdd a new exciting featureReview 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 codeRigidFragileCan’t be ‘extended’ Immobile

8. How to fix it?Using design principles and practicesThe Single Responsibility PrincipleThe Open Closed PrincipleLiskov Substitution PrincipleDependency Inversion PrincipleUsing Software Design MetricsAnd yes a whole lot of refactoring 

9. Single Responsibility PrincipleNone 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 PrincipalResponsibility is a ‘Reason for change’Each responsibility is an axis of changeThere should never be more than one reason for a class to changeDijkstra’s SoC: Separation of ConcernsThis helps us evaluate a class ‘s exposure to change

12. BusinessPartnerValidtor ModuleExample:

13. BusinessPartnerValidatorBusinessPartnerValidatorDBTradeWhat is wrong here: Changes if DB changes or Business Logic Changes

14. Counterparty Validator – Iter 1internal 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. RefactoredBusinessPartnerValidatorBusinessPartnerValidatorBusinessPartnerSourceTradeDBWhat'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 PrincipleRealise that generally systems outlive their expected timelinesAll software entities should be closed for change and opened for extensionYour design modules should never changeYou should just extend the behaviour

19. Liskov Substitution PrincipleThere 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?RateCalculatorTradeOptionFee

22. Trade Rate Calculationpublic decimal CalulateRate(Trade t){if (t is Fee) {return 1.0m; } return t.BaseAmount/t.QuotedAmount;}Use of convention rather than design

23. Fragile: sensitive to any change in Trade Fee HierarchyBetter 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

24. Design forces implementationThe Liskov substitution principalBe vary of ‘is-a’ relationshipLSP is prime enabler of OCPImportant Pointers for LSP compliance:Hollow methods (Degenerate Functions)Sub type = substitutable

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

26. Dependency Inversion PrincipalHigh level modules should not depend upon low level modules. Both should depend upon abstractions.

27. Abstractions should not depend upon details. Details should depend upon abstractions.BusinessParty ValidatorIntroduce stability with abstractionHigh Level (Less Stable)BusinessPartySourceBusinessPartyValidatorTradeDBLow Level(More Stable)

28. Better BusinessPartner Validator<Interface>IBusinessPartnerSourceBusinessPartnerValidatorBusinessPartySourceTradeDB

29. Extensible BusinessParty Validator<Interface>IBusinessPartnerSourceBusinessPartyValidatorTradeWSBusinessPartnerSourceDbBusinessPartySourceDBCloud

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

31. Software Design Metrics

32. Some Key Design Metrics - CaAfferent Couplings - CaThe number of other packages that depend upon classes within the package is an indicator of the package's responsibility.BPackageAPackagePackageClass

33. Some Key Design MetricsEfferent Couplings – CeThe number of other packages that the classes in the package depend upon is an indicator of the package's independence. BPackageAPackagePackageClass

34. Some Key Design MetricsInstability – 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 package1 indicating a completely instable package.

35. Use Visual Studio Code MetricsMaintainability IndexCyclomatic ComplexityDepth of InheritanceClass CouplingLines of CodeCode Coverage

36. Further reading

37. What else can I do?ISP: Interface Segregation Principle  Avoid fat interfacesREP: 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 ClosureNo significant program can be 100% closedClosures cant be completeClosures must be ‘Strategic’Stability metrics can indicate hotpotsDesigner must choose the changes against which her design should be closed

39. SummaryRemember your application will outlive your expectationFollow these design principlesBe Agile!Refactor ++Use Code Metrics

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

41. question & answer

42. Required SlideSpeakers, TechEd 2010 is not producing a DVD. Please announce that attendees can access session recordings at TechEd Online. www.microsoft.com/techedSessions On-Demand & Communitywww.microsoft.com/learningMicrosoft Certification & Training Resourceshttp://microsoft.com/technetResources for IT Professionalshttp://microsoft.com/msdnResources for DevelopersResources

43. Required SlideComplete 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.