building solid software with dependency injection n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Building SOLID Software with Dependency Injection PowerPoint Presentation
Download Presentation
Building SOLID Software with Dependency Injection

Loading in 2 Seconds...

play fullscreen
1 / 134

Building SOLID Software with Dependency Injection - PowerPoint PPT Presentation


  • 72 Views
  • Uploaded on

Building SOLID Software with Dependency Injection. Jeremy Rosenberg. Me. Who cares about software design?. What are our goals?. Deliver yesterday Communicate telepathically No bugs. What are our goals?. Deliver yesterday Communicate telepathically No bugs. What are our goals?.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Building SOLID Software with Dependency Injection' - coby


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
what are our goals
What are our goals?
  • Deliver yesterday
  • Communicate telepathically
  • No bugs
what are our goals1
What are our goals?
  • Deliver yesterday
  • Communicate telepathically
  • No bugs
what are our goals2
What are our goals?
  • Deliver quickly
  • Communicate quickly
  • Few bugs
  • Fix bugs quickly
  • Deliver yesterday
  • Communicate telepathically
  • No bugs
what are our goals3
What are our goals?
  • Deliver quickly
  • Communicate quickly
  • Few bugs
  • Fix bugs quickly
  • Deliver yesterday
  • Communicate telepathically
  • No bugs

aka

Efficiently deal with Change

a bad design causes these
A bad design causes these
  • Deliver slowly or unpredictably
  • Slow ramp-up for new team members
  • Slow sharing between veteran team members
a bad design causes these1
A bad design causes these
  • Frequent bugs
  • Simple bugs need complex changes
  • Lots of regressions
  • Lots of regression testing
what it is
What it is
  • Catchy acronym
  • Principles for dealing with change
what it is1
What it is
  • Catchy acronym
  • Principles for dealing with change
what it is2
What it is
  • Catchy acronym
  • Principles for dealing with change

SDOLI

what it s not
What it’s not
  • Framework
  • Library
  • Pattern
  • Goal
what is dependency injection
What is Dependency Injection?
  • Pattern
  • Jives well with SOLID
what kinds of code
What kinds of code?
  • Object-oriented
  • Statically typed*

(code examples are in C#)

what does this method do1
What does this method do?
    • Coordinates a book checkout process for a member
  • Checkout
  • Storage
what does this method do2
What does this method do?
    • Coordinates a book checkout process for a member
  • Checkout
  • Storage

Is that all?

what does this class do1
What does this class do?
  • Configuration
  • DB Access
so what does this method really do1
So what does this method really do?
  • Checkout
  • Storage
    • Configuration
    • DB access

Implicit!

s doli s ingle responsibility principle
SDOLI: Single Responsibility Principle
  • “Do one thing and do it well”
  • Applies to a method, class, service, system, …
s d oli d ependency inversion principle
SDOLI: Dependency Inversion Principle
  • Depend on contracts, not implementations
  • Goal: Decouple the single responsibility from implementations of its dependencies
s d oli d ependency inversion principle1
SDOLI: Dependency Inversion Principle
  • Depend on a contract at design-time
    • e.g. IBookRepository or BookRepositoryBase
  • Receive an implementation at runtime
    • e.g. SqlBookRepository
dependency i njection
Dependency Injection
  • A class declares its dependencies through its own contract
  • Providing dependencies is someone else’s job
dependency i njection1
Dependency Injection
  • Constructor injection
  • Property injection
  • Method injection
our test case
Our test case
  • No configuration
  • No database
  • Only coordination
all this just for test cases
All this “just” for test cases?
  • What else have we gained?
    • “Tightly bound, loosely coupled”
      • Focused responsibility => readability
      • Dependent on behavior, not implementation
    • Dependencies are explicit
      • Limits unexpected side effects
      • Straightforward (re)usage
    • Composability
composition root
Composition Root
  • Constructs the object graph
  • Lives near the entry point
sd o li o pen closed principle
SDOLI: Open/Closed Principle
  • Open for extensibility, closed for modification
  • Add behavior without changing existing code
decorator
Decorator
  • Inject behavior into an application
  • Man-in-the-middle
composite
Composite
  • Implements a contract
  • Delegates to others with the same contract
sdo l i l iskov substitution principle
SDOLI: Liskov Substitution Principle
  • Functions that use pointers to base types must be able to use objects of derived types without knowing it.
  • “Leaky abstraction principle”

-Me

is a square a rectangle1
Is a Square a Rectangle?

SetWidth / SetHeight?

plug the leak part 11
Plug the leak – Part 1

- Nine fingers left!

what to do
What to do
  • Some ideas
    • Kill the abstraction
    • Adapt each calculator to something that supports input validation
what to do1
What to do?
  • Some ideas
    • IReadOnlyDocRepo and IReadWriteDocRepo
    • IReadDocs and IWriteDocs
    • SupportsXYZ methods
sdol i i nterface segregation principle
SDOLI: Interface Segregation Principle
  • Thin interfaces are better than fat ones
  • Client-focused
adapter
Adapter

This:

or this:

solid principles
SOLID Principles
  • Single Responsibility
  • Open/Closed
  • Liskov Substitution
  • Interface Segregation
  • Dependency Inversion
di container
DI Container
  • Auto-wiring of dependencies
  • Lifetime management
ninject1
Ninject

Register

ninject2
Ninject

Resolve

Register

ninject3
Ninject

Resolve

Release

Register

other containers
Other containers
  • Castle Windsor
  • Autofac
  • StructureMap
  • Unity
don t use service locator1
Don’t use Service Locator
  • Hides dependencies
  • Consumers must use the same container
  • Testing becomes un-fun
don t use service locator2
Don’t use Service Locator
  • Composition root should be the only place referencing the DI Container.
  • General rule: if it’s not just initializing the object graph, it’s not the composition root.
don t just new it1
Don’t just new it
  • Useless interface definition
  • Same tight coupling
  • No way to swap, decorate, or otherwise compose implementations
don t be double minded1
Don’t be double minded
  • Two paths…
  • Dependencies are still not always apparent
  • Auto-wiring can be difficult
building solid software1
Building SOLID software
  • SOLID encourages good designs
  • Dependency injection is a tool to bring closer alignment with SOLID
resources
Resources
  • The Principles of OODhttp://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
  • Dependency Injection in .NETby Mark Seemann
  • ploeh blog – DependencyInjectionhttp://blog.ploeh.dk/CategoryView,category,DependencyInjection.aspx
  • SOLID (object-oriented design)http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)