Code reuse and method sharing with OOP / CGI::Application

[jeyroz]

Forgive my naiveté but have found conflicting opinions on the following topic. I am attempting to make use of CGI::Application and OOP on a project but feel as though I am hanging myself with all the freedom that Perl provides.

For the (procedural) projects I have worked on in the past, a module has been set up with common methods used throughout the application via Export. My question is, when structuring an application (made up of smaller applications) what is the best procedure for sharing a basic set of methods. These methods aren't to be overridden or refined ... just used by the separate application modules. I have seen this accomplished in several ways:

1) Set up a Base C::A module / class that @ISA CGI::Application. This Base class implements sub setup{ ... } and the standard set of C::A methods and is used by all other C::A modules (providing access to the default set of C::A methods as well as any common (custom) methods through inheritance). This seems like a good way to share common run-modes maybe, but not utility style methods.

2) Set up a Base class (Super / Abstract class) to share methods through inheritance despite the fact that the relationship between the base and subclasses isn't one of inheritance ... just utility.

3) Set up a "utility" class to be 'use'd by the C::A modules (any any custom classes) providing access to the common methods.

I hope I explained that clearly enough ... I know that all three are somewhat similar but I am looking for the 'cleanest' way of doing it.

Also, if you think I am wasting my time trying to share a somewhat mismatched group of methods and should be breaking these methods up into respective classes (ie: a Display class that handles template output, pagination display, etc. / Authentication class that handles user auth, session management, etc. / a Debug class that provides Dumper and various diagnostics) please let me know. I am teetering back and fourth on that as well.

Thank you all ahead of time ... I appreciate the help.

- junior monk

[perrin]

I've used #1 before and it works fine for things that are related to being a web controller. However, an OO purist would tell you that inheritance is not about sharing a bunch of random methods. I think your best bet is splitting the methods up into their more logical classes, especially if you eventually expect others to work on this code.

[jhourcle]

Will all things being equal, you do whatever makes best sense to you.

You're the one who is most likely going to be maintaining it, and making things so that they make sense to you, and will be easy for you to maintain.

What makes sense for someone else may not make sense to you. Yes, there's the concept of 'best practices', and 'best' is an ideal that is rarely realized.

That being said, what makes sense to be is to divide them up into modules of specific functionality (because it's easier to maintain, in my opinion), and then to make a super class that inherits all of the commonly used modules (just because I'm lazy), and possibly that functionality that didn't fit into a nice little container, but was widely used.

Of course, because I'm using mod_perl, I don't have to worry about the overhead of loading modules when they're not needed.

So, I guess with the choices you've given, I'd use a blend of #2 and #3 (maybe even some of #1). As for when you draw the line between #1 and #3 (use vs. inheritance), I'd think it's just a matter of how you think about your problem -- depending on where you place a sub system's boundries can affect what is considered inherited, and what isn't.

[Tanktalus]

If they're utility functions that aren't necessarily part of what the C::A module is for, there's no reason why you can't continue to put them in a module that uses Export. If they are merely "utility" and not parts of the C::A "object" nor part of their own objects, #3 makes perfectly clear sense, with the added advantage that you are already familiar with this tool.

[marnanel]

I think whether you should split up your methods thematically depends on how much you want to reuse them. Eventually, when you're writing another project, you'll want to use (say) a Debug class with methods similar to the debug methods you have in your common module. If you haven't split up your methods, you'll either have to import the whole common module for an unrelated project, or copy-and-paste into a new common module.

[Anonymous Monk]

The combination of #1 and #3 is what I have commonly found myself doing. The #1 part of things allows customization of the CGI::App--like setting up plugins, custom output modes (like a debug page, for example), and choice of template system, as examples. The #3 part of things allows you the flexibility of code reuse and logical factorization. You can make a "Model" module that deals with your data model and access or a "Login" module that has methods for creating users, deleting users, and validating users associated with a given project. The "Model" module could then be used for loading data into a database as well as for web apps. The "Login" module could be used for a local Tk-based app for faster/more interactive data manipulation or data entry. Hopefully, you get the point.

Sean