I'm writing a class that draws a very complex image, with multiple parts. I also plan on adding to the class to add more functionality. Would it be right to make a function for each part, even if that function will only EVER be called in the render function? I see an upside to this since it will be easier to read the code, and easier to add parts. A downside however, would be that it would increase complexity and quite possibly make it harder to maintain. Should I keep all the code in the render function, or break apart the different steps?

  • I guess your post title needs to change. Also, what you are describing here is encouraged by "Structured Programming".
    – NoChance
    Commented Dec 11, 2011 at 20:05

3 Answers 3


Nope, breaking down complex methods into a sequence of smaller, private methods is perfectly good design and improves maintainability, if the new methods have descriptive names.

  • That's what I figured. I just thought maybe if I end up getting so many "steps" that maybe it would get out of hand. Commented Dec 11, 2011 at 19:40
  • @LordZardeck: sure, every good thing can be overdone. If the number of steps really gets too large despite each one being non-trivial, that's an indication that you should try to break up the whole class into several parts with separate, mostly self-contained responsibilities. Commented Dec 11, 2011 at 19:45
  • So possibly breaking each step into it's own "step" class? Then having the original class build the steps? Commented Dec 11, 2011 at 20:08
  • 1
    @LordZardeck: something like that. But thinking in "steps" too much smacks of procedural design. It would be better to have parts of the image that know how to paint themselves and also contain the necessary data. Or perhaps factor out computation tasks that are not directly related to painting. Commented Dec 11, 2011 at 20:54
  • @LordZardeck Data. Classes are also a lot about data. If you have some piece of code, where the data for the operation and the operations themselves can be self-contained, then it is a good candidate for a separate class.
    – Malcolm
    Commented Dec 11, 2011 at 21:54

Definitely break it up! Break your steps into logical parts. This makes the code much easier to troubleshot, especially when you are employing unit tests, which itself will save you loads of troubleshooting time in the long run.


Implementing small parts of an algorithm in separate methods that are all called from a "controlling" method, your render method, is an example of using the Template Method Pattern. It is an appropriate way to manage the complexity in your scenario.

As you decide how to refactor functionality into smaller methods, you will want to consider how to support your planned modifications while adhering to the Open-Closed Principle. That is, try to break the methods down in ways that you can implement your changes by overriding individual methods in subclasses.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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