In part 2 of this series I made a case that switching from Stateless Single-Responsibility Objects to delegates and static methods lets us write simple, pure functions and lets us remove a lot of boilerplate.
Nevertheless, there was still one bit of boilerplate I hadn’t yet removed. It dealt with encapsulating dependencies to a method in order to match a delegate signature for use in other parts of the application. Read more on Functional C# Application Composition, Part 3: MethodToDelegate…
In my previous post on the Stateless Single-Responsibility Object (SSRO) approach to C# application composition I reviewed the concept and its shortcomings.
To recap:
Read more on Functional C# Application Composition, Part 2: Delegates…
Functional code is easier to test than code with state or side effects. However, most developers spend the majority of their time in traditional, imperative languages. There’s plenty of value in those imperative languages, but these days when I use one, I also try to bring in applicable functional concepts.
In this post I will explore how a stateful, Object-Oriented approach to composition became painful to me, and in my next post I will discuss my proposed functional solution. Read more on Functional C# Application Composition, Part 1: Shortcomings of Single-Responsibility Objects…