First of all, the whole point about too many methods, functions or classes is right out.
A compiler absolutely should optimize out all those calls to just leave the meat of it. If yours doesn’t, try Java. Also, ALWAYS go with the first expert rule of optimization, don’t optimize for speed until you’ve written the best most understandable non-optimized code you can–and that means the smallest.
It really blows me away that people can argue with the most common, basic facts of software development. It’s like an architect arguing that straw makes a better building material for high-rises.
We solved the problems long ago, if you don’t like the rules–go study, the rules aren’t wrong.
-Small methods, small functions, small objects and small files are more understandable and usable (good).
-Documented code is good.
-Any repeated logic anywhere is bad.
-Too many interactions between entities is bad.
-Variables that can be modified outside your currently displayed file (globals/publics) are bad (Actually just the worst case of the previous point).
-There are many others.
There are many fine points in our line of work that you can argue over, but if you find yourself arguing against one of these, please reconsider. If after consideration you still believe you are correct, please find another line of work–for all our sakes.
Remember also, The primary user of your code is the next programmer, not a computer–otherwise you’d just throw away the source and keep the object code.
PS:
To the people who had trouble because his small classes weren’t understood:
Small classes are no harder to understand than large classes. I hate to say this, but consider that you should work on your communication ability (I always feel it’s my fault if I can’t download a concept from my head into someone else’s)
Even before you code, you should be able to visualize your main classes or functional units and the relationships between them. If you have more than 5 small “core” classes, draw them on the whiteboard before you start coding. Eventually this should make it onto some form of paper. I’ve photographed whiteboards and created in-depth UML diagrams, but the whole point is to come up with whatever is necessary to communicate your structures to the others on your team.
What your users want to know is what are these core classes and how do they relate; this is exactly what class diagrams were created for.
Coding the small classes is easier for you to understand, so if it’s not easier for the rest of your team to understand, bridge the gap and do whatever it takes to communicate.
This communication ability is what separates a senior programmer from a Junior.