Phoenix.pm: Meeting 07/18/2002

[Lowell Hamilton]

I would give anything to have to have time to sit and ponder things like
this .. I understand the majority of the topics of OO design, and in
some of my projects I can see how the principles would make life easier
and more lack-of-sleep-proof for myself, but I've implemented only a
single OO module to date (a creditcard processor) and I didn't do a very
good job .... now it's time to expand it and I'm going to end up
re-writing it because I didn't do it well ... so this comes at a good
time and maybe I can learn enough to know how to expand it so I don't
end up re-writing the whole interface and implementation later.

One question that can't be answered from the sample code laying around
and in most books (except probably Damians, which is on order right
now), is scheduled for Scott's rambling session on thursday ... GOOD
design.  I've found dozens of examples of modules that break the
abstraction and access lots of $obj->{var} directly, and tried to expand
some cpan or commercial modules that just plain hurt my brain so I gave
up... so I know how to build a basic class, dump junk in, pull stuff out
via a ton of accessors or methods, but that's it.  

It's simple to take the basic pieces and toss it all together into a big
pile of semi-functioning code-like classes, but doing things the right
way is never really covered.  I see some of Doug's slideshow examples
and think "Gee, that's handy, but I wish I understood that" while I'm 
watching the presentation, but I never had a need for building oo code. 
Now that I'm building a couple big applications that scream for oo
abstraction and persistance and I'm realzing that I lack the brainpower
to make it happen.  (Only been doing things bigger than a web script for
4 months now though, so I'm still a rookie).  

Some things I would like to see are examples of good interface design,
and some more verbose examples of internal workings, answering questions
like why you should do it this way and problems happen later if you
don't.     

Using my creditcard processor example, my interface is 

$cc = new syz::iongate ( big hash of 19 vars like address, ccnum, etc );
if ($cc->preauth or $cc->process) {
    print "Denied. Error was: " . $cc->errormsg;
} else {
    print "Successful transaction";
    my ($approvalcode, $total, $12_other_things) = $cc->result;
};

(the prepare method uri-escapes, checks for valid input, and pre-auths
the card. process settles the transaction, both return non-zero on
failure, errorsg holds the error from the input validator and the
response from the cc processor company).  

Then thoughts come up like I want to add another cc processor company
into the mix, and have different types of transactions (checks, coupons,
etc), all using that interface that I have used in dozens of other
places.   Sketching it out, I see several ways of accomplishing it, but
not having enough $$ for all those big words and being an OO rookie,
it's difficult to tell which will scale and allow me to be as lazy as
possible, while not rewriting the interface AGAIN.

Browsing through your wiki, I see wonderful things and already figured
out a couple of ponderings.  Nothing like a good Scott mindmeld to get
your planets and methods aligned though, so I'm looking forward to
Thursday :> 


Lowell





On Mon, 2002-07-15 at 14:36, Scott Walters wrote:
> 
> OO has been a bit like religion.. while it preaches peace, more people
> have been killed in its name.
> 
> Not to discourage anyone from attending, but I put a lot of what I
> did up on http://www.slowass.net/wiki/?PerlDesignPatterns. 
> The slideshow I'm saving for PM is a lot more fun though =)
> 
> I'm struggling with how to make the material interesting and
> applicable. I had 0 interest in the topic until after being forced
> to look at other peoples bad OO code one too many times, and I
> started to wonder if maybe I was doing really annoying obnoxious things
> that I didn't realize (in addition to the annoying obnoxious things
> I realized I was doing). If Design Patterns were fun and accessable,
> people may willingly apply the ideas to their code. 
> 
> I think the major part of the success of the original Design Patterns
> book was that it gave a common language to program structure. 
> While not interested in high ideals and contrived examples, many
> programmers enjoyed expanding their vocabulary.
> 
> I really really want feedback and ideas to that effect, more than
> anything else. Possibly the coolist thing I could do is something
> in the vein of "Devils Dictionary". If I can get things polished
> a bit, I want to turn it loose on the Perl community.
> 
> Thanks for the encouraging words =)
> 
> -scott
> 
> On 15 Jul 2002, Lowell Hamilton wrote:
> 
> > Yay .. just what I'm tackling now (well learning the "right" way to do
> > it anyway).  Good OO has always been a mistery to me ;(
> > 
> > I'll be there.
> > 
> > Lowell
> > 
> > 
> > 
> > On Mon, 2002-07-15 at 13:53, Doug Miles wrote:
> > > We'll be having a Phoenix.pm meeting Thursday, July 18th at 7:00PM.
> > > It will be held at Bowne, which is located at 1500 N. Central Avenue,
> > > which is on the Southwest corner of Central and McDowell.  The parking
> > > lot is gated, so just press the button on the intercom, and tell the
> > > receptionist that you are there for the Perl meeting.  Park in the lot
> > > that is straight ahead from the entrance on the South side of McDowell.
> > > Park in any uncovered, non-reserved space.  Proceed to the main lobby,
> > > which is on the Northeast side of the parking lot.
> > > 
> > > Scott will be presenting "Design Patterns in Perl: Writing scalable 
> > > Object Oriented code"
> > > 
> > > -- 
> > > - Doug
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > -- 
> > | Concept Marketing Group, Inc.
> > | www.marketingsource.com
> > | 800-575-5369
> > 
> > 
> 
> 
-- 
| Concept Marketing Group, Inc.
| www.marketingsource.com
| 800-575-5369