I'm building a perl application which does the following operations:

  1. Copy a bunch of files (class fileFetcher )
  2. Parse each file (class fileParser)
  3. Store some data from each file in a database (class dbHelper)

Now, should I, in my main.pl (entry point of the script), construct an instance of each of these and call the appropriate methods? or is it better practice to have a separate "Application" class that does all the instantiations and method calls, and let the main script just have a call like Application.run(args)?

The class, would exist just to instantiate and call methods on things, and doesn't seem right.

  • 2
    Please read up on the single responsibility principle. Short, immediately obvious routines which do nothing but call other well-named routines are a very good thing. No bit of code should ever contain details about such different things as copying files and parsing content. Jun 14, 2013 at 9:02
  • @KilianFoth It doesn't contain details, merely an instantiation and a method call on the object. Jun 14, 2013 at 9:11
  • @DarkCthulhu: I agree with you, but can't formulate it well enough for a proper answer. A class Application seems like overkill. Jun 14, 2013 at 9:26
  • 1
    @DarkCthulhu: Okay, so the choice is only whether the gather(); parse(); manipulate() sequence should be in the main body or in a custom class. As long as that's all you do, it's fine to have such a sequence as your main program, but as soon as you find you sometimes have to copy files a little differently, or make multiple parsing passes, or make the sequence configurable, it would be refactoring time. Jun 14, 2013 at 10:21
  • Ewwwwww... object oriented perl
    – Dynamic
    Jun 14, 2013 at 19:04

3 Answers 3


Apply the YAGNI principle - as long as you have only 3 objects, and only one entry point into your script, you most probably don't need that additional Application class, so don't create it. This would not make your code more readable or better maintainable - so why bother (for now).

However, when your script becomes bigger in the future, and your main.pl gets additional responsibilities, it may be a good idea to refactor the instantiation code of those combined operations into a separate function. Giving that function a meaningful name describing the operation as a whole would be very good idea. Furthermore, when your program grows to a state where this operation is just one of many other operations, that would be an even better reason to refactor things out of main.

When it shows up later that this operation needs additional "global" state or environment information, then this new function may be refactored into a class to make that global state a member variable of that class. That class typically won't get the name Application, since this name is not very descriptive for what the operation does. But refactor when this happens, not beforehand.

AFAIK the notion of having a separate Application class comes from some (mostly C++) GUI frameworks where this is standard way of definining a kind of entry point and globally available object. See, for example, this SO post, about the QApplication class in the Qt framework. I don't know if there are Perl frameworks out there with a similar approach, but as long as you are not using or creating such a framework, I don't see a point to add an Applicationclass to your Perl script.


Keep It Simple

Don't create a separate Application class it's not necessary. Nothing bothers me more than having to turn over rock after rock after rock to understand what's going.


I don't think it's necessary in this case, but I also don't think it's necessarily a bad decision -- but if you do, your name is. It's not Application, that is effectively what your main is. What it is, is a workflow or a process. Application doesn't need to be an object and doesn't benefit from being an object. Your process might.

If you think it possible or likely that your process may be incorporated into a larger process, then go ahead and make it a class, until then, I'd leave it as it is.

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.