OO Programming principles.
A few main principles of design for Object Oriented code


   REUSABILITY
      - If you have to keep writing the same code over and over, or cut and
        paste from other scripts or routines you've used forever --just with
        minor variations, this is an indication that your favorite chunks of
        code could usefully be compiled into a library or subset of libraries
        that can be imported to scripts that need them.  No re-writing.

   MAINTAINABILITY
      - do you find that your solution requires a lot of tweaking and changing,
        or that you get tired of using the libraries you made because the code
        isn't flexible enough to meet the needs of individual applications?
        This indicates an opportunity to extend your code, not abandon it.  The
        extending of which I speak consists of small alterations to the code
        routines in your library so that they are more flexible themselves.
        This concept is called 'Polymorphism', or in otherwords, it's nerd-speak
        for saying that the code can handle multiple types of input in a manner
        that it morphs (or changes itself) in order to accomodate the needs.

   UNDERSTAND-ABILITY
      - can someone easily get a grasp on what you've coded, is it readable?
        could you hand it to someone and say, "see what I mean?"  You can take
        a lot of shortcuts and use a lot of handy tricks in Perl that make your
        code fairly obfuscated.  As a general rule, good code centered around
        the principle that it can be easily extended, included in other code
        with a reliably extensible interface, and so on and so forth is easy
        to understand.  Not all code needs to be centered around these
        principles, but if your code is designed with the goal of reusability
        in mind, you will succeed by creating elegant code which is easy to
        quickly grasp or follow.  You code would quickly reveal it's own
        purpose to another programmer, without making him spend extra time
        to sort out strange sequences of code where uncommon conventions of
        a programming language are used carelessly and without explanation.

        For example, A vs. B

        A
            {$$pcom{'canFT'}=0;my($ftn)=$$pcom{'DIR'}{'fonts'}
            .'/arial.ttf';my($tx)=$ftn;use GD;my($i)=GD::Image
            ->new(10,10);my($b)=$i->colorAllocate(255,255,255)
            ;my($f)=$i->colorAllocate(0,0,0,);my(@bounds)=$i->
            stringFT($f,$ftn,8,0,0,0,$tx);++$$pcom{'canFT'} if
            (scalar(@bounds)>0);&sk()unless($$pcom{'canFT'});}

        B

            use GD;

            my($i)   = GD::Image->new(10,10);
            my($ftn) = $pcom->{'DIR'}{'fonts'}.'/arial.ttf';
            my($tx)  = $ftn;
            my($b)   = $i->colorAllocate(255,255,255);
            my($f)   = $i->colorAllocate(0,0,0,);

            my(@bounds) =
               $i->
                  stringFT
                     (
                        $f,
                        $ftn,
                        8,
                        0,
                        0,
                        0,
                        $tx
                     );

            if (scalar(@bounds) > 0) {

               # assuming $pcom was previously declared elsewere in the code
               $pcom->{'canFT'} = 1;
               &sk();
            }

   SCALABILITY
      - your code shouldn't have a lot of inter/exterior dependencies.  It
        provides a good solution when it can be built upon, like a foundation
        of sorts, without clinging to other code for it's own operation, UNLESS
        your code routines were built as an extension to previously existing
        code that is readily made available in any instance that the enxtension
        you created is required.

   ALWAYS SECURITY!
      - this is a must.  If you don't know why, you will later for better or
        for worse.  If you don't know how to accomplish this in your Perl
        programming -->particulary in file IO operatives, devote yourself to
        a bit of study on the matter so that you are informed.

   PORTABILITY
      - if it doesn't work for Joe, but it works for Sarah and Bob, and Bill
        only has a problem with it now and then, it doesn't work.  That is
        just a good policy to which reusable solutions would likely adhere.

   SIMPLICITY
      - does the solution make more complications than the problem itself? If
        so, start over at the top level of your criteria, ordered by importance,
        and refine your process step by step until you are done.  If it takes
        a long time, it only means that you are saving that much time in every
        situation where this commonly needed code must be written.  If you do
        it right, it will take a bit longer but you'll only have to do it once,
        and that is pretty cool.

   MODULARITY
      - does the solution you strive to provide require a collection of smaller
        sub-tasks which could very likely be necessary to provide the needed
        functionality for other solutions as well?  If so, then split it up.
        Put your code into a hierarchal, organized compilation.  This might be
        compared to the chapters in a history book, or mathematics book.  Each
        chapter contains information which is applicable in many other
        situations.  Futher, the chapters are organized into subsections, and
        the chapters have quite likely been organized into larger sections
        themselves.  I remember in health class back in school our book had a
        structure like this example, and modular code will be simalarly
        organized.

            UNIT
              |
              +- CHAPTER
              |     |
              |     +- SECTION
              |     |     |
              |     |     +- OVERVIEW
              |     |     +- CONTENT
              |     |     |     |
              |     |     |     +- PAGES
              |     |     |     +- PAGES
              |     |     |     +- PAGES
              |     |     |
              |     |     +- REVIEW
              |     |     +- TEST



--
   -Tommy Butler
    http://atrixnet.com

I'm looking for work!
    contract or perm, full or part time
    Download my résumé http://www.atrixnet.com/resume

the Open Source Perl Archives
    at Atrixnet.
    http://www.atrixnet.com/pub/