Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Best OOP strategy?

by Anonymous Monk
on Aug 16, 2002 at 03:59 UTC ( #190588=perlquestion: print w/replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I'm currently working on a script to manage my sites news/content and need a perfect OOP strategy to use. The script is going to have a whole bunch of parts to it like actual news posting, category management, user management, static page management (like editing of index.html thru the script), etc.. so I need an OO strategy that will keep the script moving fast with more then 10 000 lines of code and make it still easy to expand down the road.

I was thinking about just doing the parts something like:

package MyScript::Categories; sub MainPage { ...main categories page... } sub Add { ...add categories page... } ..etc..
And then accessing category-related subs like MyScript::Categories::Add, etc. but I've noticed it's rather a pain to do it that way. So then I thought of doing something like:
my $ms = new MyScript; # this would go up at the top package MyScript; sub new { my $class = shift; our $library = new MyScript::Library; our $reviews = new MyScript::Reviews; bless {}, $class; } package MyScript::Library; sub new { my $class = shift; bless {}, $class; } # all library subs go here package MyScript::Reviews; sub new { my $class = shift; bless {}, $class; } # all subs related to reviews go here
Then I was thinking I could access my library subs through $library and review-related subs through $reviews anywhere in the script.

I'm not sure how either of the two OO strategies will handle with lots of code and such so I was hoping my fellow monks could give me some suggestions. These two designs might even be too poor to use in the long run so please, please point me in the right direction :)

Replies are listed 'Best First'.
Re: Best OOP strategy?
by DamnDirtyApe (Curate) on Aug 16, 2002 at 04:50 UTC
Re: Best OOP strategy?
by djantzen (Priest) on Aug 16, 2002 at 04:33 UTC

    "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.

Re: Best OOP strategy?
by Ryszard (Priest) on Aug 16, 2002 at 12:51 UTC
    Sounds to me like your need to read about patterns in OO (I just bought this book and can recommend it). It doesnt deal directly with perl, however the patterns can be applied. (check out this site for some perl specific reading).

    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.

Re: Best OOP strategy?
by Zaxo (Archbishop) on Aug 16, 2002 at 06:31 UTC

    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,

Re: Best OOP strategy?
by BUU (Prior) on Aug 16, 2002 at 04:20 UTC
    Uh. Where exactly is the OOP here? $myObj->method(); is object oriented. package:baz:foo() is a function call using packagenames
Re: Best OOP strategy?
by agentv (Friar) on Aug 16, 2002 at 20:54 UTC
    ...not to flog a limping horse here, but I feel compelled to reiterate a couple of things already said here, and to add a couple of thoughts.

    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.

Re: Best OOP strategy?
by thunders (Priest) on Aug 16, 2002 at 18:41 UTC

    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.

Re: Best OOP strategy?
by Spudnuts (Pilgrim) on Aug 16, 2002 at 17:25 UTC

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://190588]
Approved by ehdonhon
Front-paged by derby
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (8)
As of 2018-06-20 15:01 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (116 votes). Check out past polls.