Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Few Large Classes/Methods vs. Many Small Classes/Methods

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic