A noble task indeed!
I don't know of any links right off but here's a couple shorties :
- easier for other people to maintain even years from now
- easier to migrate and expand
- objects make it easier to interface and work with other things, consistantly and
without much effort
- decrease cost( time, money, space, prcessing power )
- increase efficiency and effectivity ( if something is running inefficiently and
therefore, say , slow a customer can be frustrated and you lose a customer )
Example - I recently had a project involving email parseing.
The last time I got into that was four years ago and the script was
A few hundred lines ( just to parse the mail, not incuding what it did with it after
it was parsed )
and probably couldn't handle RFCc standards 100% correctly.
I can look at it and remember why/what I was doing but I can gaurantee no one else
could have without some time.
The new one is four lines long, inluding getting the data into the script, sing a
module and object from cpan which any joe could look at ten years from now
And say "Oh I see what's happening". And go to cpan to find out more about how to use
it and other things you can do with it.
Here it is, as a comparitative example can you ( or you anti oop pals ) look at it and
get a pretty quick idea
What's goin on ??
#!/usr/bin/perl
use Mail::Internet;
my $mail = Mail::Internet->new(\*STDIN);
my $headers = $mail->head->header_hashref;
my @body = @{$mail->tidy_body()};
Perfection!!! Prety simple huh?
1 get the module
2 create the object
3 make a hash refernence to the header fields ( put the headers into a hash )
4 get the body of the message witout blank lines around it.
5 do whatever you want to with it.
Where as before when I did it non object style I had to use a few
hundred lines to do the same thing and it didn't do it well at all.
Not using modules and objects is like rowing across Lake Michigan, yes you can do it
and someitmes it might even be fun to try just to see if you could do it but it's
exhausting and a speed boat would be a lot more fun!!
DMuey
> I'm sold -- I write most code as object modules now.
>
> Yes, it adds some work to make sure it's inheritable, and I
> have to think whether a method can or must be called as a
> class method, or can or must have an actual object. I've even
> written a couple that allow non-class function-style use. My
> coworkers aren't interested in dealing with the learning
> curve for objects, and don't care to hear about it.
>
> I try not to harass them, but our code styles are diverging,
> and it becomes very difficult for them to maintain my code,
> since they know nothing about OOP. I don't want to abandon
> inheritance, or encapsulation, or polymorphism, and I darned
> well don't want to have to reinvent the wheel to get the same
> results when Perl has a fine method for it, but these
> philosophies are becoming difficult to reconcile.
>
> Obviously, though I understand it well enough to use it, I
> can't explain the advantages. They say "you could just do
> that with so-and-so", and I can't communicate the amount of
> work saved by the abstraction. Even now that we're in the
> process of migrating to a new platform and are going to have
> to deal with a lot of legacy hardcoding, it's hard to
> convince them we should have any standards. (exception --
> everyone is happy to impose standards that were their own
> ideas; fortunately my boss isn't a tyrant :)
>
> Could someone point me to a concise description of the
> benefits of objects that might be short enough for my
> coworkers to actually be willing to read, and that still
> explains enough to make it make sense?
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
