Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In the code I am working on, there are a lot of really small objects like:

    class HasFieldLameSetter
        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.

share|improve this question

closed as primarily opinion-based by back2dos, pdr, Steven A. Lowe, Robert Harvey, MichaelT Sep 11 '13 at 2:37

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

This is very subjective and also depends on the situation. Such decomposition and DI will later allow to inject a more complex implementation than the most trivial one. This may or may not be over-engineered, but that's hard to tell without context. – back2dos Sep 10 '13 at 17:39
It's what you end up with when you follow diatribes like "Single Responsibility Principle" religiously and/or are interface happy. Yes, the code becomes very flexible. Unfortunately, it also becomes unmaintainable because few people can understand it. – Dunk Sep 10 '13 at 18:23
Is code pasta a more elegant version of spaghetti code? – mclark1129 Sep 10 '13 at 19:47
@mclark1129 From this jargon site, Pasta Code is an overarching category. Ravioli Code is an OOP version of spaghetti code. – paul Sep 10 '13 at 20:48

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.

share|improve this answer
The only thing I would add, is that at first its going to be disorientating, but when you have grasped how the code is organised, it makes it much more maintainable – Michael Shaw Sep 11 '13 at 11:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.