I've been musing on #OOP style.

[thelastpsion@oldbytes.space]

I've been musing on #OOP style. I have a question for the more experienced programmers out there.

How do you decide when a class's method doesn't actually need to be a method, but instead could just be a regular function?

I'm not talking about functions that need to be shared between classes. I'm talking about intentionally moving a method outside of a class, even though it will only ever be used by that class.

For example, if I've got a parser-related function that is only needed by the parser, I will normally just put it in the parser class as a method. It keeps things neat, I can make it private and lock down the class. But I've never before stopped to think whether this is the correct thing to do every time.

After all, #Pascal (my language of choice) has the concept of units. I could just have some functions just as functions, and only have methods for things that directly need to update the class's properties.

It would make things easier for testing, too. I wouldn't need to create an instance of a class just to test a specific function works as intended.

But I don't know if it's the "right" way to do things in OO, or #ObjectPascal for that matter.

#OO

[eoinprout@mastodon.ie]

@thelastpsion if its a pure function, just operating on the parameters and no side effects then i think its a good candidate for just a function. Otherwise it would probably be just a class method.

[eoinprout@mastodon.ie]

@thelastpsion and as you say it simplifies testing

[jnkrtech@social.treehouse.systems]

@thelastpsion my 2 cents:

If it’s tightly coupled to the structure of the class or breaks the class’s encapsulation somehow, it goes on the class

Otherwise, if you’re using a language that allows you to control what functions are exported separately from what class members are exported, then it depends on the tradeoff between easy testing and a clean interface.

If it’s a private method then it’s generally best to not unit test it directly (in a perfect world). If it’s a separate function then that’s much easier to unit test.

If there’s no way to make it clear to consumers of your module that this code is supposed to be internal, then moving it out of the class increases the chances of people depending on it when you don’t want them to, or it can make your interfaces more cluttered.

Once you have unit tests for the thing, it will want to settle towards where you’ve put it. So if you could see this function one day becoming part of its own class, I would lean towards extracting and testing it separately early.

[philcowans@universeodon.com]

@thelastpsion - I don't know Pascal, but in Python you have static and class methods which can be used for this sort of thing.

Python conventions do encourage using plain methods rather than making everything a class by default though. You could maybe extract an inner module (rather than an inner class) if you had several such methods and wanted to encapsulate them from the rest of the class.