What behaviours to put in and out of a class

Question

Let's say I have a class modeling some kind of object, for example a graph (in the graph theory sense).

I will have the graph structure and data inside the class, but what about other more complex behaviors? For example, I want to create a function that transforms the graph in a specific way, or that dumps the graph in a JSON format. Should these functions be inside or outside the class?

My first thought is to put these kinds of functions inside the class, but if I put a lot of functions, each graph object will take way more memory right?

Are there clear guidelines for this question? Also, is it language dependant?

Answer 1

if I put a lot of functions, each graph object will take way more memory right?

Wrong (at least for any language I'm aware of). There is likely a small overhead (of the order of bytes to tens of bytes) per class for adding more functions but not per object.

How much should go into your objects is to some extent a philosophical debate: the OOP "purists" will tell you everything should be a member function; other people will say that forcing everything into the class for the sake of it leads to bloated classes which violate the SRP - this can be particularly true for something like JSON serialisation which is very much an orthogonal concern from the main purpose of your class.

Answer 2

It's actually not complicated. You put all behavior in a class that needs the internal data of that class to work.

Whenever you need to "get" some data from an object to do something, well, that something should likely be in that object in the first place.

Having additional behavior in a "class" does not use heap memory, so you'll be fine.

So here are some caveats. I lied. It is actually sometimes complicated, when you have different requirements, or you're building a library for which you don't yet know, or even can't know all use-cases. Obviously if you need to support behavior that will be added later, by somebody else, you need to make data available. For example you want to support somebody else implementing a graph search. Well, you'll have to make data available and you probably won't put those things where they would be in a closed application.

Also, you can actually refactor objects. That means push "data" elsewhere, or group data together, etc. So if you feel a behavior does not fit an object well (meaning you don't have everything for it in one place), you could actually move things around, so it does fit somewhere and also the data for it is co-located.

Answer 3

I was the sole maintainer of a Java application (molecular diagnosis) for 15 years, during which time the design evolved a lot. The original developers had answered your question "inside".

... I want to create a function that transforms the graph in a specific way, or that dumps the graph in a JSON format. Should these functions be inside or outside the class?

After a few years I noticed that there were more and more transforms and dumps, or their analogues, so I started to change:

void sometransform(parameters)

to

void transform(AbstractTransformer transformer, parameters)

I already had some unit tests in place, and made a point of covering any code with tests before I refactored. My experience with large systems is that one never gets it right the first time, because the client never gets it right the first time: the client makes educated guesses about the behaviour of the market, the listen to feedback (otherwise they will go broke and not be able to afford developers), and their requirements evolve. So change the code: if it protests that the change hurts too much, change the design.