This is another best practices question. From a design standpoint, can having one large class that does a great deal of processing be bad for program efficiency? If that class were divided into smaller classes, would there be a significant improment in speed and efficiency in the program? Also, do large methods have the same effect as large classes, even if there are a lot of conditionals (if, while, for) in them? Would dividing larger methods into smaller methods save on memory. I'm about to refactor some code that I inherited, and I need to know whether the changes I mentioned above will make the program more efficient. Obviously, they will make the code more readable and easier to maintain.
Here's what I think. And, yes, I know I should test before making statements about performance, but ... Breaking a big class into several little classes is a good idea, for program maintainability, iff the break-down is "natural". But, from maintainability point of view, splitting a class just because it "looks too big" generally makes things worse. From the point of view of memory, there is a smallish overhead in having several small classes, rather than one big class. However, this only applies if your application will use all the facilities of the big class. If your application only uses a small proportion of the facilities of your big class, then it still has to load the whole big class. If, on the other hand, you split your big class intelligently, then it may be that your application may never need to load some of the small classes. With regard to methods, it is my view that, for maintainability, they should never be very long. Ideally, each method should fit on the screen in a typical editor. This makes it much easier to see what's going on, providing that all the methods called by your method have helpful names. It is easier to refactor and reuse code that is in small chunks, rather than big monolithic slabs. Documentation and debug checks are easier, because you can document the values that each small method expects to receive and can test for them at the start of each method. From the performance point of view, there is a small gain in having one big method, rather than several small methods, because you save the overhead of the extra method calls. From the memory point of view, there is again a small gain in having one big method, providing that you do not duplicate code. An aside: duplicating code can occasionally be worthwhile, in the most performance-critical parts of your code. For instance, one technique is "loop unrolling" where, instead of executing your loop N times, you duplicate the content of the loop, say, 3 times, and execute your loop N/3 times.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
A thought: if you carefully refactor your code, it will not only be easier to understand, it will also be much easier to modify (because the impact of a modification will be well understood and localised). And when it's much easier to modify it will be much easier to performance tune. - Peter
Now I am super curious what sports would be like if we allowed drugs and tiny ads.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop