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 Application
class to your Perl script.
Application
seems like overkill.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.