From dependency injection to dependency rejection
summary
Argues that partial application in F# is equivalent to constructor injection (it compiles to a class with three fields and a constructor) but that pattern is not pure functional because it makes the whole dependency graph impure; demonstrates with a restaurant-reservation API refactor from OO MatreD + repository into F# functions and a Haskell port. Replaces indirect input/output by returning a decision (reservation option) and composing impure I/O at the edges — an impure–pure–impure sandwich — using partial application = constructor injection at IL level and separate decision (pure) from effect (impure).
AI-written summary · about
chapters (8)
- 0:00Introduction and setup
- 3:44Dependency injection recap
- 14:33Partial application in F#
- 28:09What is a pure function?
- 37:59Why DI isn't functional
- 40:02Refactoring to pure functions
- 50:32Impure pure impure sandwich
- 53:43Summary and conclusion
related talks
54mDependency Injection revisited
49mReaders vs Constructors: Dependency Injection showdown
41mAchieving Loose Coupling with Pure Dependency Injection
17mAchieving Loose Coupling with Pure Dependency
36mInviting everyone to the party
32mLet's Build a Dependency Injection Framework
37mDomain modelling in object-oriented and functional programming, based on C# and F#
01h 01mThe power of composition
