Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

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

by jeyroz (Monk)
on Jun 05, 2005 at 15:39 UTC ( #463729=perlquestion: print w/replies, xml ) Need Help??

jeyroz has asked for the wisdom of the Perl Monks concerning the following question:

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

author => jeyroz

  • Comment on Code reuse and method sharing with OOP / CGI::Application

Replies are listed 'Best First'.
Re: Code reuse and method sharing with OOP / CGI::Application
by perrin (Chancellor) on Jun 05, 2005 at 16:05 UTC
    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.
Re: Code reuse and method sharing with OOP / CGI::Application
by jhourcle (Prior) on Jun 05, 2005 at 19:51 UTC

    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.

Re: Code reuse and method sharing with OOP / CGI::Application
by Tanktalus (Canon) on Jun 05, 2005 at 20:48 UTC

    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.

Re: Code reuse and method sharing with OOP / CGI::Application
by marnanel (Beadle) on Jun 05, 2005 at 17:16 UTC
    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.
Re: Code reuse and method sharing with OOP / CGI::Application
by Anonymous Monk on Jun 05, 2005 at 18:10 UTC
    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.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://463729]
Approved by gam3
Front-paged by tlm
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2023-06-09 20:49 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (36 votes). Check out past polls.