Hacker News Reader

One thing I hate though, in a language like Java, is when I see "utility" classes with static methods which take objects as parameters, then perform some calculation based entirely on the state of the passed in object. In my opinion, if the object can reason about its own state and return an answer based on that reasoning, that method/logic should be in the object, not elsewhere.

Another one that bothers me are these transformation static methods which take type A and return type B based on nothing but the state of type A. The languages were talking about, C#/Java already provide a facility for this called a constructor.

If the development approach is going to completely remove operational methods from data types then I'd think long and hard about using a language which supports this instead of a language, like Clojure, which does not.

I think you made a good point: it is easy to shoot yourself in the foot with OOP. It is difficult to shoot yourself in the foot with FP. But when OOP is done correctly it offers useful features.

> that method/logic should be in the object, not elsewhere

Only if it's involved in preserving some object invariants, or accessing parts of its state that are abstracted away in the public interface. Otherwise, you're breaking encapsulation by putting some logic in the object that doesn't belong there, and making it hard to change the implementation later.

> The languages were talking about, C#/Java already provide a facility for this called a constructor.

There are sensible reasons to avoid using constructors for this, at least in the general case.

> Only if it's involved in preserving some object invariants, or accessing parts of its state that are abstracted away in the public interface. Otherwise, you're breaking encapsulation by putting some logic in the object that doesn't belong there, and making it hard to change the implementation later.

I've been pondering this thread all day, and I think this is the crux of the issue. Ideally, classes would only encapsulate state and you'd use namespaces/modules to encapsulate functionality. But most Java/C# OOP examples use classes to encapsulate both state and functionality, which gets you stuck in the morass that the article discusses.

What you ask for is mostly impossible because you might not know about every possible object you'll be getting your construction params from....and besides that's horribly coupled. What about circular dependencies?

C# helps you to some degree with extension methods so you get the same instance.Method() syntax.

> Why should I build a model specifically for this one context of usage and have the properties tightly-coupled to their mutators, when I can completely decouple these things and have the models operate with any arbitrary state mutators?

Because otherwise, your domain model is not able to express which states are valid. A core idea behind encapsulation is that by controlling state mutations, it is possible to enforce invariants, thereby making invalid states impossible to construct. This idea is not unique to object orientation; for instance, in the static functional programming community, this is known as "making illegal state unrepresentable" [1].

By creating a "dumb" domain model and allowing business rule modules to do arbitrary mutations, each model is required to know about and enforce the domain model’s invariants itself, which dramatically increases the amount of code that potentially can break these invariants, and thus needs to be debugged if something goes wrong.

> Taking this a step further, you can have a business model project (class library/Nuget) that is shared across multiple projects within an organization.

This can work in some situations, but there are good reasons not to do this. Different teams may have differing and sometimes conflicting meanings for some of the terms of the domain (especially for generic concepts such as "user") as well as different data needs depending on the use case. This is why for instance Eric Evans’ "Domain-Driven Design" [2] argues for limiting domain model unification to "bounded contexts" [3] of which there may be multiple in the organization, and have explicit translation ("anti-corruption“) layers between the boundaries of these contexts.

[1]: https://fsharpforfunandprofit.com/posts/designing-with-types...

[2]: https://www.goodreads.com/book/show/179133.Domain_Driven_Des...

[3]: https://www.martinfowler.com/bliki/BoundedContext.html

The problem is that people never properly understood which operations were supposed to go on objects, and they just started accumulating everything that was even loosely related. My favorite example is registering for university courses. So you have a Student object and a Course object... Which one does the register function go on?

Objects should only contain those methods which are required for the invariants of that object. A course registration function is a workflow that involves two types, but does not control their invariants, so it belongs on neither. Most business logic falls into this bucket, and that bucket really works best as a functional paradigm where one can freely recombine the logic to create new workflows.

(The worst answer I've seen is that both end up with a register method, with one just reversing the parameters. So Student.register(Course) just calls Course.register(Student).)

There are well-defined patterns for such behavior. Domain services are introduced to protect invariants _between_ entities. Implementation is simple really. Student “fills out course registration form” (VO) and then Course “completes registration with filled out registration form”. Essentially the behavior of registering for the course is distributed between Student and Course as appropriate.

The point I’m trying to make is that the problem is not inherit in OOP. The problem is that domain modeling is hard. If a developer cannot synthesize the above “solution”, I’m not sure a different paradigm is going to help.

And why does a Course register a student? Why does it know what a "course registration form" is? None of these things have anything to do with the Course object or is invariants... The Course is just one of many parameters into the workflow. Why is it therefore responsible for the actual act of registration?

In real life, the aptly named "student registrar" is responsible for performing the task. But they're not an entity within this system... Rather they are the context in which this system is running. So a non-bound function actually makes perfect sense... It's bound to the top-level registrar context of the system.

In BPMN, the registrar would be one swimlane, and the registration the process, with additional swimlanes for other actors like the student. The registrar still owns the process, but BPMN allows for other actors to also play parts within the system.

A relational view would introduce a Registration which would join a Course and Students. The workflow would create a Registration, which defacto means that an individual Registration cannot be responsible for executing this.

> Most business logic falls into this bucket, and that bucket really works best as a functional paradigm

There is nothing I can see here that calls for FP. You are still mutating the state of the world.

Just use a free standing function. That's like a method on "The world", which is the object where we should put most functions. Programming is easy. (Not: all the technical decisions behind it)

I explicitly call out the reasoning for using functional concepts here: recombination into new workflows. For instance, a student may only be able to register for 15 credit hours or less. However, an advisor can register a student for up to 20 credit hours. If done properly, this should be a very simple change within the workflow... Just swap out the verification function that's composed into the workflow.

I still don't see what's functional about this. Functional is about higher-order functions, currying, and so on. I'm not positive most business logic profits from that. What you describe can be achieved by swapping out a number (or more generally, data).

Of course, we can come up with a scheme that requires two validation functions that have more distinctive features than just some number's values. And in this case that might be implemented by parameterizing the function parameter. But, it could also be implemented with a switch for example, and often this approach is more maintainable. And then, you can also have pointers to functions in conventional programming languages. In general, the need for functional approaches is vastly overblown.

I mean, it all boils down to assembly in the end... Why not just do everything in assembly?

I'm finding little too your arguments other than what seems to be a pre-existing bias towards functional approaches being "overblown", along with various alternatives which of course exist, because every programming paradigm is capable of implementing arbitrary logic.

Some abstractions will help you do certain things. If you find yourself constantly duplicating and tweaking the same axiomatic logic to do different things, functional approaches are generally a more helpful abstraction than others.

I can give you a good reason why not to do assembly. It requires you to allocate storage for data by constantly swapping it in and out of a fixed number of places. It binds you to minute details of a specific architecture that don't matter in 99% of the cases. It doesn't have a facility for subroutine calls (one of the most successful abstractions for sure), requiring the programmer to redundantly encode a calling convention at each call site, which also affects register allocation. It doesn't allow you to give descriptive names to local variables.

I'm not positive that functional approaches can bridge a similarly distinctive gap. But I know that it's easy to get tempted down rabbitholes where we constantly restructure programs without measurable benefit, or make abstractions that we regret later on.

Instead, it rather seems to me like mainstream imperative languages adopt a few simple features where they make sense (or not). For example, sometimes it's nice and elegant to look up items using a predicate function, although usually I'll actually prefer the explicit for loop or such (but yeah, YMMV).

One more problem I see is as follows. It seems to me that assembly->procedural (compiled) languages is a step that improves encoding efficiency in a very "local" way. It's still pretty easy to contain and control these abstractions and make different decisions in other places, and still have the places interact easily enough. With more advanced systems, I'm not so sure. There are so many general, far reaching assumptions how computation should be done (language runtime, code generation, etc) that go beyond the mere constraints of the computer's architecture. I think these lead to a lot of isolation that is not beneficial.

> If you find yourself constantly duplicating and tweaking the same axiomatic logic to do different things,

Point is, I really don't. (I'm not sure what "the same axiomatic logic" is, but I don't find myself duplicating a lot of things). Actually, it often seems to me things are much easier and less redundant if we can just focus on the data and not get a type system or similar in the way. Of course there might be problem domains where things look a little different than I've experienced.

> I still don't see what's functional about this. Functional is about higher-order functions, currying, and so on. I'm not positive most business logic profits from that. What you describe can be achieved by swapping out a number (or more generally, data).

And a discussion about composing functions is a discussion about higher-order functions. Why is that not FP?

This is the antithesis of OOP. Behavior should be modeled with data, not around data. Given a new use-case (some mutation of state), how can you be sure that an invariant is not bypassed if invariants are modeled at the level of each use-case? Any solution to the above begs the question, as all you will have done is distributed your “domain object” across the filesystem. Your system would be better served to simply put all the rules and objects into a single file which brings us back to original claim.