The document discusses the principles of good software design, emphasizing the importance of testability, dependency injection, and inversion of control. It introduces the SOLID principles for designing maintainable and flexible code, along with practical demonstrations using dependency injection frameworks like Ninject and Unity. The document concludes by highlighting how these design practices can lead to more cohesive, loosely coupled code while maintaining encapsulation.

1. Design for testability as a way to good codingSimone ChiarettaArchitect, Council of the EUhttp://codeclimber.net.nzTwitter: @simonechDecember 9th, 2010

2. Who the hell am I?Simone ChiarettaMicrosoft MVP ASP.NETASP InsiderBlogger – http://codeclimber.net.nzItalianALT.NET UG FounderOpenSource developerClimberAll Around Nice GuyDisclaimer:"The viewsexpressed are purelythose of the speaker and may not in anycircumstancesberegarded as stating an official position of the Council"

3. What are we going to talk about?What is “Good Design”?Testability requirements?What is Design for Testability?What is Dependency Injection?What is Inversion of Control?How to do IoC via DI using Ninject?How to do IoC via DI using Unity?References

4. What is Good Design?

5. What is Good DesignHigh CohesionLow CouplingGood Encapsulation

6. What is Good Design

7. Solid: Single Responsibility Principle (SRP)A class should have one, and only one, reason to change.

8. Solid: SingleResponsibilityPrinciple (SRP)“If a class has more then one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.”Robert C. MartinSolid: SingleResponsibilityPrinciple (SRP)Email Sending AppEmail SenderEmail Sending AppFlat FileXML FileFile

9. sOlid: Open Closed Principle (OCP)You should be able to extend a classes behavior, without modifying it.

10. sOlid: OpenClosedPrinciple (OCP)“Modules that conform to the open-closed principle have two primary attributes.They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.They are “Closed for Modification”.The source code of such a module is inviolate. No one is allowed to make source code changes to it.”- Robert C. Martin

11. sOlid: OpenClosedPrinciple (OCP)Email SenderFileReaderServiceIFileFormat ReaderFlat FileXML File

12. soLid: Liskov Substitution Principle (LSP)Derived classes must be substitutable for their base classes.

13. soLid: LiskovSubstitutionPrinciple (LSP)“If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.” - Barbara Liskov

14. soLid: LiskovSubstitutionPrinciple (LSP)Email SenderFileReaderServiceDatabaseIFileFormat ReaderFlat FileXML FileDatabase Connection File

15. soLid: LiskovSubstitutionPrinciple (LSP)DatabaseDatabaseReaderServiceEmail SenderFlat FileIFileFormat ReaderFileReaderServiceXML File

16. solId: Interface Segregation Principle (ISP)Clientsshouldnotbeforcedtodependuponinterfacestheydon’t use

17. solId: InterfaceSegregationPrinciple (ISP)“This principle deals with the disadvantages of ‘fat’ interfaces. Classes that have ‘fat’ interfaces are classes whose interfaces are not cohesive. In other words, the interfaces of the class can be broken up into groups of member functions. Each group serves a different set of clients. Thus some clients use one group of member functions, and other clients use the other groups.” - Robert Martin

18. solId: InterfaceSegregationPrinciple (ISP)EmailSenderEmailSenderDatabase ReaderServiceFileReaderServiceSendEmail

19. ReadFile

20. ReadFromDb

21. SendEmail

22. GetMessageBody

23. GetMessageBodysoliD: Dependency Inversion Principle (DIP)Depend on abstractions, not on concretions.

24. soliD: DependencyInversionPrinciple (DIP)“What is it that makes a design rigid, fragile and immobile? It is the interdependence of the modules within that design. A design is rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules.” - Robert Martin

25. soliD: DependencyInversionPrinciple (DIP)Flat File ReaderXml File ReaderEmail SenderDatabase Reader ServiceIMessageInfoRetrieverIEmailServiceProcessingServiceIFileFormat ReaderFile Reader Service

26. Before and AfterIMessageInfoRetrieverIEmailSenderEmailProcessingServiceEmail Sending AppDatabaseDatabaseReaderServiceFlat FileIMessageInfoRetrieverXML FileIFileFormat ReaderFileReaderServiceFileIEmailServiceEmailServiceBeforeAfter

27. How to test for “good design”?You can’tActually you can Clear?

28. Testability Requirements

29. Testability ActorsSystem Under TestDepended On ComponentMock/Fake/Stub

30. Testability ConceptsTest just one featureIndipendency from environmentIndipendency from dependenciesFast

31. Design for Testability

32. Design for Testability = Good DesignGood design is difficult to measureEasily testable = Good Design

33. What is Dependency Injection

34. Bad CodeDemo:Hard-Coded Dependencies1-2

35. The problem of strong couplingRigid – Must change the Climber code to change the Tools he usesFragile – Changes to the Tools can affect the ClimbersNot Testable – Cannot replace the Tools with a stub/fake when I want to test the Climber in isolation

36. Better CodeDemo:Hard-Coded Dependencieswith Interface3

37. Still problemsWe have lower coupling but still Climber has to be changed to change tools

38. Slightly Better CodeDemo:Hard-Coded Dependencieswith Service Locator4

39. Still problemsStill Climber depends on the LocatorJust moving the problem inside another module

40. Introducing Dependency InjectionDemo:Dependency Injectionby Hand5

41. Good, isn’t it?Climber is always the same, and doesn’t know how to “get” the toolsThe Climber is given the tools he has to use

42. Dependency InjectionAre we done?NOT YET!

43. Introducing Dependency InjectionDemo:Dependency Injectionby Hand(more complex)6

44. Needs ImprovementsHost must know how to assemble dependenciesWeloose encapsulation

45. What is Inversion of Control

46. Inversion of ControlDemo:Inversion of Control7

47. What we achievedStill have DIPGot encapsulation backDependencies are handled by external component

48. How to configureXMLAttributesFluent APIall of them

49. Many IoCC…

50. Ninject

51. The KernelFactory Method on SteroidsHold the configurationReturns objectsIKernel kernel = new StandardKernel( new ClimbingModule());var climber = kernel.Get<Climber>();

52. ModulesModules hold specific configurationsConfiguration through Fluent APIBind<Climber>().ToSelf();Bind<IClimbingTools>().To<QuickDraws>();

53. Inversion of ControlDemo:Inversion of Control(complex)8

54. Different kinds of InjectionConstructor InjectionProperty InjectionMethod InjectionThrough Factory Method

55. AttributesAre used to help discriminate injection patterns[Inject]public IClimbingTools tools {get; set;}[Inject]public void GetReady(IClimbingTools tools)

56. Inversion of ControlDemo:AttributesInjection Patterns9

57. BehavioursSingleton (Default)TransientPer ThreadPer RequestBYOBind<Climber>().ToSelf().InTransientScope();Bind<Climber>().ToSelf().InSingletonScope();

58. Inversion of ControlDemo:Activation Behaviours10

59. But there is more...Constructor ParametersContextual BindingNamed BindingBind<IClimbingTools>().To<IceScrews>() .WithConstructorArgument("brand", "Black Diamond");Bind<IClimbingTools>().To<QuickDraws>() .WhenInjectedInto(typeof(SportClimber));Bind<Climber>().To<SportClimber>() .Named("Simone");climber = kernel.Get<Climber>("Simone");

60. Inversion of ControlDemo:Advanced Features11

61. Finally Some TestingNo need to use IoC any more (and you should not)MockTools tools = new MockTools();Climber climber = new Climber(tools);climber.Climb();Assert.IsTrue(tools.Placed);

62. Finally some TestingDemo:Testing12

63. P&P Unity

64. UnityMicrosoft IoC containerConfigured via codeConfigured through XMLmyContainer .RegisterType<IClimbingTools, QuickDraws>();<unity><typeAliases> <typeAlias alias="IClimbingTools” type="ClimbDemoIoCUnity.IClimbingTools, ClimbDemoIoCUnity" /> <typeAlias alias="QuickDraws” type="ClimbDemoIoCUnity.Tools.QuickDraws, ClimbDemoIoCUnity" /></typeAliases><containers> <container> <types> <type type="IClimbingTools" mapTo="IceScrews" /> </types> </container></containers></unity>

65. UnityDemo:Unity13

66. Bonus section: Func

67. FuncBy Daniel Cazzulino (of Moq fame)The fastestIoCavailableDoesn’t usereflectionAlwayswrite factory methodcontainer.Register<IClimbingTools>( c => newQuickDraws());container.Register( c => newClimber(c.Resolve<IClimbingTools>()));

68. Bonus section: FuncDemo:Func14

69. IoC inside other hosts

70. IoC in other hostsIoC shines when activation is already delegated to factoriesASP.NET MVCWCFRequires changes in the default “object factory”ControllerFactoryServiceHostFactory

71. IoC in other hostsDemo:ASP.NET MVC15

72. Conclusions

73. Call for ActionsThink about a project you worked onThink about any maintainabily/change issue you had:Most likely they would have been solved with DI/IoCThink how DI/IoC could have helped

74. Main takeawaysDI/IoC helps building service oriented applicationsDI/IoC helps managing dependenciesDI/IoC helps bulding highly cohese, loose coupled code while maintaling encapsulation

75. ReferencesUncle Bob’s Principle Of Object Oriented Development: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOodOO Design Principles:http://www.oodesign.com/design-principles.htmlComplete SOLID slides and demo (Derick Bailey):http://www.lostechies.com/media/p/5415.aspxNinject:http://ninject.org/ - v2http://github.com/enkari/ninject/ - v2.2 betap&p Unity:http://unity.codeplex.com/ - v2 (part of EntLib5)Funq:http://funq.codeplex.com/