In the code I am working on, there are a lot of really small objects like:
class HasFieldLameSetter
{
public:
HasFieldLameSetter(field& p_):m(_p){}
void set(bool p2)
{
m.hasLame = p2;
}
field& m;
};
Having lots of small classes creates a hard-to-read and complicated “code pasta”. Sometimes, reading it is really really hard because I spend a lot of time jumping from file to file to find out that the class did something trivial like in the example setting bool to true. In addition, those objects are being passed around everywhere by “dependency injection” which makes reading it even more difficult.
How do I persuade the author of the code to write slightly bigger objects?
In my opinion too many small objects is just a nightmare for programmers. Am I missing something, or is there a mistake in my thinking? I would be happy to read any papers that might change my point of view.
4
Could I agree with it? Not often.
It is universally excepted best practice that an object have one, and only one responsibility to change (Single Responsibility Principle). For something like this, the code very likely needs to be very granular in order to compose these little teeny objects into more meaningful things.
It is also very common in older C++ and Java where the tiny objects are essentially functors/delegates/function objects, but the language does not support nice syntax to cut down on this sort of boilerplate.
A bunch of tiny objects can get over-engineered or “too” abstracted, but it’s not a nightmare and occasionally necessary. I’d rather have too small objects than too large any day.
1