In object-oriented design, dependency injection is a well-known design pattern, although it's a complicated solution to the problem of decoupling. Functional programming offers a simpler way.
This talk examines dependency injection in object-oriented design, and explains how it's not required (nor desired) in functional programming. You'll also learn how a proper functional design eliminates the need for mocks and stubs in unit testing, enabling you to entirely reject the notion of dependencies.
You don't need to know Haskell or F# to attend this session; relevant syntax will be explained just-in-time. Object-oriented examples will be in C#.
Inside Unity Technologies, we built one of the most challenging automation setups in the world. We make software that runs on 20+ platforms with millions of users and billions of deployments. Our software engineers have to keep a high pace of feature development while maintaining quality. We have more than 100k tests that we run often on all our development branches producing 2M test runs a day, 60M monthly and hundreds of millions of runs yearly.
In this talk, I will explain how company culture influenced the evolution of our automation solutions. From poorly connected pieces to a solid, unified, data-driven solution running on tens of platforms and used by hundreds of our employees every day. I’ll go through the challenges we met, important decisions we made, what went wrong, what went right, and what we are still struggling with.
DDD is often invoked to justify perfectionism, or sometimes it sets up in people's minds an intimidating, impossible standard. This leads to endless analysis and polishing or indecisive thrashing. Although DDD does value polish and refinement in certain aspects of the software, the thrust of it is experimental and messy -- and always pragmatic.
For example, bounded contexts are an explicit acknowledgement of the need to confine our intensive modelling within a modest scope. And within that modest scope, we iterate toward refinement, sometimes having insights along the way that lead to much deeper, more elegant models ... but only sometimes, and unpredictably. Good designs always have flaws. And losing a pragmatic, balanced view of all this makes projects slow! Paradoxically, moving slowly means less exploration, less iteration and therefore worse design.
This has happened to most serious designers. It has happened to me. This balance doesn't usually happen without conscious attention, and it helps to have some concrete techniques for making well-designed, imperfect software. We can also shift our mindset to produce better designs by avoiding the pitfalls of idealism.
