CODEWITHSUNDEEP
java
jmasterx
jmasterx

Reputation: 54183

Code Organization with many private methods?

I often find myself programming like this:

public class SomeClass implements SomeInterface
{
  private someData;
   public SomeClass(Parameters And Stuff)
   {
   }

   private void a()
   {
     e();
     f();
     g();
   }

   private void b()
   {
     h();
     i();
   }

   private void c()
   {
     j();
   }

private void d()
{
   ...
   might call even more private methods...
}

private void e()
{
   ...
   might call even more private methods...
}

private void g()
{
   ...
   might call even more private methods...
}
.......
private void j()
{
   ...
   might call even more private methods...
}

   @Override
   public void interfaceMethod(Some Parameters)
   {
     a();
     b();
     c();
     d();

   }
}

The real method names are meaningful and have return values and parameters.

But the point is, there are only 1 or few methods hat the user calls, which is good, but, in order to try to keep the implementation clean, I break it down into a whole lot of private methods.

Is this a good idea? If someone else looks at my code, unless they follow the execution trail, it might be a little confusing?

Is this programming style acceptable? Is there maybe a cleaner clearer way to deal with this type of situation?

Thanks

Upvotes: 2

Views: 1016

Answers (4)

AlfredoCasado
AlfredoCasado

Reputation: 818

Off course is a good practice, each time you create one of those private method your are giving a MEANING to this lines with his method name, there are some considerations:

  • Prefer always short methods (in java more than 10 or 15 lines is big)
  • Think harder to find really good names that guides the reader of your code an that are, kent beck often says "intention revealing" names. And when you think that your names are good, go for a break, read again your code, and find better names :P (finding good names its one the most important things in software design, perhaps the most important).
  • Try to follow the "newspaper metaphor" from robert martin, clean code is a mandatory book for every software developer.
  • Sometimes, if you have a lot of private methods, think in terms of single responsibility and perhaps you discover that this class can be splitted in small classes.

Upvotes: 0

Kevin Bowersox
Kevin Bowersox

Reputation: 94499

This practice is 10x better than its inverse (1000 line methods). Just make sure you adhere to the DRY principle and keep an eye out for areas in the code where an object could make life easier. You can usually identify these areas by keeping tabs on the number of arguments passed to the methods or the same arguments being passed to multiple methods. This is a clear indicator a class instance variable or object is required.

Another quote from Bob Martin's book Clean Code is:

The first rule is that methods should be small. The second rule is that methods should be smaller than that.

Upvotes: 1

Tim B
Tim B

Reputation: 41210

This really comes down to coding style rather than any hard and fast rule.

The thing with these sort of methods is to ask yourself:

  1. Is the code reusable - if so it would make a good method

  2. Is the code very long - if so I should consider splitting it

  3. Can the code be made more readable by splitting it - if so I should consider splitting it.

On the other hand though:

  1. Is the code not re-usable? If I will only ever call it from one place is it worth having it as a method?

  2. Is this method trivial, is it actually worth having separately or should it be merged into another?

  3. Does separating the code maker it clearer/cleaner - or would it actually be simpler to merge it?

Judging the correct way to weight these sort of questions is what differentiates an experienced programmer with a clean architecture from a novice programmer with a mess. Unfortunately I can't give you a hard-and fast answer though as it is more art than science.

Upvotes: 5

Teresa Carrigan
Teresa Carrigan

Reputation: 698

As long as the method names are properly descriptive, this is a good practice.

Upvotes: 1

Related Questions