Function objects with no state shouldn't be object oriented?

Question

My question relates to this topic here: Are classes with only a single (public) method a problem?

There I read in the comments often something like that:

It is no longer object oriented. Because those classes don't represent anything, they are just vessels for the functions.

So my question is, how to write that the object oriented way?

In the topic I linkened the main question is, if it is a good design having just one public method in a class, which have no state.

Let's say I have the following two classes

class A
{
    String field1;
    String field2;
    String field3;        
}
class B
{
    String field1;
    String field2;
String fieldK;
String fieldM;

}

Now I want to have some/two "behaviour";

    private String behaviourA()
    {
        //works with field1 and field2
    }
private String behaviourB()
{
    //works with field1 and fieldK
}

class B should have behaviourA and behaviourB class A can only have behaviourA

I don't want to copy-paste behaviourA into both classes. So iI could use inheritance. But if class A and B already inherits from something else, then I can't use it, if no multiple inheritance is availiable.

So my solution would be an extra class Z, which contains behaviourA and inject/or hard-coded (the injection detail is not relevant for my question) this into both classes A and B, but class Z is in that way just a "functionObject" with no state.

Something like that, from that people say, that this isn't object oriented.

I don't say that this is bad. (SOLID and object oriented design are somewhat close, ask @Robert Bräutigam ^^ And I'am on his side in that thinking.)

But my question is here now, how poeple, who say, that classes with no state and only behaviour/one method are not object oriented, would refactor my example not having multi inheritance and not having copy paste of code to get an object oriented design in their opinion.

Answer 1

The premise is just wrong. It is fine to have object with no internal state and can be perfectly "object oriented".

A common example is in the Strategy pattern, where the strategy-object encapsulate some behavior or algorithm separately from the data it operates on. A strategy object can fulfill its role fine without any internal state.

To be fair, there is no exact, universally agreed definition of "object oriented". But I don't know of any reasonable interpretation which would say the strategy pattern was not object-oriented.

In your particular case, it would be fine to have behaviourA and behaviourB as two stateless objects (or function objects) and then use them in class A and B as appropriate.

I can't explain why someone would claim this is not object-oriented, but if I had to guess it is probably a misunderstanding due to the fact that you don't necessarily need an object. If the object in question have only a single method you might also be able to use a stand-alone function or lambda instead. In many cases this would be simpler. But there could also be good reasons to use an object. E.g. if your are implementing an interface or have to support inheritance, or if you anticipate the need for more methods.