I commented on my appreciation of this post when I first came across it but I just came back to add a thought I had:
I often see people still writing these services and repositories i.e. NotificationService as a class with a tonne of methods on it. You don't need classes to do this sort of thing. There's no reason why you can't just have individual functions as mini services. If you're using standalone functions instead of classes with dozens of methods, you really cut down on implementation creep and having to mock random unrelated dependencies when you're just trying to test a single method.
I think this whole services as classes thing is just a "well we did it in OOP" thing. Start thinking in functions!
Maybe we stick to this pattern because constructor injection is the most common way to implement DI but it's not the only way - and in a predominantly functional application, it's probably not even the best/easiest way.
In this post, I tried to bind “clean architecture principles” and “functional core in imperative shell” with pure transformations because I think it takes the best from different paradigms.
I use objects for services here just because it’s easier for me to think of a service as a “package” with a couple of functions inside, and easier to check if the service implements the interface. (I try not to use classes if there is no need to keep some state in the entity.) So, basically, it is just a function, but in a box 😃
I also think that DI via constructors is a convenient way to compose objects, although for composing functions there are other technics like boxes and mapping :–)
In general, I try not to be an advocate for a single particular programming paradigm. For example, immutability, pure functions and functional composition are ideal for describing data transformations. But for working with state I prefer objects instead of monadic state changes from pure FP 😅
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I commented on my appreciation of this post when I first came across it but I just came back to add a thought I had:
I often see people still writing these services and repositories i.e.
NotificationServiceas a class with a tonne of methods on it. You don't need classes to do this sort of thing. There's no reason why you can't just have individual functions as mini services. If you're using standalone functions instead of classes with dozens of methods, you really cut down on implementation creep and having to mock random unrelated dependencies when you're just trying to test a single method.I think this whole
services as classesthing is just a "well we did it in OOP" thing. Start thinking in functions!Maybe we stick to this pattern because constructor injection is the most common way to implement DI but it's not the only way - and in a predominantly functional application, it's probably not even the best/easiest way.
That’s correct!
In this post, I tried to bind “clean architecture principles” and “functional core in imperative shell” with pure transformations because I think it takes the best from different paradigms.
I use objects for services here just because it’s easier for me to think of a service as a “package” with a couple of functions inside, and easier to check if the service implements the interface. (I try not to use classes if there is no need to keep some state in the entity.) So, basically, it is just a function, but in a box 😃
I also think that DI via constructors is a convenient way to compose objects, although for composing functions there are other technics like boxes and mapping :–)
In general, I try not to be an advocate for a single particular programming paradigm. For example, immutability, pure functions and functional composition are ideal for describing data transformations. But for working with state I prefer objects instead of monadic state changes from pure FP 😅