[trilila]

In OOP those groups are called classes, and the fun is that you can instantiate them and call them objects. And within those objects you can set a state, so those functions operate against it. A nice feat of OOP is that you can also inherit logic and expand it.

[StreamBright]

The question why would I need to do that?

Btw. no, this is not how OOP works. With the method I outlayed I have very easy time to achieve idempotency, the thing you suggested makes it harder because the objects have internal state and the method calls can depend on those.

[blodovnik]

Sounds disastrous.

[trilila]

In the wrong hands, it does. Easy to tangle OOP. But the point is each of the two paradigms has its own benefits, and should be used when best for the task at hand.

[pjmlp]

Somehow it seems hard to grasp that at their core classes are basically extensible modules.

[mikekchar]

The key to understanding classes, IMHO is that you are grouping functionality to make the code more cohesive. The style of grouping is to group the functions based on the program state where these functions make sense.

Often people go the other way around and write entity relation diagrams. They write classes to encode the data that they want to work with and put the functions that interact with the data into those classes. This actually leads to code that isn't OO (again IMHO). It actually more closely resembles modular programming. You have areas where you say, "I'm dealing with that data here". All of your instance variables are essentially global to that module. Especially when the classes become large, this becomes mostly indistinguishable from imperative code with global variables.

Instead, consider the parameters that the methods on your class use. Imagine that you had no instance variables and that you had to pass all of the parameters to your functions. Now group all of the functions that use mostly the same parameters. That's a class. The instance variables represent some state of the program and the methods work on that state. Afterwards you can make diagrams to see how these objects interact with each other, but it usually doesn't make sense to do it before hand (because otherwise you end up with bags of data and functions that act on that data as if they were global variables).

Or, more concisely: An class is not a table in a DB and you shouldn't model it the same way ;-)

[trilila]

Indeed. Sometimes tho one just needs to pass a data set to a function, then the result the another, and so on, without the execution branches needed for figuring out the modularity rules and constraints of OOP. And that is where functional programming is relevant (and in math like scenarios, where speed and accuracy are key). But not as a rule of thumb, for everything programming.