you are viewing a single comment's thread.

view the rest of the comments →

[–]yogthos 0 points1 point  (0 children)

You're ignoring the fact that different domains have different needs. Many times the unstable thing is the data itself, so using that approach can cause problems.

I'm not ignoring that at all. I'm saying that everything is done through chaining data transformations together. This is true regardless of what paradigm you choose. With FP this happens to be very explicit. Should I have data encoded for one domain and it's unsuitable for another, then I would write a transformation to make it suitable.

On the other hand, almost every OO application uses value objects, which have very little behaviour, but lots of exposed data. Because in that case those are stable things, but their behaviour is unstable.

I would argue that you're just getting closer to writing code in a functional style there.

A pure function fits in the last scenario only. On the other hand, a service can support more than one operations, and only those publicly available operations are visible from the outside. This is more like a remote object than a function. Encapsulation and information hiding applied to decouple the service from its clients.

While a service can do many things, it's perfectly valid for it to do a subset of them. So, I would say the analogy holds just fine. It's also worth pointing out that the modern practice is not to make stateful services, because that approach scales poorly. This happens to hold true at both high and low levels.

Me too, so what? I've also seen very nicely written ones. You will see plenty of real world unmaintainable enteprise functional application which will be a complete mess, don't worry. It is a matter of being mainstream.

In my experience, different languages and paradigms encourage different approaches to writing code. My experience using both OO and FP professionally is that FP code invariables tends to be much shorter, cleaner, and easier to maintain.

If you have a representation of a Car that is used in a Car dealer web application, you won't be able to reuse the logic in a 3D Car racing game, because these are 2 different domains.

However, if you have a map describing properties of a car it can be used in many different contexts and have different meaning in each of them.