SlideShare a Scribd company logo

Lego For Engineers - Dependency Injection for LIDNUG (2011-06-03)

•
•
Theo Jungeblut
Theo Jungeblut

The document discusses how to build reusable and maintainable applications in C# using Lego principles. It promotes principles like separation of concerns, single responsibility, and dependency injection to create loosely coupled and modular code. It provides examples of how to implement these principles using techniques like interfaces, dependency injection containers, and the strategy of "keeping it simple stupid".

Related slideshows

Clean Code - Design Patterns and Best Practices at Silicon Valley Code Camp
Clean Code - Design Patterns and Best Practices at Silicon Valley Code CampClean Code - Design Patterns and Best Practices at Silicon Valley Code Camp
Clean Code - Design Patterns and Best Practices at Silicon Valley Code Camp
 
Clean Code 2
Clean Code 2Clean Code 2
Clean Code 2
 
SOLID design principles applied in Java
SOLID design principles applied in JavaSOLID design principles applied in Java
SOLID design principles applied in Java
 
1 of 39
Download to read offline
Lego for Engineers How to build Reusable and Maintainable Applications in C# Lego (trademarked in capitals as LEGO) Theo Jungeblut 06/03/2011
Theo Jungeblut • Senior Software Developer at Omnicell Inc. in Mountain View • Has been designing and implementing .NET based applications , components and frameworks for 8 years • Previously worked in factory automation with focus on component based software and framework development for 3 ½ years theo@csharp-lighthouse.com • Degree in Software Engineering and Network Communications www.csharp-lightouse.com
Overview • Why Lego for Software Engineers? • Design Patterns, Principles and Best Practices • Dependency Injection Container & more • The “Must Read”-Book • Summary • Q&A • References 3
Why Lego for Software Engineers? Lego (trademarked in capitals as LEGO) is a line of construction toys manufactured by the Lego Group http://upload.wikimedia.org/wikipedia/commons/7/75/Lego_technic_gears.jpg 4
Design Patterns, Principals & Best Practices • Keep it simple stupid (KISS) • Separation of Concerns (SoC) • Single Responsibility Principle (SRP) • Component Oriented Programming (CoP) • Interface / Contract • Don’t Repeat Yourself (DRY) • Dependency Inversion Principal (DIP) • Inversion of Control (IoC) • Constructor Injection • Setter Injection • Interface Injection • Service Locator 5
Keep it simple, stupid (KISS)
KISS-Principle – “Keep It Simple Stupid” by Kelly Johnson http://blogs.smarter.com/blogs/Lego%20Brick.jpg 7
The Power of Simplicity Graphic by Nathan Sawaya courtesy of brickartist.com Graphic by Nathan Sawaya courtesy of brickartist.com 8 http://www.geekalerts.com/lego-iphone/
Graphic by Nathan Sawaya courtesy of brickartist.com
Separation of Concerns (SoC) Single Responsibility Principle (SRP)
The Product http://www.technicopedia.com/8865.html
Component / Service http://www.technicopedia.com/8865.html
Class, Struct, Enum etc. http://technicbricks.blogspot.com/2009/06/tbs-techpoll-12-results-2009-1st.html
Separation of Concerns (SoC) probably by Edsger W. Dijkstra in 1974 • “In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. •A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. “ http://en.wikipedia.org/wiki/Separati on_of_Concerns 14
Single Responsibility Principle (SRP) by Robert C Martin “Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.” http://en.wikipedia.org/wiki/Single_responsibility_principle public class Logger : ILogger { public Logger(ILoggingSink loggingSink) {} public void Log(string message) {} } http://www.ericalbrecht.com 15
Component-Oriented Programming (CoP)
Different Ways of doing Something Similar http://www.ericalbrecht.com http://www.julianaheng.com/transformers-rotf-bumblebee- and-sam-action-figures/ http://www.ericalbrecht.com 17
Why Reusable Components Rock http://www.ericalbrecht.com/technic/8020/8020all.jpg 18
Interfaces / Contracts • Decouple Usage and Implementation through introduction of a contract • Allows to replace implementation without changing the consumer public interface ILogger public class Logger : ILogger { { void Log(string message); public Logger(ILoggingSink loggingSink) } {} public void Log(string message) {} } 19
Don’t repeat yourself (DRY)
Don’t repeat yourself (DRY) by Andy Hunt and Dave Thomas in their book “The Pragmatic Programmer” // Code Copy and Paste Method // DRY Method public Class Person public Class Person { { public string FirstName { get; set;} public string FirstName { get; set;} public string LastName { get; set;} public string LastName { get; set;} public Person(Person person) public Person(Person person) { { this.FirstName = string.IsNullOrEmpty(person.FirstName) this.FirstName = person.FirstName.CloneSecured(); ? string.Empty : (string) person.FirstName.Clone(); this.LastName = person.LastName.CloneSecured(); } this.LastName = string.IsNullOrEmpty(person.LastName) ? string.Empty : (string) person.LastName.Clone(); public object Clone() } { return new Person(this); public object Clone() } { } return new Person(this); } } public static class StringExtension { public static string CloneSecured(this string original) { return string.IsNullOrEmpty(original) ? string.Empty : (string)original.Clone(); } } 21
Dependency Inversion Principle (DIP)
Dependency Inversion Principle (DIP) by Robert C. Martin • “High-level modules should not depend on low-level modules. Both should depend on abstractions. • Abstractions should not depend upon details. Details should depend upon abstractions.” http://en.wikipedia.org/wiki/Dependency_inversion_principle 23
S Single Responsibility Principle O Open/Closed Principle L Liskov Substitution Principle I Interface Segregation Principle D Dependency Inversion Principle Robert C Martin: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Inversion of Control (IoC)
Inversion of Control (IoC) by Martin Fowler 1994 Logger logger = new Logger(); 26
Inversion of Control (IoC) by Martin Fowler 1994 Logger logger = new Logger(); 27
The “Must Read”-Book by Mark Seemann Dependency Injection is a set of software design principles and patterns that enable us to develop loosely coupled code. 28 http://www.manning.com/seemann/
Inversion of Control – Constructor Injection http://www.martinfowler.com/articles/injection.html public class ContactManager : IContactManager { public ContactManager(ILogger logger, IContactPersistence contactPersistence) { this.logger = logger; if (logger == null) { throw new ArgumentNullException("logger"); } … } } 29
Inversion of Control – Setter (Property) Injection http://www.martinfowler.com/articles/injection.html // UNITY Example public class ContactManager : IContactManager { [Dependency] public IContactPersistence ContactPersistence { get { return this.contactPersistence; } set { this.contactPersistence = value; } } } 30
Inversion of Control (IoC) – Interface Injection http://www.martinfowler.com/articles/injection.html In this methodology we implement an interface from the IOC framework. IOC framework will use the interface method to inject the object in the main class. You can see in figure ‘Interface based DI’ we have implemented an interface ‘IAddressDI’ which has a ‘setAddress’ method which sets the address object. This interface is then implemented in the customer class. External client / containers can then use the ‘setAddress’ method to inject the address object in the customer object. http://www.codeproject.com/KB/aspnet/IOCDI/InterfacebasedDI.JPG http://www.codeproject.com/KB/aspnet/IOCDI.aspx 31
Inversion of Control – Service Locator http://www.martinfowler.com/articles/injection.html // UNITY Example internal static class Program { private static UnityContainer unityContainer; private static SingleContactManagerForm singleContactManagerForm; private static void InitializeMainForm() { singleContactManagerForm = unityContainer.Resolve<SingleContactManagerForm>(); } } 32
Inversion of Control – Service Locator http://www.martinfowler.com/articles/injection.html // UNITY Example internal static class Program { private static UnityContainer unityContainer; private static SingleContactManagerForm singleContactManagerForm; private static void InitializeMainForm() { singleContactManagerForm = unityContainer.Resolve<SingleContactManagerForm>(); } } 33
Inversion of Control Service Locator vs Dependency Injection • Service Locator allows to request explicitly the needed instance/type/service • Every user of a service has a dependency to the Service Locator • Potential issue if the component need to be provided to 3rd parties. • Favorable for closed platforms as the Service Locator allow more control • Testing is easier with Dependency Injection than a Service Locator if Service provided is not easily substituted • In general Service Locator is only the less compelling choice if the code is mainly used out of the control of the writer 34 http://www.martinfowler.com/articles/injection.html#ServiceLocatorVsDependencyInjection
Dependency Injection Container & more • Typically support all types of Inversion of Control mechanisms • Constructor Injection • Property (Setter) Injection • Interface Injection • Service Locator •.NET based DI-Container • Unity • Castle Windsor • StructureMap Related Technology: • Spring.NET • Managed Extensibility Framework (MEF) • Autofac • Windows Communication Foundation (WCF) • Puzzle.Nfactory • Ninject • PicoContainer.NET • and more 35
The “Must Read”-Book by Mark Seemann 36 http://www.manning.com/seemann/
Summary Improving Reusability and Maintainability through: • Simplification and Specialization (KISS, SoC, SRP) •Decoupling (Interfaces, CoP, DIP or SOA) • Avoiding Code Blow (DRY, YAGNI) • Testability (all of them!) Lego (trademarked in capitals as LEGO) 37
Q&A Feedback & Comments: theo@csharp-lighthouse.com www.csharp-lighthouse.com Graphic by Nathan Sawaya courtesy of brickartist.com
References Part http://www.manning.com/seemann/ http://en.wikipedia.org/wiki/Keep_it_simple_stupid http://picocontainer.org/patterns.html http://en.wikipedia.org/wiki/Separation_of_concerns http://en.wikipedia.org/wiki/Don't_repeat_yourself http://en.wikipedia.org/wiki/You_ain't_gonna_need_it http://en.wikipedia.org/wiki/Component-oriented_programming http://en.wikipedia.org/wiki/Service-oriented_architecture http://www.martinfowler.com/articles/injection.html http://www.codeproject.com/KB/aspnet/IOCDI.aspx http://msdn.microsoft.com/en-us/magazine/cc163739.aspx http://msdn.microsoft.com/en-us/library/ff650320.aspx http://msdn.microsoft.com/en-us/library/aa973811.aspx http://msdn.microsoft.com/en-us/library/ff647976.aspx http://msdn.microsoft.com/en-us/library/cc707845.aspx http://msdn.microsoft.com/en-us/library/bb833022.aspx http://dotnetslackers.com/articles/net/A-First-Look-at-Unity-2-0.aspx http://unity.codeplex.com/ http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11 39

More Related Content

Lego For Engineers - Dependency Injection for LIDNUG (2011-06-03)

  • 1. Lego for Engineers How to build Reusable and Maintainable Applications in C# Lego (trademarked in capitals as LEGO) Theo Jungeblut 06/03/2011
  • 2. Theo Jungeblut • Senior Software Developer at Omnicell Inc. in Mountain View • Has been designing and implementing .NET based applications , components and frameworks for 8 years • Previously worked in factory automation with focus on component based software and framework development for 3 ½ years theo@csharp-lighthouse.com • Degree in Software Engineering and Network Communications www.csharp-lightouse.com
  • 3. Overview • Why Lego for Software Engineers? • Design Patterns, Principles and Best Practices • Dependency Injection Container & more • The “Must Read”-Book • Summary • Q&A • References 3
  • 4. Why Lego for Software Engineers? Lego (trademarked in capitals as LEGO) is a line of construction toys manufactured by the Lego Group http://upload.wikimedia.org/wikipedia/commons/7/75/Lego_technic_gears.jpg 4
  • 5. Design Patterns, Principals & Best Practices • Keep it simple stupid (KISS) • Separation of Concerns (SoC) • Single Responsibility Principle (SRP) • Component Oriented Programming (CoP) • Interface / Contract • Don’t Repeat Yourself (DRY) • Dependency Inversion Principal (DIP) • Inversion of Control (IoC) • Constructor Injection • Setter Injection • Interface Injection • Service Locator 5
  • 6. Keep it simple, stupid (KISS)
  • 7. KISS-Principle – “Keep It Simple Stupid” by Kelly Johnson http://blogs.smarter.com/blogs/Lego%20Brick.jpg 7
  • 8. The Power of Simplicity Graphic by Nathan Sawaya courtesy of brickartist.com Graphic by Nathan Sawaya courtesy of brickartist.com 8 http://www.geekalerts.com/lego-iphone/
  • 9. Graphic by Nathan Sawaya courtesy of brickartist.com
  • 10. Separation of Concerns (SoC) Single Responsibility Principle (SRP)
  • 12. Component / Service http://www.technicopedia.com/8865.html
  • 13. Class, Struct, Enum etc. http://technicbricks.blogspot.com/2009/06/tbs-techpoll-12-results-2009-1st.html
  • 14. Separation of Concerns (SoC) probably by Edsger W. Dijkstra in 1974 • “In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. •A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. “ http://en.wikipedia.org/wiki/Separati on_of_Concerns 14
  • 15. Single Responsibility Principle (SRP) by Robert C Martin “Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.” http://en.wikipedia.org/wiki/Single_responsibility_principle public class Logger : ILogger { public Logger(ILoggingSink loggingSink) {} public void Log(string message) {} } http://www.ericalbrecht.com 15
  • 16. Component-Oriented Programming (CoP)
  • 17. Different Ways of doing Something Similar http://www.ericalbrecht.com http://www.julianaheng.com/transformers-rotf-bumblebee- and-sam-action-figures/ http://www.ericalbrecht.com 17
  • 18. Why Reusable Components Rock http://www.ericalbrecht.com/technic/8020/8020all.jpg 18
  • 19. Interfaces / Contracts • Decouple Usage and Implementation through introduction of a contract • Allows to replace implementation without changing the consumer public interface ILogger public class Logger : ILogger { { void Log(string message); public Logger(ILoggingSink loggingSink) } {} public void Log(string message) {} } 19
  • 21. Don’t repeat yourself (DRY) by Andy Hunt and Dave Thomas in their book “The Pragmatic Programmer” // Code Copy and Paste Method // DRY Method public Class Person public Class Person { { public string FirstName { get; set;} public string FirstName { get; set;} public string LastName { get; set;} public string LastName { get; set;} public Person(Person person) public Person(Person person) { { this.FirstName = string.IsNullOrEmpty(person.FirstName) this.FirstName = person.FirstName.CloneSecured(); ? string.Empty : (string) person.FirstName.Clone(); this.LastName = person.LastName.CloneSecured(); } this.LastName = string.IsNullOrEmpty(person.LastName) ? string.Empty : (string) person.LastName.Clone(); public object Clone() } { return new Person(this); public object Clone() } { } return new Person(this); } } public static class StringExtension { public static string CloneSecured(this string original) { return string.IsNullOrEmpty(original) ? string.Empty : (string)original.Clone(); } } 21
  • 23. Dependency Inversion Principle (DIP) by Robert C. Martin • “High-level modules should not depend on low-level modules. Both should depend on abstractions. • Abstractions should not depend upon details. Details should depend upon abstractions.” http://en.wikipedia.org/wiki/Dependency_inversion_principle 23
  • 24. S Single Responsibility Principle O Open/Closed Principle L Liskov Substitution Principle I Interface Segregation Principle D Dependency Inversion Principle Robert C Martin: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
  • 26. Inversion of Control (IoC) by Martin Fowler 1994 Logger logger = new Logger(); 26
  • 27. Inversion of Control (IoC) by Martin Fowler 1994 Logger logger = new Logger(); 27
  • 28. The “Must Read”-Book by Mark Seemann Dependency Injection is a set of software design principles and patterns that enable us to develop loosely coupled code. 28 http://www.manning.com/seemann/
  • 29. Inversion of Control – Constructor Injection http://www.martinfowler.com/articles/injection.html public class ContactManager : IContactManager { public ContactManager(ILogger logger, IContactPersistence contactPersistence) { this.logger = logger; if (logger == null) { throw new ArgumentNullException("logger"); } … } } 29
  • 30. Inversion of Control – Setter (Property) Injection http://www.martinfowler.com/articles/injection.html // UNITY Example public class ContactManager : IContactManager { [Dependency] public IContactPersistence ContactPersistence { get { return this.contactPersistence; } set { this.contactPersistence = value; } } } 30
  • 31. Inversion of Control (IoC) – Interface Injection http://www.martinfowler.com/articles/injection.html In this methodology we implement an interface from the IOC framework. IOC framework will use the interface method to inject the object in the main class. You can see in figure ‘Interface based DI’ we have implemented an interface ‘IAddressDI’ which has a ‘setAddress’ method which sets the address object. This interface is then implemented in the customer class. External client / containers can then use the ‘setAddress’ method to inject the address object in the customer object. http://www.codeproject.com/KB/aspnet/IOCDI/InterfacebasedDI.JPG http://www.codeproject.com/KB/aspnet/IOCDI.aspx 31
  • 32. Inversion of Control – Service Locator http://www.martinfowler.com/articles/injection.html // UNITY Example internal static class Program { private static UnityContainer unityContainer; private static SingleContactManagerForm singleContactManagerForm; private static void InitializeMainForm() { singleContactManagerForm = unityContainer.Resolve<SingleContactManagerForm>(); } } 32
  • 33. Inversion of Control – Service Locator http://www.martinfowler.com/articles/injection.html // UNITY Example internal static class Program { private static UnityContainer unityContainer; private static SingleContactManagerForm singleContactManagerForm; private static void InitializeMainForm() { singleContactManagerForm = unityContainer.Resolve<SingleContactManagerForm>(); } } 33
  • 34. Inversion of Control Service Locator vs Dependency Injection • Service Locator allows to request explicitly the needed instance/type/service • Every user of a service has a dependency to the Service Locator • Potential issue if the component need to be provided to 3rd parties. • Favorable for closed platforms as the Service Locator allow more control • Testing is easier with Dependency Injection than a Service Locator if Service provided is not easily substituted • In general Service Locator is only the less compelling choice if the code is mainly used out of the control of the writer 34 http://www.martinfowler.com/articles/injection.html#ServiceLocatorVsDependencyInjection
  • 35. Dependency Injection Container & more • Typically support all types of Inversion of Control mechanisms • Constructor Injection • Property (Setter) Injection • Interface Injection • Service Locator •.NET based DI-Container • Unity • Castle Windsor • StructureMap Related Technology: • Spring.NET • Managed Extensibility Framework (MEF) • Autofac • Windows Communication Foundation (WCF) • Puzzle.Nfactory • Ninject • PicoContainer.NET • and more 35
  • 36. The “Must Read”-Book by Mark Seemann 36 http://www.manning.com/seemann/
  • 37. Summary Improving Reusability and Maintainability through: • Simplification and Specialization (KISS, SoC, SRP) •Decoupling (Interfaces, CoP, DIP or SOA) • Avoiding Code Blow (DRY, YAGNI) • Testability (all of them!) Lego (trademarked in capitals as LEGO) 37
  • 38. Q&A Feedback & Comments: theo@csharp-lighthouse.com www.csharp-lighthouse.com Graphic by Nathan Sawaya courtesy of brickartist.com
  • 39. References Part http://www.manning.com/seemann/ http://en.wikipedia.org/wiki/Keep_it_simple_stupid http://picocontainer.org/patterns.html http://en.wikipedia.org/wiki/Separation_of_concerns http://en.wikipedia.org/wiki/Don't_repeat_yourself http://en.wikipedia.org/wiki/You_ain't_gonna_need_it http://en.wikipedia.org/wiki/Component-oriented_programming http://en.wikipedia.org/wiki/Service-oriented_architecture http://www.martinfowler.com/articles/injection.html http://www.codeproject.com/KB/aspnet/IOCDI.aspx http://msdn.microsoft.com/en-us/magazine/cc163739.aspx http://msdn.microsoft.com/en-us/library/ff650320.aspx http://msdn.microsoft.com/en-us/library/aa973811.aspx http://msdn.microsoft.com/en-us/library/ff647976.aspx http://msdn.microsoft.com/en-us/library/cc707845.aspx http://msdn.microsoft.com/en-us/library/bb833022.aspx http://dotnetslackers.com/articles/net/A-First-Look-at-Unity-2-0.aspx http://unity.codeplex.com/ http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11 39