I highly recommend reading Refactoring (Amazon link) by Martin Fowler; it should be in every programmer's library and will help you with situations like this. I will refer to it in the post.
If a class has too much code, then it's usually time to split up the class. That may entail creating member variables that have classes (delegating functionality), or it may mean creating an object on the fly (replace method with method object). Things that share commonalities are good cases for applying inheritance or the state/strategy pattern.
Short answer
Yes, you would go so far as to have those functions in their own files. However, I would instead make them classes. Perhaps Updater
and Builder
objects. You can inherit from BuilderCommon
and UpdaterCommon
classes. These new objects will be coupled to the old object, but that's okay. You may consider putting these new sets of classes in their own package. Hierarchical organization will help with readability and reuse of common code.
Try to take advantage of concepts like inheritance and abstraction techniques like generics to do the work for you. If you can find commonality between doA
, doB
, etc., make UpdateHelper
classes out of them and put them in a list. Then simply iterate over the list.
This is just one of the many ways to do it:
public class Updater
{
public Updater(List<IUpdateHelper> helpers)
{
helpers = new ArrayList<UpdateHelper>();
this.helpers.add(helpers);
}
public void update()
{
for (IUpdateHelper helper : helpers)
{
helper.performHelp();
}
}
protected List<IUpdateHelper> helpers;
}
public class UpdaterCommon extends Updater
{
public UpdaterCommon()
{
helpers.add(new UpdateHelperA());
... // Etc.
}
}
/*
* This uses inheritance for common helpers, but it could just as well use
* delegation. Also, this assumes that order of invocation for each helper
* doesn't matter.
*/
public class UpdaterOne extends UpdaterCommon {...}
interface IUpdateHelper
{
public void performHelp();
}
public class UpdateHelperA implements IUpdateHelper {...}
Definitely replace those arrays with objects and add an interface.
Closing
In my experience it usually only takes the application of a few of these concepts on a regular basis to make a significant difference in code quality. If a package, class, method, conditional, etc. gets to be unruly, break it out into a smaller unit. Keep pushing the nitty-gritty functionality down into very small methods so that you can look at the code from a high level.