15:00
Nah, OOP gives you a banana if you build one.
I was actually thinking about OOP vs FP the other day.
I decided I like FP better because a pure function can be worked on and made correct in isolation.
You can write a piece of code, test it, and know 100% that it will work.
In OOP, it relies on the call sequence because of field assignments, etc. In FP, it doesn't.
With a well-built FP language, you know that you have the only reference to a copy of data unless you explicitly override it.
(Prevents race conditions, etc.)
And it enforces that you check common error states by encoding them into the type system (i.e. null/Maybe<T>).
So you either know 100% you have to deal with a potential null state before you get the value, or you 100% know that it can never ever be null.
It's kind of like a for vs foreach. The foreach will never give you an off-by-one error.
At the end of the day, a well-structured FP program looks surprisingly like a well-structured OOP program.
You have modules of related content, interface-like types (in C# terms, basically a class of delegates).
You have method-injection instead of ctor-injection.
For example, instead of injecting your DB instance to the ctor and using it over multiple methods, you pass it into each method.
But, if your language supports currying, you can make that the first parameter and pass it in at one point to create a new function to pass around where you don't need to worry about it.
VBA Rubberducking
VBA Rubberducking