Three Four pieces of advice:

1. Use an RDBMS.
   • MySQL
   • PostgreSQL
2. Use Templates.
   • Template Toolkit
   • HTML::Template
   • HTML::Mason
   • Many, many more...
3. Use an application framework.
   • CGI::Application
4. Use mod_perl (thanks fuzzyping)

Those who know that they are profound strive for clarity. Those who
would like to seem profound to the crowd strive for obscurity.
            --Friedrich Nietzsche

"Perfect" object-oriented architectures are as elusive as Plato's forms, and even more so when sought beginning from a script. For example, using our to declare your objects within MyScript::new not only makes those globally accessable, thereby violating encapsulation, but it in no way ties those instances to the instance of MyScript, rather to the package. So far you've got a script that merely utilizes packages and functions, not objects.

If you want to make this a thoroughly OO system I suggest reflecting on this as a data structure issue. What groupings of information naturally fit together? What information ought to be unique to a particular instance of the package, and what may be appropriately tied to the package statically? If done well the program control flow will follow naturally from the object model, rather than a preconceived notion of control determining how you model your data.

I also recommend perusing the tutorials section on OOP.

Now, depending on the structure of your site, will depend on the pattern you choose to implement.

There are two ways to go about this i reckon.

1. Design your site with no concious thought to a "formal" pattern, then read up on patterns and find one which suites your design.
2. Read up on patterns, and choose one that fits your problem.

IMO, either way, if you're looking at reusable objects and OO design in general, you really need to look at (and understand) patterns. Before I read about patterns, my designs came close to what a pattern was defined as, however there was "something lacking". After some reading of various patterns I had the tools in place to design a "more complete" solution.

Now this may not be what you're after, however, understanding at a top level what you want to do before jumping in and coding 1st is a much better way do design IMO.

Best strategy? There are definately ones (patterns) that will not suit, however there are quite a few that probably will. In fact, there may be multiple patterns you can employ in your solution.

Not perfect, but very helpful: Can you say Bar is a Foo? Try inheritance. Can you say Bar has a Foo? Keep an instance of Foo in Bar, or else construct a temporary one in Bar's methods.

After Compline,
Zaxo

First of all, if your reason for going to OO is speed, forget it. That's not the reason we do it. In fact, most of the time we lose a little bit of efficiency when we use an OO approach because there is typically a level of indirection in the design.

Example: If I simply stat() a file to get some information, it's reasonably fast. If I create an object to help me with this, I call one of my object's methods, it calls stat() on my behalf, it assembles the return values into a data structure that I access through my other object methods. I might need to make two function calls myself, and my object may have to make yet another function call.

There is speed in OO programming, but it's development time speed. You can write your code faster sometimes, and you can usually integrate it or enhance it much more rapidly than with a simple structured linear design.

Perhaps a pithier way to say this is that OO programming won't make your program run faster, but it will make you able to add features faster.

On the other hand, if you are planning to write a system that needs 10000 lines of code, you probably do need to consider taking the Object approach. (Though if you write 10000 lines of good Perl, you should get something as substantial as an operating system in my opinion.)

Read what the others have suggested here. There are good references you can read, not only about how to do OO programming in Perl, but also about the principles of design.

If I could distill it to one phrase, it would be this: "Start with the data." If you do a careful analysis of what your data structures should look like, and what will happen to them, then the code will not necessarily write itself, but it will "lay down real nice-like."

In addition to books and tutorials you can read on the subject, study the code from some good examples (and bad examples) of systems that are developed in this manner. Many such examples are present on this system.

But whatever you do, have fun, and don't be shy about getting started. The best way to figure this stuff out is to do some yourself and inspect good examples of how others have done it.

...All the world looks like -well- all the world, when your hammer is Perl.
---v

You probably do not want a single 10000 line script... not sure if that was your thought. When I code larger applications I tend to use several scripts, several templates, style sheets, and a few modules.

Before I write a single line of code I try to imagine what code each View(Page) will share. It's pretty likely that they all will need to connect to a database, check a session variable(cookie etc), save state. All of these tasks can then be moved to a module or a series of modules.

Then I think about the look of the site HTML::Template is a good fit for this. you can put together HTML template files that you can view in a browser or even (god forbid)a visual design tool like Dreamweaver, if that's your thing. this takes a lot of guess work out of how the finished page will look. In general these should not use any major formatting tags. just tables images and text in addition to the TMPL tags. The look of the site takes shape in the next step.

CSS. A file or group of files containing all of your CSS formatting rules should be linked to your templates. In this case if you decide that the background of some sheet should be a little darker you only have to make this change once.